19.11.2015 00:43, Georg Chini wrote:
On 15.11.2015 22:08, Alexander E. Patrakov wrote:
The second result (https://imgur.com/a/eVahQ ) is with the old module.
You see that, with it, the rate oscillates wildly and then snaps to
44100 Hz. However, the final latency is not correct, and it
accumulates due to clock mismatch between the two sound cards in the
desktop. I have not waited enough to see what happens next, but the
result is clearly invalid.
I wonder why the phase is not continuously growing in the final plot. I
would expect this
because the controller snaps to the base rate.
The controller snaps to the base rate, then waits for the latency
difference to accumulate, then unsnaps. That's why the average rate is
still correct. Also, the script only looks at the audio waveform at the
output and thus cannot catch the situation where the module eats the
accumulating latency difference.
The next result (https://imgur.com/a/Bi2Yz ) is with the new module,
as of PATCH 04/13. There is some "rate hunting", and it results to
some noise in phase. It is generally contained between -150 and 200
degrees.
Next, let's see (https://imgur.com/a/yQGWL ) what the deadband
achieves. Result: it helps against rate hunting, but not much against
phase oscillations. This is because new_rate is snapped to base_rate,
which would only be correct if the cards actually shared the common
clock. So here is what happens: the module runs for some time with 1:1
resampling (i.e. with the rate strictly equal to 44100 Hz), and the
latency difference slowly drifts due to the clock mismatch. When the
difference becomes bigger than the error of its measurement, the
module corrects it, and then runs at 44100 Hz for some time again.
Could you use 2 s as adjust time? 10 seconds is definitely too slow to
achieve good results.
I would expect a similar result but with much smaller amplitude of the
phase oscillation.
Will measure this in the evening.
However, I'd argue that this phase metric can be improved without the
deadband and beyond what this deadband-based implementation provides.
What is the problem with the dead band? There are physical limitations
to what makes
sense to correct and the dead band just takes care of those limits.
There are no such limits once you (or your second-order filter) start
averaging previous latency difference measurements.
First, see (https://imgur.com/a/P5Y0A ) what happens, at PATCH 04/13,
if we just decrease adjust_time to 1 second. The rate oscillations
become bigger, but phase oscillations stay of the same order as with
the default value of adjust_time (10 seconds). So not good.
Then, let's change the rate controller so that it does not attempt to
correct all of the latency difference in one step. The value of
adjust_time is still 1s, but let's aim to correct the difference after
10 steps by a factor of 2.71. For simplicity (and for testing purposes
only), let's destroy the non-linear part of the controller. Here is
the code:
static uint32_t rate_controller(
uint32_t base_rate,
pa_usec_t adjust_time,
int32_t latency_difference_usec) {
uint32_t new_rate;
new_rate = base_rate * (1.0 + 0.1 *
(double)latency_difference_usec / adjust_time);
return new_rate;
}
As you can see (https://imgur.com/a/eZT8L ), the phase oscillations
are now much more limited!
I have received a private email from Georg where he proposes to use
the deadband, but snap to something other than base_rate, e.g. to a
result of some slow controller. For me, this is equivalent to using
this slow controller, i.e. a good idea.
I'll send you a patch privately later today. I kept the controller and
implemented a more or less
independent controller which takes care of the clock skew / latency
drift. I'd like to discuss
this approach first with you before I send another patch to the list.
I have received this email, will also test the filter in the evening.
--
Alexander E. Patrakov
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
