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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



16.06.2014 22:24, Mauro Carvalho Chehab wrote:
Em Mon, 16 Jun 2014 20:38:52 +0600
"Alexander E. Patrakov" <patrakov@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux