Detect and adjust for clock skew when using multiple soundcards.

Bug #1293800 reported by RJ Skerry-Ryan
6
This bug affects 1 person
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.

RJ Skerry-Ryan (rryan)
Changed in mixxx:
status: New → Confirmed
importance: Undecided → High
Revision history for this message
Daniel Schürmann (daschuer) wrote :

A nice link:
http://www.leapsecond.com/pages/sound-1pps/

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.

Changed in mixxx:
assignee: nobody → Daniel Schürmann (daschuer)
milestone: none → 1.12.0
Changed in mixxx:
status: Confirmed → In Progress
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

We now have a nice solution that lets the user choose how much synchronization delay to introduce.

Changed in mixxx:
status: In Progress → Fix Committed
Revision history for this message
Daniel Schürmann (daschuer) wrote :
RJ Skerry-Ryan (rryan)
Changed in mixxx:
status: Fix Committed → Fix Released
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/7339

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.