[alsa-devel] R: snd_pcm_writei 0 frames
Giuliano Zannetti - ART S.p.A.
giuliano.zannetti at artgroup-spa.com
Tue Mar 26 17:40:38 CET 2019
Hi Jaroslav,
Thank you for your suggestion. But unfortunately the problem persists.
Giuliano
-----Messaggio originale-----
Da: Jaroslav Kysela <perex at perex.cz>
Inviato: lunedì 25 marzo 2019 16:15
A: Giuliano Zannetti - ART S.p.A. <giuliano.zannetti at artgroup-spa.com>; alsa-devel at alsa-project.org
Cc: Takashi Iwai <tiwai at suse.de>
Oggetto: Re: [alsa-devel] snd_pcm_writei 0 frames
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.
More information about the Alsa-devel
mailing list