On 2010-09-08 02:52, pl bossart wrote:
So what does this test mean? pavucontrol obviously affects the latency
of the sink due to it's VI meters. This obviously increases the
likelihood of a rewind being triggered.So, with this in mind what
values do you suggest we pick?
Pierre, is it your understanding that it is when DMA transfer collides with
cpu->RAM transfer that makes the DMA stream to become broken permanently? Or
exactly what is it that makes it break?
The low-latency setting has nothing to do with rewinds.
Indirectly it is - if the rewind margin is greater than the actual
latency there won't be any rewind.
It's when you
actually change the volume that you will rewind and remix with the new
stream volume. You could set a super low latency and rewind exactly
once when the stream starts.
There are two issues with the rewind. One is a race condition between
the DMA and the ring buffer update. If you rewind and update the ring
buffer, the DMA may actually have already fetched older data.
To fetch the old data is not a problem IMO, that gives us just a ms more
of the old data and we might miss a ms of the new data. That's not
optimal, but not a complete disaster either.
What is the big problem here, is when we get a persistent crackling
(even when everything has straightened out after the rewind!), and if I
understand you correctly, that has something to do with the DMA
controller...? Could you elaborate on what conditions it is that cause
the persistent crackling?
The
second is that you could experience underflows if you don't do the
update fast enough. By enabling logs you should be able to find out if
there are real underflows.
Exactly.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
