[alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes

[Mauro Carvalho Chehab]

Em Mon, 16 Jun 2014 15:04:44 -0400
Devin Heitmueller <dheitmueller at kernellabs.com> escreveu:

> >> The official TV playback application, found on the CD with drivers,
> >> captures samples from the card into its buffer, and plays from the other
> >> end of the buffer concurrently. If there are, on average for a few
> >> seconds, too few samples in the buffer, it means that they are consumed
> >> faster than they arrive, and so the SAA chip is told to produce them a
> >> bit faster. If they accumulate too much, the SAA chip is told to produce
> >> them slower. That's it.
> >
> > Ok. Well, xc5000 (with does the audio sampling) doesn't have it, AFAIKT.
> >
> >> >
> >> > The xc5000 tuner used on this TV device doesn't provide any mechanism
> >> > to control audio PLL. It just sends the audio samples to au0828 via a
> >> > I2S bus. All the audio control is done by the USB bridge at au0828,
> >> > and that is pretty much limited. The only control that au0828 accepts
> >> > is the control of the URB buffers (e. g., number of URB packets and
> >> > URB size).
> 
> It's probably worth noting that Mauro's explanation here is incorrect
> - the xc5000 does *not* put out I2S.  It outputs an SIF which is fed
> to the au8522.  The au8522 has the audio decoder, and it's responsible
> for putting out I2S to the au0828.
> 
> Hence the xc5000's PLL would have no role here.
> 

Ah, OK. I didn't notice that hvr950q was using SIF. In this case,
then maybe au8522 may have some PLL fine tune register to adjust the
sampling rate.

> In fact, you should see the exact same behavior on the A/V input,
> since the au8522 is responsible for the I2S clock which drives the
> cs5503 (the 5503 is in slave mode).

I suspect that the best is to use a resampling code to avoid the
frequency drift clock issue, as it is generic enough to cover both
cases, and won't require hardware-assisted support.

Yet, as I posted on my previous email, this is not yet the kind of
bug that we're facing right now. If I'm doing the calculus correct,
a -10Hz difference at a 48 kHz sampling rate would take ~150 seconds
to cause an underrun (a 16 ms period_bytes lost).

Regards,
Mauro