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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
