[pulseaudio-discuss] Stream move + latency problems

[Colin Guthrie]

'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/]