[alsa-devel] snd_pcm_writei 0 frames

[Jaroslav Kysela]

Dne 25. 03. 19 v 15:16 Giuliano Zannetti - ART S.p.A. napsal(a):
> Hi,
> 
> I've the following configuration in my asound.conf:
> 
> |-----| - - > |-----| - - > |-----| - - > |-----| - - > |-----| - - > |----------|
> |plug |       |     | - - > |     | - - > |     | - - > |     | - - > | (output) |
> |-----| - - > |     | - - > |     | - - > |     | - - > |     | - - > |    hw    |
>               |     | - - > |     | - - > |     | - - > |     | - - > |          |
>               |     |       |     |       |route| - - > |dmix | - - > |          |
>               |     |       |     |       |     | - - > |     | - - > |          |
>               |     |       |     |       |     | - - > |     | - - > |          |
>               |     |       |     |       |-----| - - > |-----| - - > |----------|
>               |route|       |multi|
>               |     | - - > |     |
>               |     | - - > |     | - - > |----| - - > |----| - - > |----------|
>               |     | - - > |     | - - > |    | - - > |    | - - > |(loopback)|
>               |-----| - - > |     | - - > |plug| - - > |dmix| - - > |    hw    |
>                             |-----| - - > |----| - - > |----| - - > |----------|
> 
> As you can see I'm using a loopback interface.
> I open the pcm plug in the block mode to write.
> 
> writtenFrames = snd_pcm_writei(handle, bufferToWrite, bufferToWriteSize);
> 
> Using the configuration above I have several "writes" with 0 written frames.
> It seems like the snd_pcm_writei does not hold until data will be written.
> 
> In general, 0 written frames sounds weird to me, because snd_pcm_writei should block itself if no space is available in the circular buffer right?
> 
> So, my questions are two:
> 
>   1.  Writing 0 frames is an expected behaviour (regardless of my configuration in the asound.conf)? In what scenarios can I have that?
>   2.  How my configuration could trigger this behaviour?

I guess that snd_pcm_multi_may_wait_for_avail_min() implementation is the culprit. It should take in account all slaves - not only the master one.

Could you test this modification?

diff --git a/src/pcm/pcm_multi.c b/src/pcm/pcm_multi.c
index 28440378..0afd31bf 100644
--- a/src/pcm/pcm_multi.c
+++ b/src/pcm/pcm_multi.c
@@ -775,11 +775,15 @@ static int snd_pcm_multi_mmap(snd_pcm_t *pcm)
        return 0;
 }

-static int snd_pcm_multi_may_wait_for_avail_min(snd_pcm_t *pcm, snd_pcm_uframes_t avail ATTRIBUTE_UNUSED)
+static int snd_pcm_multi_may_wait_for_avail_min(snd_pcm_t *pcm, snd_pcm_uframes_t avail)
 {
        snd_pcm_multi_t *multi = pcm->private_data;
-       snd_pcm_t *slave = multi->slaves[multi->master_slave].pcm;
-       return snd_pcm_may_wait_for_avail_min(slave, snd_pcm_mmap_avail(slave));
+       unsigned int i;
+       for (i = 0; i < multi->slaves_count; ++i) {
+               if (snd_pcm_may_wait_for_avail_min(multi->slaves[i].pcm, avail))
+                       return 1;
+       }
+       return 0;
 }

 static snd_pcm_chmap_query_t **snd_pcm_multi_query_chmaps(snd_pcm_t *pcm)

					Jaroslav


-- 
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.