Re: Master Plan on rewinding

[Lars-Peter Clausen <lars@metafoo.de>]

On 09/07/2014 05:16 PM, Alexander E. Patrakov wrote:
[...]
> 2. PulseAudio blindly assumes that it can rewind up to hwbuf_frames -
> (snd_pcm_avail() + rewind_safeguard) frames. The rewind safeguard is needed
> due to reasons that I don't completely understand, but one of them is
> imprecise reporting of the hardware pointer, and another one is that the
> hardware transfers several bytes at a time, and the bytes we need to
> overwrite may be already cached by the hardware.
>

Also at the time you will process the result form snd_pcm_avail() will be 
more than what was reported as the audio DMA keeps going in the background.

[...]
> For the allegedly existing cards where the pointer granularity is always the
> same as the period size, Raymond's method will not work. However, I don't
> know any concrete example of such card (I didn't look at snd-firewire in
> detail, though). And in any case, my opinion is that this "pointer
> granularity = period size" limitation on such cards can be treated as a
> driver bug that needs to be fixed (by someone who knows the driver, not by
> me). On cards where pointer updates happen only on interrupts, the driver
> should not configure the card in such a way that one period visible to the
> userspace corresponds to one interrupt. Instead, it should always configure
> the card for the minimum possible period size, and report only part of the
> period interrupts to period_elapsed(). I.e.: userspace asked for 2 periods
> 64 ms each, but let's configure the card for, say, 64 periods 2 ms each, and
> use the "extra" interrupts only for updating the pointer.
>

There are quite a few ASoC drivers that do have this restriction. For some 
of the drivers the restriction comes from the hardware itself for others it 
is while the hardware in theory supports it nobody bothered so far to 
implement this.

I do not agree that this should be treated as a driver bug and that those 
drivers should increase the interrupt rate. Mainly because this is policy 
and the interrupt rate is configured by the application by setting the 
period size and the driver should not have to guess what kind of latency 
requirements the application has. If the application has lower latency 
requirements it needs to set a smaller period size. Unnecessarily increasing 
the interrupt rate has for example has a impact on power consumption which 
is something you'd like to keep low on battery powered devices.

We should though expose the granularity with which the pointer is updated to 
userspace so it can make educated decisions on how to configure the period size.

- Lars