On 22.03.2016 12:57, Georg Chini wrote:
On 22.03.2016 12:51, Tanu Kaskinen wrote:
On Tue, 2016-03-22 at 12:33 +0100, Georg Chini wrote:
On 22.03.2016 12:20, Tanu Kaskinen wrote:
On Tue, 2016-03-22 at 10:11 +0100, Georg Chini wrote:
Hi,
when a sink is started, there is some delay before the first
sample is
really played.
This delay is a constant part of the sink latency that will be always
present, so the
minimum sink latency cannot go below that start delay.
Would it be acceptable to adjust the latency range for the device
after
each unsuspend
to reflect that?
USB devices (those I have access to) for example have a startup
delay in
the range of
10ms, but have a latency range that starts at 0.5ms which does not
make
a lot of sense
in my opinion.
I don't understand why the startup delay would limit the minimum
latency once the stream is flowing. Imagine a sound card that is
powered by a nuclear power plant. I don't know how long it takes to
start a nuclear power plant, but let's say it takes a couple of days.
Now the sound card startup delay is a couple of days, but there's no
reason that the audio latency has to be a couple of days once the
power
plant is running. Where would all that audio be buffered anyway?
Hi Tanu,
you are wrong.
I don't believe you :)
Look at the code of alsa-sink. It never drops samples. The only way to
compensate
for the startup delay would be to drop audio as long as the sink is
not yet playing,
but that is not done. I could try to implement that however and then
you would be
right, but with the current code at least for the alsa-sink the
startup delay will persist.
In fact, the first data is pushed to the sound card even before
snd_pcm_start(), so
dropping audio seems to be difficult. We would have to feed silence to
the card until
we are sure it is playing and drop audio during that period.
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
