On Tue, 2011-06-14 at 16:43 -0700, Arun Raghavan wrote: > 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. Looks good to me. > 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? I didn't look at the code too closely, but what about adding some field in pa_sink_input.thread_info that gives enough information for the sink to do the right thing in the PA_SINK_MESSAGE_FINISH_MOVE handler? -- Tanu
