On Mon, 6 Jan 2003, Paul Davis wrote:
> >> this seems wrong to me. what should fail is an attempt to set the
> >> sample rate unless the hardware is its own clock Master. if no attempt
> >> is made to set it, then the application gets whatever the hardware is
> >> running at, whether that is externally controlled or some h/w specific
> >> default.
> >
> >I think that it's wrong when application receives stream with another
> >parameters than requested.
>
> how would that happen?
>
> if it asks for a specific rate via hw_params, it will either get it,
> or fail. if it doesn't ask for a specific rate, it will get whatever
> the h/w is using (some default and/or the value set by an external clock).
>
> > Imagine that you're doing a software sample
> >rate conversion and we really need to know the exact rate for this job.
>
> you can get it by just asking the device what rate its using, or by
> knowing that your hw_params request completed successfully.
Ok, we speak about same things. It's ok when hw_params request returns an
error code when rate doesn't match.
> >1) offer all available sample rates in open() or reduce them as suggested
> > by Anders
> >2) in trigger(START)
> > - check if current sample rate match with hw_params - if not - fail
> >3) in interrupt callback
> > - same job as trigger does
>
> what about checking in read/write operations, in case the external
> clock has changed?
Yes, the check might be in copy/silence/pointer callbacks, too.
Jaroslav
-----
Jaroslav Kysela <[EMAIL PROTECTED]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
-------------------------------------------------------
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
