[pulseaudio-discuss] [PATCH] module-virtual-sink: Speed up draining

[David Henningsson]

On 2014-10-02 17:21, Alexander E. Patrakov wrote:
> 02.10.2014 19:58, David Henningsson wrote:
>> The drain speed increase done a while ago, only worked when directly
>> connected
>> to ALSA sinks. Playing through an module-virtual-sink would cause
>> slower drains.
>>
>> This fix has two parts:
>>   1) We now refuse to process handed out silence. This has the effect
>>      that it tells ALSAs sink input that we're draining, and that we
>> want to
>>      be woken up exactly at this sample based point in time.
>>   2) When we're being called to process input underruns, we know this has
>>      happened, so we can just forward the call up the sink chain to get
>>      to protocol-native, which can acknowledge that the drain has
>> completed.
>>
>> This fix is incomplete, because if more than one sink input is playing
>> back
>> into the sink, only the last one will be drained in time. But it's better
>> than nothing.
>>
>> Signed-off-by: David Henningsson <david.henningsson at canonical.com>
>> ---
>>
>> Happy for testing of this patch - Ubuntu runs HDA-intel with 64K
>> buffers instead of the 2M that
>> some distros use, so I'm not seeing that much difference that you do
>> anyway.
>>
>> Also, when I was testing, I also noticed a bigger startup latency when
>> playing
>> back through a virtual sink. This is nothing I have looked deeper at.
>
> Hello David,
>
> I have looked at the patch, but came to the conclusion that I cannot
> provide a good review now. Please find some criticisms below, but they
> are not serious. In fact, I will accept any of the following responses
> to the criticisms:
>
> 1. Let's ignore the issue.
>
> 2. Let's apply a big hammer and just disallow high (or, for that matter,
> dynamic) latencies on virtual sinks, effectively masking the issue.
>
> 3. (a fix)
>
> In fact, I was going to suggest (2) at the miniconf, together with
> punting on rewind support for virtual sinks. In too many cases, this is
> just impossible to implement due to external reasons. But that's a
> rather controversial decision that would need to be discussed.
>
> This may be valid for module-virtual-sink, but is definitely invalid for
> any sink that does non-trivial processing. Consider an imaginary virtual
> sink that adds some reverb to the sounds that come through it: the
> output does not end when the input ends. I guess we need to define first
> what "drain" really means in such cases, or agree to ignore the issue
> (which is fine if there is a comment about that).
>
> I'd prefer the definition when "drained" means "the first output sample
> affected by the last valid input sample has been crossed by the hardware
> pointer of the real sink", i.e. so that it does not include the tail of
> the reverb. But this may be technically too complex to implement.

I'm not sure what you actually mean, since you say that your response is 
not serious, but there are certainly many cases where underrun before 
and after filter do happen simultaneously (a simple gain filter, e g), 
and even more when things happen simultaneously "enough", i e, when 
there are just a few samples to worry about, like an EQ, and nobody 
(except possibly you ;-) ) would notice that we cut it off prematurely.
Without knowing the details about echo cancelling, I'd assume 
module-echo-cancel, which Yui was talking about, falls into that 
category too.

For reverbs, delays, and those type of effects, the implementation above 
is indeed not okay. After all, it's a band aid rather than a complete 
fix. I'd suggest that those effects would, at this point, accept handed 
out silence and have longer drains as a consequence.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic