Detect and adjust for clock skew when using multiple soundcards.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mixxx |
Fix Released
|
High
|
Daniel Schürmann |
Bug Description
When using multiple soundcards differences in the accuracies of the crystals can cause clock skew. When time progresses at different rates for different cards we can't satisfy both without underflows or overflows in one of them.
The solution in Mixxx 1.12.0 is to pick a clock reference device to run the master callback on (typically the device the master output is enabled for). All other soundcards read from AudioOutput buffers via FIFOs.
Overflow and underflows are easy to detect with these FIFOs. Now we need to decide what to do about them.
Overflows are easy to handle -- you just timestretch slightly to make the available samples fit into the desired buffer.
Underflows are not as easy. You have to cause the card to go into "underflow" mode where we predict the card's rate and then time stretch future buffers so that time slows down for the card (more samples per unit time) to match the slower rate.
See previous discussion in Bug #1203249.
Changed in mixxx: | |
status: | New → Confirmed |
importance: | Undecided → High |
Changed in mixxx: | |
assignee: | nobody → Daniel Schürmann (daschuer) |
milestone: | none → 1.12.0 |
Changed in mixxx: | |
status: | Confirmed → In Progress |
Changed in mixxx: | |
status: | Fix Committed → Fix Released |
A nice link: www.leapsecond. com/pages/ sound-1pps/
http://
Result, this souncard was at 44ppm
---
We have a maximum buffer of 4096 frames.
If we allow to shrink or stratch by one frame at max, we can run a two 144 ppm soundcards with opposite drift at maximum latency.
Without the correction and two 44ppm sound cards in opposite direction and a typical 23 ms buffer we will face a underflow or overflow every 26 seconds.
---
Actually we are facing extreme jitters from up to one buffer size. So we need an artificial delay of at least on buffer for the non clock device. In addition we need a delay (extra buffer for the saved samples) this is used, when one sound card overtakes and should not introduce an extra delay.
---
It is to bad that we can't be sure the read/write solution does not work for all underling APIs. It was working very nice without introducing an delay, because we had direct access to the ALSA library and are able to use the internal buffer for jitter compensation.
Maybe we should allow to enable it as an experimental preference option.