Re: The different STATES of ALSA

[James Courtier-Dutton <James@superbug.co.uk>]

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