On 17.02.2018 22:05, Raman Shuishniou wrote:
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.
---
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.
OK.
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.
If the writer writes larger chunks of data to the pipe, the calculation
of the latency
should be reconsidered. Currently it returns the amount of data in the pipe.
This means, the latency will remain constant for some time and then
suddenly jump
up, when the next block is written. Would it not be better to return the
time since
the last pipe read as latency? You can actually test what is better by
observing the
end-to-end latency that module-loopback reports. The numbers should not
vary too
much after a minute of runtime - around +/-500 usec is a normal value if
you set
adjust_time=1. If you are seeing jumps of several ms, the source does
not report
latency correctly.
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
