handling of underrunning snd_pcm_writei

handling of underrunning snd_pcm_writei

[Mads Kiilerich]

Hi,

I AM trying to convert an internal app from oss to alsa and is trying to 
grok the alsa API and the examples I can find.

I would like to ask some questions to avoid guessing and making wrong 
assumptions. Feel free to redirect me to where I should have found the 
answer myself.

http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#gf13067c0ebde29118ca05af76e5b17a9 
says about snd_pcm_writei:

> Returns: a positive number of frames actually written otherwise a negative error code
> ...
> Return values:
> ...
> -EPIPE 	an underrun occurred
> ...
> The count of bytes can be less only if a signal or underrun occurred.

So what is returned in case of underrun? Error code or count of bytes?

Should snd_pcm_recover always be used to get the byte count after 
-EPIPE? snd_pcm_recover is neither mentioned in the link above nor in 
http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html , so I don't feel 
confident about that.

And is it measured in "positive number of frames actually written" or 
"count of bytes"?

It surprises me that snd_pcm_writei shows non-blocking behaviour in case 
of underruns and don't use all the offered data. I would guess that it 
either blocked and enjoyed the data it finally got, or that it gave an 
error and didn't take any data at all. But if this is how it is, then 
... that is how it is ;-)

/Mads

using
alsa-lib-1.0.21-3.fc11.i586
alsa-plugins-pulseaudio-1.0.21-2.fc11.i586

Re: handling of underrunning snd_pcm_writei

[Mads Kiilerich]

On 11/11/2009 05:50 PM, Mads Kiilerich wrote:

> http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#gf13067c0ebde29118ca05af76e5b17a9
> says about snd_pcm_writei:
>
>> Returns: a positive number of frames actually written otherwise a
>> negative error code
>> ...
>> Return values:
>> ...
>> -EPIPE an underrun occurred
>> ...
>> The count of bytes can be less only if a signal or underrun occurred.
...
> It surprises me that snd_pcm_writei shows non-blocking behaviour in case
> of underruns and don't use all the offered data. I would guess that it
> either blocked and enjoyed the data it finally got, or that it gave an
> error and didn't take any data at all. But if this is how it is, then
> ... that is how it is ;-)

Ok, experiments indicates that the documented blocking behaviour only 
applies in SND_PCM_STATE_RUNNING. snd_pcm_writei apparently behaves 
non-blocking in SND_PCM_STATE_PREPARED. I can see how that kind of makes 
sense - I just didn't expect that. Is that correctly understood?

/Mads

Re: handling of underrunning snd_pcm_writei

[Takashi Iwai]

At Wed, 11 Nov 2009 17:50:12 +0100,
Mads Kiilerich wrote:
> 
> > Returns: a positive number of frames actually written otherwise a negative error code
> > ...
> > Return values:
> > ...
> > -EPIPE 	an underrun occurred
> > ...
> > The count of bytes can be less only if a signal or underrun occurred.
> 
> So what is returned in case of underrun? Error code or count of bytes?

First it returns the actually written frames, then -EPIPE.
But, it might return -EPIPE first, depending on the plugin, I guess.

> Should snd_pcm_recover always be used to get the byte count after 
> -EPIPE? snd_pcm_recover is neither mentioned in the link above nor in 
> http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html , so I don't feel 
> confident about that.

Yes, snd_pcm_recover() is *recommended*.  You can write the recovery
routine by yourself.  The function isn't referred here just because
it's relatively new.  Better to be documented, indeed.

> And is it measured in "positive number of frames actually written" or 
> "count of bytes"?

Frames.  Should be corrected.

For both fixes, a patch from contributors is always welcome ;)

> It surprises me that snd_pcm_writei shows non-blocking behaviour in case 
> of underruns and don't use all the offered data. I would guess that it 
> either blocked and enjoyed the data it finally got, or that it gave an 
> error and didn't take any data at all. But if this is how it is, then 
> ... that is how it is ;-)

It's because the XRUN isn't recovered automatically but the operation
stops.  It's analogous to a disk-full error.


thanks,

Takashi

Re: handling of underrunning snd_pcm_writei

[Mads Kiilerich]

On 11/12/2009 08:12 AM, Takashi Iwai wrote:
> Yes, snd_pcm_recover() is *recommended*.  You can write the recovery
> routine by yourself.  The function isn't referred here just because
> it's relatively new.  Better to be documented, indeed.

Thanks a lot for you answer, Takashi. That was very helpful.

But when I hack pcm_min.c to log the state at the beginning of the loop 
and then enforces an underrun by pausing the program then it sometimes 
locks up:

