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
