On 23.03.2016 12:26, Tanu Kaskinen wrote:
On Wed, 2016-03-23 at 11:34 +0100, Georg Chini wrote:
On 23.03.2016 11:04, Tanu Kaskinen wrote:
On Tue, 2016-03-22 at 12:57 +0100, 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.
The sink isn't responsible for dropping samples in any case. The
connection between the start delay and the runtime latency just doesn't
exist at the sink level.
Again, sorry, but you are wrong. The startup delay does not vanish
magically. I can only point you to the code. I have been working with it
for a couple of month now and I know what I am saying. What happens
for USB devices with timer based scheduling is the following:
1) First audio data is written to the card
Ok, now the buffer is full.
It looks like it isn't, see below.
2) snd_pcm_start() is called
3) More data is written to the card
How is this possible? If the hardware hasn't consumed any audio yet, we
won't write anything, because the buffer is full. If the hardware has
consumed something, but nothing has come out of the speakers yet, then
the hardware has the consumed audio buffered somewhere.
I don't know how this is possible, but that is what happens. It looks
like the buffer isn't full after the first write. mmap_write() returns
true a couple of times before anything is actually played and data
_is_ added to the buffer.
4) The reported delay of the card goes up exactly by the amount that was
written
5) This repeats a couple of times
If nothing is still coming out of speakers, this indicates that the
hardware reports the latency wrong, or our smoother is messing up the
latency reports. AFAIK, if the hardware has a 10 ms buffer, that should
be always included in what snd_pcm_delay reports. If it reports
something less, it's a driver bug.
I don't think there are any (more than usual) wrong reports - these are
values that are clearly visible on the oscilloscope, and correcting the
latency by the amount (by checking when the condition explained below
is true) leads to the correct latency. You cannot deny something that is
measurable just because it should not be that way.
I am talking about the delay reported by pa_alsa_safe_delay(). The delay
reported by this call does exactly match u->write_count during the first
milliseconds, which means that the alsa driver is buffering, but not
playing.
Playback starts at the moment, when u->write_count is larger than the
delay.
Again - check the code. It does not care at all if the card is really
playing,
it is just pushing audio to it. It probably would get stuck at some point
because alsa cannot buffer infinitely, but for the startup delays that the
devices have, it still works.
6) The card starts playing after 10 -15ms
7) Now there is some difference between the delay and the amount of data
written
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
