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

[Mauro Carvalho Chehab]

Em Mon, 16 Jun 2014 20:38:52 +0600
"Alexander E. Patrakov" <patrakov at gmail.com> escreveu:

> 16.06.2014 20:21, Mauro Carvalho Chehab wrote:
> > Both xawtv and tvtime use the same code for audio:
> > 	http://git.linuxtv.org/cgit.cgi/xawtv3.git/tree/common/alsa_stream.c
> >
> > There's an algorithm there that gets the period size form both the
> > capture and the playback cards, trying to find a minimum period that
> > would work properly for both.
> 
> I don't see any adaptive resampler (similar to what module-loopback does 
> in pulseaudio) there. 

Are you referring to changing the sample rate? This doesn't
affect my test scenario, as the playback interface supports the
only PCM format/rate used by the TV card (48kHz, 16 bits/sample, stereo):

Codec: Realtek ALC269VC
Default PCM:
    rates [0x5f0]: 32000 44100 48000 88200 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM

> Without that, or dynamically controlling the audio 
> capture clock PLL in the tuner, xruns are unavoidable when transferring 
> data between two unrelated cards.

What do you mean by dynamically controlling the audio capture clock PLL
in the tuner? That doesn't make any sense to me.

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).

> 
> So, until any further evidence appears, I think it is a common bug in 
> these audio codes.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alsa-info.txt.7qy7T0g90U
Type: application/octet-stream
Size: 33796 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140616/f5a8b46d/attachment-0001.obj>