Hi Takashi,
Thanks for your reply and suggestions. Finally we have found the root
cause.
Seems it's related to both drivers and alsa-lib.
When two dmix clients run in parallel we get two direct dmix instances. 1st dmix instance: snd_pcm_dmix_open() snd_pcm_direct_initialize_slave() save_slave_setting() Since the driver we are using has SND_PCM_INFO_RESUME flag, dmix->spcm->info has this flag. Then this flag is cleared in
dmix->shmptr->s.info.
2nd dmix instance: snd_pcm_dmix_open() snd_pcm_direct_open_secondary_client() copy_slave_setting() 2nd dmix->spcm->info is copied from dmix->shmptr->s.info so it doesn' has this flag.
If 1st dmix instance resumes firstly it should implement recovery of slave pcm in snd_pcm_direct_slave_recover(). Because 1st dmix->spcm->info has SND_PCM_INFO_RESUMEļ¼snd_pcm_resume(direct->spcm) can be called correctly to resume slave pcm.
... and immediately stop the stream, then prepare and restart as a usual restart.
However if 2nd dmix instance resumes firstly, snd_pcm_resume(direct->spcm) will not be called because it's spcm->info doesn't has SND_PCM_INFO_RESUME flag. The 1st dmix
instance
assumes someone else already did recovery so snd_pcm_resume(direct->spcm) won't be called neither. In result the slave pcm fails to resume.
Something wrong happening here, then.
In dmix, there is no hardware resume at all, but it's always a restart of the stream. The call of snd_pcm_resume() is only temporarily for
inconsistencies
that can be a problem on some drivers (IIRC dmaengine stuff). That said, dmix does a kind of fake resume, stops and restarts the stream cleanly on
the
first instance. On the second instance, it's already recovered, hence it
bails
out.
If poll() hangs on the second instance, there can be some other problem. Maybe the resume -> stop -> restart sequence doesn't work with your
driver
well?
Our dma driver will do PAUSE in system suspend and requires doing RESUME
in
system resume. Current problem is that snd_pcm_resume() is not called by
both
1st instance and 2nd instance.
That's weird. Are you really testing with the latest alsa-lib code?
If application doesn't call snd_pcm_resume(), it means that the PCM state isn't set to SUSPENDED, so it pretends as if still running.
Or if you mean that snd_pcm_resume() to the slave PCM isn't called (even though snd_pcm_resume() is called for the dmix PCM), check whether snd_pcm_direct_slave_recover() gets called, especially at the point:
/* some buggy drivers require the device resumed before prepared; * when a device has RESUME flag and is in SUSPENDED state,resume * here but immediately drop to bring it to a sane active state. */ if (state == SND_PCM_STATE_SUSPENDED && (direct->spcm->info & SND_PCM_INFO_RESUME)) { snd_pcm_resume(direct->spcm); snd_pcm_drop(direct->spcm); snd_pcm_direct_timer_stop(direct); snd_pcm_direct_clear_timer_queue(direct); }
Try to put debug prints or catch via breakpoint whether this code path is executed.
Also, does the issue happen with the latest 6.11-rc kernel, too? If yes, what if you drop SNDRV_PCM_INFO_RESUME bit flag in the driver side? Does the problem persist, or it works?
I'm working on kernel 6.6 and alsa-lib v1.2.11. It's not so outdated I think and then I will try to switch on the latest version.
Indeed I did some debug on this part. Please see my comments inline.
int snd_pcm_direct_slave_recover(snd_pcm_direct_t *direct) { ... /* [Chancel] * When two dmix clients run in parallel we get two direct dmix instances. * 1st dmix->spcm->info has SND_PCM_INFO_RESUME flag but 2nd dmix doesn't. * Let's name 1st opened dmix "dmix1" and 2nd dmix "dmix2". * After resume, both dmix1 and dmix2 enter into snd_pcm_direct_slave_recover(). * Here we assume dmix2 is the earlier instance which execute here. * dmix2 successfully get semaphore lock and dmix1 is waiting for this lock. */ semerr = snd_pcm_direct_semaphore_down(direct, DIRECT_IPC_SEM_CLIENT); ... state = snd_pcm_state(direct->spcm); if (state != SND_PCM_STATE_XRUN && state != SND_PCM_STATE_SUSPENDED) { /* [Chancel] * dmix2 finds spcm state is SUSPENDED so it will not enter here. * However later when dmix1 get lock and enter here, spcm state has been changed to RUNNING by dmix2. * In result dmix1 assumes some other instance has done so dmix2 directly return. * snd_pcm_resume() is not called by dmix1. */ /* ignore... someone else already did recovery */ semerr = snd_pcm_direct_semaphore_up(direct, DIRECT_IPC_SEM_CLIENT); if (semerr < 0) { SNDERR("SEMUP FAILED with err %d", semerr); return semerr; }
return 0; } ...
if (state == SND_PCM_STATE_SUSPENDED && (direct->spcm->info & SND_PCM_INFO_RESUME)) { /* [Chancel] * dmix2->spcm->info doesn't have SND_PCM_INFO_RESUME flag. So this condition is not met. * snd_pcm_resume() is not called by dmix2. */
snd_pcm_resume(direct->spcm); snd_pcm_drop(direct->spcm); snd_pcm_direct_timer_stop(direct); snd_pcm_direct_clear_timer_queue(direct); } ... ret = snd_pcm_prepare(direct->spcm); ... /* [Chancel] * dmix2 calls snd_pcm_start to set spcm state to RUNNING. */ ret = snd_pcm_start(direct->spcm); ... }
The dma driver I'm using supports pause/resume function. I don't think dropping SNDRV_PCM_INFO_RESUME is a good fix on this issue. Besides this driver, I also validate on another driver whose dma doesn't has such flag. This issue has gone and both 2 instances work well with suspend/resume.
Regards, Chancel Liu
SND_PCM_INFO_RESUME flag has impact on the flow of dmix resume. In
my
opinion the first resumed dmix instance should make sure slave pcm can be recovered properly no matter it's the first opened instance or secondary opened instance
.
The snd_pcm_resume() gets called no matter which instance, just the first
one
who tries to recover the suspended state. (And it's called internally at updating the various state, not necessarily an explicit recovery call.)
Unfortunately if secondary opened instance resumes first it doesn't has SND_PCM_INFO_RESUME which causes snd_pcm_resume() never be called.
No, it's misunderstanding. SND_PCM_INFO_RESUME isn't exposed to the application in the case of dmix at all; i.e. dmix doesn't support the full resume, per se. That's the design. So it doesn't matter which instance gets resumed at first.
Do you know why the secondary opened instance clear the SND_PCM_INFO_RESUME flag? Can we do the following modification?
diff --git a/src/pcm/pcm_direct.c b/src/pcm/pcm_direct.c @@ -1183,8 +1226,6 @@ static void save_slave_setting(snd_pcm_direct_t *dmix,
snd_pcm_t *spcm)
COPY_SLAVE(buffer_time); COPY_SLAVE(sample_bits); COPY_SLAVE(frame_bits);
dmix->shmptr->s.info &= ~SND_PCM_INFO_RESUME;I don't think so. The clearance of the RESUME flag here is correct. dmix doesn't support the hardware resume feature. It does its own. (And this flag is merely a info for apps, which isn't really evaluated except
for
the code in dmix workaround there.)
Takashi
I think dmix should know what state the real driver is. If driver requires that app should do snd_pcm_resume() how can dmix get this information?
The dmix already knows. But the PCM state exposed to applications isn't always tied as 1:1.
Takashi