Re: snd_pcm_drain() always fails

Re: snd_pcm_drain() always fails

[Jaroslav Kysela]

On Mon, 1 Aug 2005, Hynek Hanke wrote:

> 
> Hi,
> 
> I'm still having problems programming ALSA backend for my app. I open the
> device, I try to write as many frames as possible, I poll() for events (and
> check for XRUNs and SUSPENDs, they don't happen). When I get notification that
> ALSA is ready for more frames, I send more (typically 32 or 64). After all
> frames are sent, I call snd_pcm_drain() ... and want to wait in poll() until
> ALSA gets out of SND_PCM_STATE_DRAINING.
> 
> But snd_pcm_drain() always fails with ``Resource temporarily unavailable''
> error.  The state after snd_pcm_drain() fails is still RUNNING. Why is this?
> What can I do about it?

Nothing. If drain() is supposed to wait until all data are played and 
you're using the non-blocking mode, then it's definitely an error (thus 
-EAGAIN is returned - and it means from the driver perspective - I must 
wait and the application does not want this from me).

> Or, what is the correct way to wait until the rest of the sound is 
> played when I'm using the poll() approach?

Set the blocking mode before drain() is called (and return the mode back 
after it, if you want). The better way might be setting sw_params to 
wakeup app after all frames are played and use the standard poll() call to 
wait in app.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: snd_pcm_drain() always fails

[Hynek Hanke,,,]

> > Or, what is the correct way to wait until the rest of the sound is 
> > played when I'm using the poll() approach?
> Set the blocking mode before drain() is called (and return the mode back 
> after it, if you want). 

Not possible. I'm waiting for other events (not comming from ALSA) too in the
poll().

> The better way might be setting sw_params to wakeup app after all frames are
> played and use the standard poll() call to wait in app.

How do I do this or where can I read about it? Still, I need to receive other events
too while waiting for the sound to stop playing.

Thank you,
Hynek Hanke


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: snd_pcm_drain() always fails

[Hynek Hanke]

> Nothing. If drain() is supposed to wait until all data are played and 
> you're using the non-blocking mode, then it's definitely an error (thus 
> -EAGAIN is returned - and it means from the driver perspective - I must 
> wait and the application does not want this from me).

The documentation is very unclear about this. My guess was that it should bring
me to the state DRAINING which should remain until all frames are played.
 
> Set the blocking mode before drain() is called (and return the mode back 
> after it, if you want).

This is not possible. I'm using the non-blocking mode and poll() specifically
because I need to receive external events (not comming from ALSA) too.

> The better way might be setting sw_params to wakeup app after all frames are
> played and use the standard poll() call to wait in app.  

How can I do this or where can I read about it? I still need to receive those
external events on other file descriptors. Is it possible with this approach?

With regards & thank you,
Hynek Hanke


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: snd_pcm_drain() always fails

[Takashi Iwai]

At Mon, 1 Aug 2005 20:10:15 +0200,
Hynek Hanke wrote:
> 
> > Nothing. If drain() is supposed to wait until all data are played and 
> > you're using the non-blocking mode, then it's definitely an error (thus 
> > -EAGAIN is returned - and it means from the driver perspective - I must 
> > wait and the application does not want this from me).
> 
> The documentation is very unclear about this. My guess was that it should bring
> me to the state DRAINING which should remain until all frames are played.

Patches are always welcome :)

> > Set the blocking mode before drain() is called (and return the mode back 
> > after it, if you want).
> 
> This is not possible. I'm using the non-blocking mode and poll() specifically
> because I need to receive external events (not comming from ALSA) too.
> 
> > The better way might be setting sw_params to wakeup app after all frames are
> > played and use the standard poll() call to wait in app.  
> 
> How can I do this or where can I read about it? I still need to receive those
> external events on other file descriptors. Is it possible with this approach?

Set avail_min swparams to the buffer size so that poll() won't return
unless the full buffer size becomes free (i.e. all samples are
played).  If stop_threshold is set to buffer size, the pcm stream will
be stopped automatically and set to XRUN state.


Takashi


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: snd_pcm_drain() always fails

[Hynek Hanke]

> Set avail_min swparams to the buffer size so that poll() won't return
> unless the full buffer size becomes free (i.e. all samples are
> played).  

This would mean, if I understand correctly, that I always send more data only
after the buffer is already empty. Won't that cause unwanted effects
(underrruns etc.)?

With regards,
Hynek Hanke




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: snd_pcm_drain() always fails

[Takashi Iwai]

At Mon, 1 Aug 2005 20:36:37 +0200,
Hynek Hanke wrote:
> 
> > Set avail_min swparams to the buffer size so that poll() won't return
> > unless the full buffer size becomes free (i.e. all samples are
> > played).  
> 
> This would mean, if I understand correctly, that I always send more data only
> after the buffer is already empty. Won't that cause unwanted effects
> (underrruns etc.)?

No, you can change avail_min on the fly, at the moment you want
"draining".  Reset avail_min to a certain value again if you want to
re-feed the data.


Takashi


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: snd_pcm_drain() always fails

[Giridhara]

Hynek Hanke,,, <hanke <at> volny.cz> writes:

> 
> > > Or, what is the correct way to wait until the rest of the sound is 
> > > played when I'm using the poll() approach?
> > Set the blocking mode before drain() is called (and return the mode back 
> > after it, if you want). 
> 
> Not possible. I'm waiting for other events (not comming from ALSA) too in the
> poll().
> 
> > The better way might be setting sw_params to wakeup app after all frames are
> > played and use the standard poll() call to wait in app.
> 
> How do I do this or where can I read about it? Still, I need to receive
other events
> too while waiting for the sound to stop playing.
> 
> Thank you,
> Hynek Hanke
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> 



Hello Team,

Any body successfully run the audio in the non blocking mode. 
I too have the same issues. 
Please suggest me.
Any sample programs are great help for me. 

Thanks and Regards,
Giri