Em Mon, 16 Jun 2014 20:38:52 +0600 "Alexander E. Patrakov" <patra...@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. >
alsa-info.txt.7qy7T0g90U
Description: Binary data
