[pulseaudio-discuss] [PATCH] Don't use tsched on unsafe ALSA plugins

[David Henningsson]

On 2014-04-21 09:04, Alexander E. Patrakov wrote:
> 21.04.2014 07:49, David Henningsson wrote:
>> On 2014-04-20 21:26, Alexander E. Patrakov wrote:
>>> Thus, it is not possible to tell the hardware device (that can use
>>> rewinds) from a properly wrapped software encoder (that can't rewind and
>>> doesn't pretend to be able to rewind), because for both cases
>>> snd_pcm_rewindable() would return 0 at the moment PulseAudio needs to
>>> make a decision.
>>
>> The moment PulseAudio needs to make a decision is when a rewind is
>> requested.
>
> No. The decision definitely needs to be at the device-open time.
> Otherwise this will happen:
>
> """
> Now I need to rewind in order to accommodate a new low-latency client.
> Oops, I can't, and I have so much wrong data in my hardware buffer! I
> should not have created such a big buffer, but now it too late to change
> anything.
> """

So you want to always go low-latency (and high CPU/power consumption), 
in case rewind is not possible?

This sounds like a trade-off.

The other possibility would be to just wait until the hw buffer is empty 
and then continue with low latency. If "accomodate a new low latency 
client" happens rarely, and the maximum buffer size is < 2 seconds, then 
maybe this is not much of an issue, compared to the drawback of forcing 
low latency when it's not needed.

> And indeed, the current code already has logic to choose different
> buffer sizes for tstamp and irq-driven modes:
>
> http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/alsa/alsa-util.c#n298
>
>
> On my hardware, the buffer sizes for these two modes differ by a factor
> of 1000.

What hardware is that? If we don't do that already, we should cap the 
tsched buffer size to ~ 2 seconds, or we'll just use more memory than we 
need. Divide that with 1000 and you claim to have a irq-driven buffer 
size of 2 ms. Which is way too low.

> So what I want is really not related to tsched. "Don't choose a big
> buffer size and high latency, and don't try to rewind, if we know in
> advance that ALSA cannot rewind or only pretends to be able to rewind"
> would be a better description of my patch.
>
>> Whether or not to enable tsched should not matter in this case, unless
>> I'm missing something. (And this is probably what Raymond is trying to
>> say too.)
>> Or, put in another way, why would it be better for the ALSA device to be
>> in interrupt driven mode just because it can't rewind?
>
> I have two slightly-conflicting answers to this.
>
> First answer:
>
> Rewinds and timestamp-driven scheduling are only the means to get
> dynamically reconfigurable latency, which is useful for less dropouts
> when there are no low-latency clients, lower power usage, and possibly
> other good things. Due to the inability to do rewinds, the "dynamic
> client-driven latency" goal becomes unachievable, so there is simply no
> good point to use timestamp-based scheduling in this case.
>
> Of course timestamp-based scheduling will work without rewinds, but, as
> PulseAudio would then need (due to inability to do rewinds) to lock into
> the constant minimum latency, the wakeup points will be evenly spaced in
> time. And that's almost equivalent to the IRQ-based scheduling (with a
> small exception listed in the second answer).
>
> Or to put it another way. Currently, PulseAudio supports two models:
> "big buffer + timestamp-based scheduling + rewinds" and "small buffer +
> IRQ-driven scheduling + no rewinds". Intermediate models such as "small
> buffer + timestamp-based scheduling + no rewinds" are possible, but they
> would IMHO only unnecessarily inflate the test matrix.

Eh? Rewinds are not disabled under IRQ-driven scheduling.

> Second answer:
>
> Well, it is not better. In timestamp-based scheduling mode, we can
> dynamically adjust latency. The limitation is that, without rewinds, our
> decisions to reduce latency (e.g. due to a new client) would apply too
> late. But even with this limitation, it means that we can try to keep as
> low latency as it actually works on the given hardware (similar to the
> current watermark logic), disregarding any client-specified latency.
>
> The problem is that, if one wants to use timestamp-based scheduling
> without rewinds, one needs to decouple the current watermark logic, the
> buffer size choice logic, and the "don't use latency lower than
> requested by any client" logic, because the later only makes sense when
> rewinds are possible.

I think we can still dynamically switch latency even without rewinds. 
It'll just take slightly longer to start new streams.

Anyway, here's another idea:

During PulseAudio's first five seconds, all streams are running as some 
kind of "startup test". How about we use that to probe the rewind too? 
And if snd_pcm_rewindable says we can't rewind even with a full buffer, 
then we choose a medium latency as our highest latency, e g 150 - 200 
ms, instead of the 2 seconds?

// David