$ ./pcm_min
state 2 SND_PCM_STATE_PREPARED
state 2 SND_PCM_STATE_PREPARED
Short write (expected 16384, wrote 7616)
state 3 SND_PCM_STATE_RUNNING
state 3 SND_PCM_STATE_RUNNING
state 3 SND_PCM_STATE_RUNNING
state 3 SND_PCM_STATE_RUNNING
[ctrl-s ... waiting for silence ... ctrl q]
ALSA lib pcm.c:7234:(snd_pcm_recover) underrun occured
state 2 SND_PCM_STATE_PREPARED
state 2 SND_PCM_STATE_PREPARED
state 3 SND_PCM_STATE_RUNNING
[hanging in snd_pcm_writei]

It seems like pcm_min.cs use of snd_pcm_recover isn't enough to recover 
fully? The playback never gets started again, so the async writes in 
PREPARED succeeds, but the first blocking write hangs waiting forever? 
What is missing?

It also surprises me that the last PREPARED write isn't a short write. 
Why is that?

Regards,
Mads

Re: handling of underrunning snd_pcm_writei

[Mads Kiilerich]

On 11/12/2009 01:10 PM, Mads Kiilerich wrote:
> On 11/12/2009 08:12 AM, Takashi Iwai wrote:
>> Yes, snd_pcm_recover() is *recommended*. You can write the recovery
>> routine by yourself. The function isn't referred here just because
>> it's relatively new. Better to be documented, indeed.
>
> Thanks a lot for you answer, Takashi. That was very helpful.
>
> But when I hack pcm_min.c to log the state at the beginning of the loop
> and then enforces an underrun by pausing the program then it sometimes
> locks up:
>
> $ ./pcm_min
> state 2 SND_PCM_STATE_PREPARED
> state 2 SND_PCM_STATE_PREPARED
> Short write (expected 16384, wrote 7616)
> state 3 SND_PCM_STATE_RUNNING
> state 3 SND_PCM_STATE_RUNNING
> state 3 SND_PCM_STATE_RUNNING
> state 3 SND_PCM_STATE_RUNNING
> [ctrl-s ... waiting for silence ... ctrl q]
> ALSA lib pcm.c:7234:(snd_pcm_recover) underrun occured
> state 2 SND_PCM_STATE_PREPARED
> state 2 SND_PCM_STATE_PREPARED
> state 3 SND_PCM_STATE_RUNNING
> [hanging in snd_pcm_writei]
>
> It seems like pcm_min.cs use of snd_pcm_recover isn't enough to recover
> fully? The playback never gets started again, so the async writes in
> PREPARED succeeds, but the first blocking write hangs waiting forever?
> What is missing?

It seems like the lockup always happens in SND_PCM_STATE_RUNNING after 
snd_pcm_avail_update has reported values > 9000. Usually it returns < 8000.

Any idea?

/Mads

Re: handling of underrunning snd_pcm_writei

[Takashi Iwai]

At Thu, 12 Nov 2009 15:01:15 +0100,
Mads Kiilerich wrote:
> 
> On 11/12/2009 01:10 PM, Mads Kiilerich wrote:
> > On 11/12/2009 08:12 AM, Takashi Iwai wrote:
> >> Yes, snd_pcm_recover() is *recommended*. You can write the recovery
> >> routine by yourself. The function isn't referred here just because
> >> it's relatively new. Better to be documented, indeed.
> >
> > Thanks a lot for you answer, Takashi. That was very helpful.
> >
> > But when I hack pcm_min.c to log the state at the beginning of the loop
> > and then enforces an underrun by pausing the program then it sometimes
> > locks up:
> >
> > $ ./pcm_min
> > state 2 SND_PCM_STATE_PREPARED
> > state 2 SND_PCM_STATE_PREPARED
> > Short write (expected 16384, wrote 7616)
> > state 3 SND_PCM_STATE_RUNNING
> > state 3 SND_PCM_STATE_RUNNING
> > state 3 SND_PCM_STATE_RUNNING
> > state 3 SND_PCM_STATE_RUNNING
> > [ctrl-s ... waiting for silence ... ctrl q]
> > ALSA lib pcm.c:7234:(snd_pcm_recover) underrun occured
> > state 2 SND_PCM_STATE_PREPARED
> > state 2 SND_PCM_STATE_PREPARED
> > state 3 SND_PCM_STATE_RUNNING
> > [hanging in snd_pcm_writei]
> >
> > It seems like pcm_min.cs use of snd_pcm_recover isn't enough to recover
> > fully? The playback never gets started again, so the async writes in
> > PREPARED succeeds, but the first blocking write hangs waiting forever?
> > What is missing?
> 
> It seems like the lockup always happens in SND_PCM_STATE_RUNNING after 
> snd_pcm_avail_update has reported values > 9000. Usually it returns < 8000.

Hm, not now, as I've been too busy for other things.
Will take a look at this issue later.


thanks,

Takashi