[pulseaudio-discuss] [PATCH v6 1/2] pipe-source: generate silence when no writers connected

[Georg Chini]

On 17.02.2018 11:08, Raman Shuishniou wrote:
> 16.02.2018 23:50, Georg Chini пишет:
>> On 16.02.2018 17:37, Raman Shishniou wrote:
>>>
>>> On 02/16/2018 12:00 PM, Georg Chini wrote:
>>>> On 14.02.2018 23:16, Raman Shyshniou wrote:
>>>>> Currently the pipe-source does not produce any data if no
>>>>> writer is connected. This patch enable silence generator
>>>>> when last writer closed pipe. It will stop automatically
>>>>> when any data appears.
>>>>> ---
>>>>
>>
>> I agree that the timer can be disabled and that the time stamp
>> gets meaningless the way it is set now when reading from the
>> pipe. But we must continue without interruption when we switch
>> from pipe to silence, so we should set the time stamp to
>> something meaningful before switching to silence. (Switching
>> between pipe and silence properly would not have worked with
>> my code above.)
>
> Switching from pipe to silence can be easily done by generation a 
> little less silence in first iteration.

Yes, that is what the pseudo code is doing.

> It's not working when switching from silence to pipe.
>
> Actually we don't know if the writer can buffer data and/or trying to 
> do some congession control. When the pipe have some data - source must 
> read and post it immediately.
>
> While switching from silence to pipe we can wait until we run out of 
> silence, but pipe has data to post right here and right now. For 
> example, if the latency is 20ms and we wait for 10ms before starting 
> the first read, the writer will just write more data to pipe while we 
> waiting (+10ms). We will read and post that extra data on the next 
> iteration.
>
> So we need to drop extra data from pipe or buffer the head of data 
> each iteration. Both solutions are bad. I think we'll just give the 
> source-output(s) a chance to deal with the extra silence we generated.

You are (again) right, waiting for the silence to be played only moves 
the problem to the
first pipe read. What happens when pipe data is coming in is that the 
latency (as seen by
the source output) suddenly jumps up by possibly as much as one full 
source latency.

If the receiving side does not compensate somehow (like module-loopback 
does), switching
between pipe and silence multiple times will lead to accumulated 
latency. Therefore I do not
think it is acceptable to hope that the source-output can deal with the 
extra silence.

To me it appears like the only correct solution is to implement some 
local buffering, so that
we can rewind the source and drop the remaining silence when pipe data 
comes in.

It looks rather difficult to implement silence generation correctly, 
maybe we should drop
the whole idea and stick with your original suspend/unsuspend approach. 
Implementing
some local buffering would however increase underrun stability (at least 
when used with
module-loopback). What do you think?

One more point I have been thinking about:
The pipe sets POLLIN as soon as data is available, which means we will 
possibly run an
iteration of the thread function every couple of samples, leading to 
high CPU load,
depending on the way the writer delivers the data.
It could be changed to a timer based approach - there are the 
pa_smoother functions
which account for the difference between system clock and writer clock. 
(See for
example the alsa-sink code, there we have a similar situation.) So if we 
stick to the idea
of generating silence, it might be worth considering a timer based approach.