The different STATES of ALSA

The different STATES of ALSA

[Hynek Hanke]

Hi everyone,

I'm having very much troubles programming an ALSA interface because the
documentation is pretty poor. I'm very much confused about the different states
in alsa-lib.

(After I was told alsa-lib is not thread-safe and there is some bug in the kernel
implementation of the underlaying calls of snd_pcm_writei(), I'm now running the
non-blocking/polling approach).

My questions:

1) In which states am I allowed to call
	a) snd_pcm_hw_params_any
	b) snd_pcm_hw_params
	c) snd_pcm_prepare
	d) snd_pcm_drop and _drain

2) Which states do they bring me to, if they don't return an error?

3) How is it possible that snd_pcm_drain returns with a success value *and*
   the snd_pcm_state() still reports SND_PCM_STATE_DRAINING ? Is this a bug?

4) How is it possible, that the whole time a sound is played snd_pcm_writei()
   never returns the value -EPIPE and still, when checking the state before
   playing the next sound, I find the device in the SND_PCM_STATE_XRUN
   (snd_pcm_drain() gets called in the meantime).

The problems (3) and (4) seem to arrise only under some circumstances, possibly
when more sounds are played in a quick succession.

Thank you for help,
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: The different STATES of ALSA

[James Courtier-Dutton]

Hynek Hanke wrote:
> Hi everyone,
> 
> I'm having very much troubles programming an ALSA interface because the
> documentation is pretty poor. I'm very much confused about the different states
> in alsa-lib.
> 
> (After I was told alsa-lib is not thread-safe and there is some bug in the kernel
> implementation of the underlaying calls of snd_pcm_writei(), I'm now running the
> non-blocking/polling approach).
alsa-lib is perfectly thread-safe.
The non-blocking/polling or "callback" approach is by far the most 
efficient and best way to talk to a sound card.

Generally you should use:
open
set hw_params
set sw_params
fill some of the sound buffer then do snd_pcm_start() or set sw_params 
to autostart for you.
Then use poll(), check state(xrun recover) and then writei() for sound 
output.

> 
> My questions:
> 
> 1) In which states am I allowed to call
> 	a) snd_pcm_hw_params_any
Only after snd_pcm_open() and snd_pcm_hw_params_alloca(&params);
> 	b) snd_pcm_hw_params
Only after you have done all the snd_pcm_hw_params_xxx() to set 
different HW params.
This must happen before any snd_pcm_sw_params and before the stream is 
prepared or started.
> 	c) snd_pcm_prepare
After an xrun(for xrun recovery) or after hw and sw params have been set up.

> 	d) snd_pcm_drop and _drain
At any time while the stream is in RUNNING state.
It returns depending on block/non-block state.

> 
> 2) Which states do they bring me to, if they don't return an error?
a) SND_PCM_STATE_OPEN
b) SND_PCM_STATE_SETUP
c) SND_PCM_STATE_PREPARED
d) SND_PCM_STATE_DRAINING

The way to reach SND_PCM_RUNNING depends on the sw_params and calls to 
snd_pcm_writei() and snd_pcm_start().

> 
> 3) How is it possible that snd_pcm_drain returns with a success value *and*
>    the snd_pcm_state() still reports SND_PCM_STATE_DRAINING ? Is this a bug?
This depends on block/non-block status.
snd_pcm_nonblock()

> 
> 4) How is it possible, that the whole time a sound is played snd_pcm_writei()
>    never returns the value -EPIPE and still, when checking the state before
>    playing the next sound, I find the device in the SND_PCM_STATE_XRUN
>    (snd_pcm_drain() gets called in the meantime).
This depends on sw_params and block/non-block status.
You can configure the device to automatically exit XRUN state whenever a 
snd_pcm_writei() is called, although this is probably only wanted for 
extremely simple apps. Most apps will want a separate XRUN recovery feature.

> 
> The problems (3) and (4) seem to arrise only under some circumstances, possibly
> when more sounds are played in a quick succession.
> 
> Thank you for help,
> Hynek Hanke
> 

sound card programming is rather complicated. the alsa api allows for 
about 6 different programming models which is why it might seem complicated.
Now, the universally best method for programming the sound card and 
sending samples to it is the callback method. This method is quite 
complicated to achieve and requires a very good knowledge of how sound 
cards work. Luckily, a 3rd party application hides all this complexity 
from the programmer. You might want to look into it. It is called jackd.

James


-------------------------------------------------------
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: The different STATES of ALSA

[Hynek Hanke]

> >(After I was told alsa-lib is not thread-safe and there is some bug in the 
> >kernel
> >implementation of the underlaying calls of snd_pcm_writei(), I'm now 
> >running the
> >non-blocking/polling approach).
> alsa-lib is perfectly thread-safe.

I was told otherwise by several ALSA developers in the thread ``How to
interrupt snd_pcm_writei'' started on June the 21st. A kernel patch was
sent to the conference and I tried it, but the problem persisted. So, as
you suggest too, I started using the non-blocking/polling approach.

> >1) In which states am I allowed to call
> >	a) snd_pcm_hw_params_any
> Only after snd_pcm_open() and snd_pcm_hw_params_alloca(&params);

In my app, I typically open one ALSA connection at the start and then play
soundfiles when needed, often interrupting them in the middle to play another
ones. Do I need to allocate a new params structure each time I want to play a
new sample or is it possible to reuse the old one?

I don't know what are the allowed states (SND_PCM_STATE_...) for this. For
example SND_PCM_STATE_XRUN is ok or is it not? (since I'll later fix it for
playing with snd_pcm_prepare() ).

> >	c) snd_pcm_prepare
> After an xrun(for xrun recovery) or after hw and sw params have been set up.

So the same states as snd_pcm_hw_params_any + SND_PCM_STATE_XRUN?
 
> >	d) snd_pcm_drop and _drain
> At any time while the stream is in RUNNING state.

Calling the function in every other state is considered an error?

> >3) How is it possible that snd_pcm_drain returns with a success value *and*
> >   the snd_pcm_state() still reports SND_PCM_STATE_DRAINING ? Is this a 
> >   bug?
> This depends on block/non-block status.
> snd_pcm_nonblock()

I didn't find anything specific about this in the documentation.

You say that snd_pcm_drain() behaves differently in the blocking and
non-blocking mode? snd_pcm_drain() returns immediatelly in non-blocking mode? I
thought it's purpose is to wait? So, do I need to wait with poll() instead?
 
> from the programmer. You might want to look into it. It is called jackd.

Yes, we know about this option.

Thanks for your help,
Hynek


-------------------------------------------------------
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: The different STATES of ALSA

[James Courtier-Dutton]

Hynek Hanke wrote:
>>>(After I was told alsa-lib is not thread-safe and there is some bug in the 
>>>kernel
>>>implementation of the underlaying calls of snd_pcm_writei(), I'm now 
>>>running the
>>>non-blocking/polling approach).
>>
>>alsa-lib is perfectly thread-safe.
> 
> 
> I was told otherwise by several ALSA developers in the thread ``How to
> interrupt snd_pcm_writei'' started on June the 21st. A kernel patch was
> sent to the conference and I tried it, but the problem persisted. So, as
> you suggest too, I started using the non-blocking/polling approach.
> 
> 
>>>1) In which states am I allowed to call
>>>	a) snd_pcm_hw_params_any
>>
>>Only after snd_pcm_open() and snd_pcm_hw_params_alloca(&params);
> 
> 
> In my app, I typically open one ALSA connection at the start and then play
> soundfiles when needed, often interrupting them in the middle to play another
> ones. Do I need to allocate a new params structure each time I want to play a
> new sample or is it possible to reuse the old one?
> 
> I don't know what are the allowed states (SND_PCM_STATE_...) for this. For
> example SND_PCM_STATE_XRUN is ok or is it not? (since I'll later fix it for
> playing with snd_pcm_prepare() ).

Once the hw_params and sw_params have been set, you cannot change them. 
You have to close and then reopen the device.

> 
> 
>>>	c) snd_pcm_prepare
>>
>>After an xrun(for xrun recovery) or after hw and sw params have been set up.
> 
> 
> So the same states as snd_pcm_hw_params_any + SND_PCM_STATE_XRUN?
At snd_pcm_hw_params_any() only unrestricted hw_params and sw_params 
have been set, to snd_pcm_prepare() will probably fail. You need to 
restrict the configuration space before runnin snd_pcm_prepare()
I.e. Set the format and number of channels.

>  
> 
>>>	d) snd_pcm_drop and _drain
>>
>>At any time while the stream is in RUNNING state.
> 
> 
> Calling the function in every other state is considered an error?
I don't know. But in any other state, it won't actually do anything.

> 
> 
>>>3) How is it possible that snd_pcm_drain returns with a success value *and*
>>>  the snd_pcm_state() still reports SND_PCM_STATE_DRAINING ? Is this a 
>>>  bug?
>>
>>This depends on block/non-block status.
>>snd_pcm_nonblock()
> 
> 
> I didn't find anything specific about this in the documentation.
> 
> You say that snd_pcm_drain() behaves differently in the blocking and
> non-blocking mode? snd_pcm_drain() returns immediatelly in non-blocking mode? I
> thought it's purpose is to wait? So, do I need to wait with poll() instead?
in non-blocking mode, no function call to alsa-lib blocks. So that goes 
for snd_pcm_drain() as well.
You can call snd_pcm_nonblock() to set blocking mode just before the 
snd_pcm_drain() if you wish, but the poll() is probably better.

>  
> 
>>from the programmer. You might want to look into it. It is called jackd.
> 
> 
> Yes, we know about this option.
> 
> Thanks for your help,
> Hynek
> 
> 

Cheers
James


-------------------------------------------------------
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: The different STATES of ALSA

[Hynek Hanke]

> >>>	d) snd_pcm_drop and _drain
> >Calling the function in every other state is considered an error?
> I don't know. But in any other state, it won't actually do anything.

Can someone please clarify this?

With Regards,
Hynek


-------------------------------------------------------
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: The different STATES of ALSA

[James Courtier-Dutton]

Hynek Hanke wrote:
>>>>>	d) snd_pcm_drop and _drain
>>>
>>>Calling the function in every other state is considered an error?
>>
>>I don't know. But in any other state, it won't actually do anything.
> 
> 
> Can someone please clarify this?
> 
> With Regards,
> Hynek
> 
> 
You can read the documentation regarding this.
e.g. The doxygen documentation should help.
Alternatively, read the comments at the top of alsa-lib/src/pcm/pcm.c



-------------------------------------------------------
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: The different STATES of ALSA

[Jaroslav Kysela]

On Sun, 31 Jul 2005, James Courtier-Dutton wrote:

> Once the hw_params and sw_params have been set, you cannot change them. You
> have to close and then reopen the device.

It's not true. You must call snd_pcm_hw_free() before applying of new 
hardware parameters. Software parameters can be changed at any time.

						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: The different STATES of ALSA

[Jaroslav Kysela]

On Sun, 31 Jul 2005, Hynek Hanke wrote:

> > >>>	d) snd_pcm_drop and _drain
> > >Calling the function in every other state is considered an error?
> > I don't know. But in any other state, it won't actually do anything.
> 
> Can someone please clarify this?

drain function can be called at any time except immediately after open 
(the hardware parameters must be set)...

						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