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. 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? Cheers, Arun
