Stream move + latency problems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux