'Twas brillig, and Arun Raghavan at 15/06/11 00:43 did gyre and gimble: > Hey folks, > As Amanda and Alejandro reported and debugged (thanks to both of you for > the analysis!), there seem to be problems with latency calculations on > stream moves. I've spotted 2 issues so far. > > 1. Latency calculations are made assuming that current latency values > are what was requested. As Amanda points out, the result is that the > sink latency halves on each move, eventually causing a rewind flood. I'm > attaching a patch for this. Just want some eye-balls on this before I > push this out. Seems like a sensible approach. Can't comment immediately as to whether there are other places where buffer_attr is used in a setup sense without digging in the code properly which I won't be able to do today. > 2. While moving, we can't update the destination sink latency. > Currently, the pa_sink_input->moving() function is called before the > sink input's 'sink' member is updated (it is NULL during this time). As > a result, we can't actually set the sink latency, and the overall > latency is calculated assuming that the sink will be able to provide > ~1/2 the requested latency. I'm not sure how we should be fixing this. > I'm tempted to call sink_input->moving() after setting the sink on it, > but this might (probably will?) break stuff. Anybody got a cleaner > alternative? Do we even need to update the latency in the moving() function? Can we not just leave it until the FINISH_MOVE message is handled, or do we loose other information by this stage? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
