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

["Alexander E. Patrakov" <patrakov@gmail.com>]

16.06.2014 22:24, Mauro Carvalho Chehab wrote:
> Em Mon, 16 Jun 2014 20:38:52 +0600
> "Alexander E. Patrakov" <patrakov@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

No, it doesn't. The card only pretends to give out samples at 48000 Hz, 
but, due to the imperfect quartz, actually gives them out at something 
like 48010 or 47990 Hz (if we take the Realtek's idea of 48 kHz as the 
source of truth), and that even changes slightly due to thermal issues. 
The goal here is to measure the actual sample rate and to resample from 
it to 48 kHz. The "alsaloop" program (part of alsa-utils), when compiled 
with libsamplerate, does exactly that. If GPLv2+ is OK for you, you can 
copy the code.

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

Some chips (e.g. SAA7133) have a register that allows fine-tuning the 
actual rate at which they sample the sound (while applications still 
think that it is nominally at 32 kHz). This register is not exposed at 
the ALSA level, but exposed as the "audio_clock_tweak" parameter of the 
saa7134 module. Linux applications normally don't use this register, but 
Windows uses this register as follows.

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.

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

OK, as you can't tweak the PLL, you have to resample. The idea is, 
again, simple. Record samples to a buffer if you can, and play them 
through a variable-rate resampler concurrently if you can. You can use 
poll() to figure out the "if you can" part. If samples accumulate too 
much or if the buffer becomes too empty, change the resampling ratio 
slightly in order to compensate. As I said, the code is here:

http://git.alsa-project.org/?p=alsa-utils.git;a=tree;f=alsaloop

-- 
Alexander E. Patrakov