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

[Raman Shuishniou]

17.02.2018 15:31, 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.

The accumulated latency can be decreased when the writer disconnects.


> 
> 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?
> 

I think we don't need to implement local buffering only to make a 
correct switching between silence and pipe. Fifo assumes local writer
and the buffering should be implemented on it's side if it's necessary
for underrun stability.

Suspend/resume algorithm will be enough to not confuse source-outputs
when no writers connected to pipe.

I'll try to reimplement original autosuspend patch to make it more 
platform-independed.

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

The writer also should use the CPU too much to write a couple of samples 
at each iteration. I don't think we need to worry about this in
pipe-source module.

--
Raman