On Sun, 13 Oct 2002, James Courtier-Dutton wrote:
> Jaroslav Kysela wrote:
>
> >On Sat, 12 Oct 2002, James Courtier-Dutton wrote:
> >
> >
> >
> >>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
> >>
> >>
> >
> >But what's "current configuration"? What you want to prefer? rate?
> >channels? period_size? No, application should give these hints to driver.
> >
> >
> >
> >>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.
> >>
> >>
> >
> >All these functions needs exactly one configuration at input.
> >The snd_pcm_hw_params() function chooses one configuration and sets it to
> >hardware. I've updated documentation.
> >
> > Jaroslav
> >
> >
> >
>
> Thanks for the documentation update. I currently use the inline docs
> contained in alsa-lib/pcm/pcm.c. Is that the ones you update ? I only
> mentioned it because I made the mistake of putting the can_pause()
> before the snd_pcm_hw_params() without knowing that it would not work
> correctly, so I just wanted the documentation to be updated so that no
> one else would make the same mistake.
> I think the point I was trying to make is that one should be able to call
> snd_pcm_hw_can_pause() at any time. One should not have to wait until
> one has snd_pcm_hw_params() has been called. At this point I am assuming
> that the result of "snd_pcm_hw_can_pause()" is always constant, and does
> not depend of any hw_params that have been set. But now I come to think
> of it, this might not be true. I think the SB Live can do pause/resume
> in normal mode, but cannot do it in AC3 passthru mode using the DSP TRAM.
>
> But as a general point, this does not really matter too much to me now,
> because I will be using snd_pcm_hw_params_current() that you have kindly
> added to the API. ;-)
> I will have to wait until the next release of alsa09 before I actually
> code the change, because I cannot expect all my users to install alsa09
> from CVS. :-(
>
> As a sub note, maybe snd_pcm_can_pause() should return some sort of
> error code, or throw an assert if the application programmer has put it
> before snd_pcm_hw_params() instead of returning a perfectly useable
> result that is baseless. I think an assert() would be acceptable, as
> this is a application programming error and not a user initiated error.
> It would then force the application programmer to "get it right first
> time". ;-)
Updated. I hope that it will work.
Jaroslav
-----
Jaroslav Kysela <[EMAIL PROTECTED]>
Linux Kernel Sound Maintainer
ALSA Project http://www.alsa-project.org
SuSE Linux http://www.suse.com
-------------------------------------------------------
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
