(CC stable dropped; this is not how to submit stable patches.)

Mauro Carvalho Chehab wrote:

The Auvitek 0828 chip, used on HVR950Q actually need two quirks and not just one.

The first one, already implemented, enforces that it won't have channel swaps at the transfers.

However, for TV applications, like xawtv and tvtime, another quirk is needed, in order to enforce that, at least 2 URB transfer intervals will be needed to fill a buffer.

• 	period = 2 * MAX_URBS * fp->maxpacksize;
  

• 	min_period = period * 90 / 100;
  

• 	max_period = period * 110 / 100;
  

I don't quite understand what you mean with "URB transfer interval".

All USB audio devices transfer packets in intervals between 125 µs and 1000 µs.

MAX_URBS is a somewhat random value that is not directly derived from either a hardware or software constraint.

Are you trying to enforce two packets per URB?

Why are you setting both a minimum and a maximum?

Isn't this affected by the constraints of the playback device?

Without it, buffer underruns happen when trying to syncronize the audio input from au0828 and the audio playback at the default audio output device.

This looks like a workaround for a userspace bug that would affect all USB audio devices. What period/buffer sizes are xawtv/tvtime trying to use?

Regards, Clemens

Em Mon, 16 Jun 2014 09:22:08 -0400 Devin Heitmueller dheitmueller@kernellabs.com escreveu:

...

This looks like a workaround for a userspace bug that would affect all USB audio devices. What period/buffer sizes are xawtv/tvtime trying to use?

I have similar concerns, although I don't know what the right solution is. For example, the last time Mauro tweaked the latency in tvtime, it broke support for all cx231xx devices (note that tvtime and xawtv share essentially the same ALSA code):

http://git.linuxtv.org/cgit.cgi/tvtime.git/commit/?id=3d58ba563bfcc350c180b5...

It seems like there is definitely something wrong with the latency/period selection in both applications, but we need some insight from people who are better familiar with the ALSA subsystem for advice on the "right" way to do low latency audio capture (i.e. properly negotiating minimal latency in a way that works with all devices).

Well, I suspect that the issue is at Kernel level.

Let's see the au0828 case: 48 kHz, 2 bytes/sample, 2 channels, 256 maxpacksize, 1 ms URB interval (bInterval = 1).

In this case, there is 192 bytes per 1ms period.

Let's assume that the period was set to 3456, with corresponds to a latency of 18 ms.

In this case, as NUM_URBS = 12, it means that the transfer buffer will be set to its maximum value of 3072 bytes per URB pack (12 * 256), and the URB transfer_callback will be called on every 16 ms.

So, what happens is:

- after 16 ms, the first 3072 bytes arrive. The next packet will take another 16ms to arrive; - after 2 ms, underrun, as the period_size was not filled yet.

The thing is that any latency that between 16 ms and 32 ms are invalid, as the URB settings won't support it.

Regards, Mauro

Em Mon, 16 Jun 2014 09:39:17 +0200 Clemens Ladisch clemens@ladisch.de escreveu:

(CC stable dropped; this is not how to submit stable patches.)

Mauro Carvalho Chehab wrote:

...

The Auvitek 0828 chip, used on HVR950Q actually need two quirks and not just one.

The first one, already implemented, enforces that it won't have channel swaps at the transfers.

However, for TV applications, like xawtv and tvtime, another quirk is needed, in order to enforce that, at least 2 URB transfer intervals will be needed to fill a buffer.

...

• 	period = 2 * MAX_URBS * fp->maxpacksize;
  

• 	min_period = period * 90 / 100;
  

• 	max_period = period * 110 / 100;
  

I don't quite understand what you mean with "URB transfer interval".

All USB audio devices transfer packets in intervals between 125 µs and 1000 µs.

In this case, it uses a 1000 µs, as defined at the USB descriptor for the au0828 devices (bInterval).

FYI, those TV devices are too limited, in terms of audio: they only provide: - 48 kHz rate; - 16 bits/sample; - 2 channels; - maxumum URB size: 256 bytes.

Its internal firmware is also too buggy. We needed to add several workarounds at both analog and digital stream support for some conditions that caused the chip to stop producing URBs, or made it to cause ESHUTDOWN errors while streaming.

MAX_URBS is a somewhat random value that is not directly derived from either a hardware or software constraint.

Yes, I noticed that.

Are you trying to enforce two packets per URB?

No, I'm trying to enforce that it won't complain about underruns, while keeping the latency constrained.

This is the same kind of fix we needed to do with em28xx-audio.c some time ago.

In this case, I'm enforcing that the URB callback will receive 3072 samples, and that the PCM timer won't be triggered too early, e. g. it will wait for the needed time for the URB callback to be called twice.

Why are you setting both a minimum and a maximum?

When I wrote em28xx patches, I did several tests with different max latency constraints. On some cases, when it selected an odd number of periods, we would still have some troubles. So, it sounds safer to keep the same type of logic here.

Anyway, just setting the minimum is enough for xawtv/tvtime to work with the default -alsa-latency parameter.

Isn't this affected by the constraints of the playback device?

Hard to tell without having a test hardware with different constraints. All playback hardware I currently have supports 48 kHz rate, and supports a period size in the range of this The application takes those constraints into account

...

Without it, buffer underruns happen when trying to syncronize the audio input from au0828 and the audio playback at the default audio output device.

This looks like a workaround for a userspace bug that would affect all USB audio devices. What period/buffer sizes are xawtv/tvtime trying to use?

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.

It tries to enforce a choice where the max latency would be constrained. The max latency is 30ms, by default, but the user can change it via -alsa-latency parameter.

Regards, Mauro

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

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.

Em Mon, 16 Jun 2014 23:16:02 +0600 "Alexander E. Patrakov" patrakov@gmail.com escreveu:

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.

I see. Well, you're talking about a xrun that would happen after several seconds, and caused by a clock drift between capture and playback xtals.

The issue we're facing happens dozen of times a second, and it is caused by something else: despiste what period_size says, with this board, the sampling period is not continuous.

The reason for that is simple: 1ms is the minimal interval for this board can feed interrupts, and the minimal period size = 192 bytes (as anything lower than 192 bytes would cause data to be dropped).

As the maximum limit per URB transfer is 3072 bytes (12 URB packs, with 256 bytes each), we have:

Period time = (num_bytes + 191) / 192 ms

For num_bytes between 192 and 3072.

After 3072, the URB endpoint will always use 3072 bytes per URB transfer, with takes 16 ms to be filled.

So, the period time is given by: Period time = (num_bytes / 3072) * 16 ms

In other words, the period ranges from 1 to 16 ms, in 1ms step, up to 3072 bytes. After that, the period is always multiple of 16 ms.

Trying to set it to any value between 17 ms and 31 ms causes xruns, because the buffer will only be filled the next time the URB callback is called (and this happens on every 16 ms).

That's what happens with xawtv currently: while the hardware has a 16ms-multiple constraint for the period size, but as there's no constraints at the ALSA Kernel code enforcing a period size multiple of 16 ms, xawtv will set it to its default latency (30 ms).

That works fine for the first transfer, but it gets an underrun before the second one. So, we have about 30 underruns per second.

There's nothing that can be done on userspace, as the 16 ms multiple request is specific to this card. Other cards use different URB constraints, as different maxsize and/or different number of URBs would result on a different period size.

So, changing it in userspace from one card breaks for the others.

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.

After having this big xrun issue fixed, I'll look into it. I need to check if xawtv/tvtime license is GPLv2.

...

...

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.

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

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

Ok, I'll look into it after fixing this issue.

Regards, Mauro

Em Mon, 16 Jun 2014 15:04:44 -0400 Devin Heitmueller dheitmueller@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