[Alsa-devel] Problems with snd_pcm_hw_params_can_pause (). etc.

[James Courtier-Dutton]

Currently, the state of play is that "snd_pcm_hw_params_can_pause ()" should not be called until one has first done the first "snd_pcm_hw_params()"

I start with
snd_pcm_hw_params_any(this->audio_fd, params);
then go about setting params, e.g.
snd_pcm_hw_params_set_access()
snd_pcm_hw_params_set_format()
etc.
Then
snd_pcm_hw_params()
then
snd_pcm_hw_params_can_pause (params)

If the "snd_pcm_hw_params_can_pause (params)" goes before the "snd_pcm_hw_params()" an invalid result is returned. I.E. the result is always 1 even for cards which don't support it.

I think the documentation should make it clear when one should use "snd_pcm_hw_params_can_pause ()".
or maybe "snd_pcm_hw_params_any()" should be modified to correctly fill the "can_pause" bit.
Maybe I have missunderstood the API, but I would prefer the approach of first retrieving the current hw params, then go about modifying it, then writting it back. If one has not set any hw params yet, it would fill the structure with the most general case, then allow the application to set params to further restrict the config.
I had assumed that "snd_pcm_hw_params_any()" did the retrieving of the current hw params, but reset to the least restrictive settings. I don't think "can_pause" is anything an application can set, the hardware on the card decides that, so the "snd_pcm_hw_params_any()" should cause "can_pause" to return a valid setting that matches the hardware, instead of having to wait for the params to be written to the card with "snd_pcm_hw_params()" before "can_pause" is set accurately.

Cheers
James




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel