[pulseaudio-discuss] [PATCH v6 1/2] pipe-source: generate silence when no writers connected
rommer at ibuffed.com
Sat Feb 17 21:05:05 UTC 2018
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
>> 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.
> 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
> 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
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
More information about the pulseaudio-discuss