On Wed, Mar 13, 2013 at 09:00:29PM -0700, chris hermansen wrote:
> Looking at the messages, I find it odd that the reset doesn't happen
> cf. we just jump to the complaint about the rates not matching.
>
> Mar 13 20:33:51 temuko kernel: [ 372.014273] current rate 96000 is
> different from the runtime rate 44100
>
> Looking at the code...
>
> Torstein, I am not completely following all the details here but I see
> in the patched clock.c
>
> if (cur_rate != rate) {
> snd_printk(KERN_WARNING
> "current rate %d is different from the
> runtime rate %d\n",
> cur_rate, rate);
> }
>
> /* Some devices doesn't respond to sample rate changes while the
> * interface is active. */
> if (cur_rate != prev_rate) {
> switch (chip->usb_id) {
> /* C-Media CM6610/CM6620/CM6631 */
>
> I am not following why you check for cur_rate and rate being unequal
> in the first case and cur_rate and prev_rate being unequal in the
> second.
>
> Is this intentional, and I'm missing the wonderful subtlety of it all?
The operations done before that bit you quoted is essentially
prev_rate = get_rate();
set_rate(rate);
cur_rate = get_rate();
The first check is a consistency check to ensure that the rate we read
back is the same as the one we just set. In a working set-up, this
shouldn't happen.
We then check for a change in sample rate by comparing the value read
before the set-operation to the value read after the set-operation.
If your device consistently fails the sanity check by returning a wrong
value in the second get_rate(), it might be that the device has some
issues with responding properly to a rate request after a rate set, but
as noted earlier:
> > After the sample rate is set to 44.1k, it reads back the previous rate
> > of 96k. The reset is then skipped, as the previous rate and the current
> > rate is equal, even if the target rate is different. If this was the
> > only issue, it could be avoided by comparing the previous rate and the
> > target rate when determining if the reset is necessary. But the
> > mangled rate read and the 'cannot get freq' in your previous run
> > suggests that there are other issues.
If we can find some other explanation for the 'cannot get freq' and the
large negative rate you saw earlier, it might help to replace the
if (cur_rate != prev_rate) {
with
if (rate != prev_rate) {
so that we do the reset if the target rate is different from the
previous rate, ignoring what the device thinks its current rate is.
Torstein
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Alsa-user mailing list
Alsa-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user
