Full Ableton Link support by JoergAtGithub · Pull Request #10999 · mixxxdj/mixxx

JoergAtGithub · 2022-10-24T20:14:03Z

Based on the old PR #3783 from @spensbot, I created a new PR with Ableton Link support for Main.

The LINK-Button enables/disables the Link session. The number right to it shows the number of connected Link peers.
It syncronizes Tempo and Beat-Position (Phase).

In Ableton Link all peers are equal, there is no leader. Therefore syncronization is always bidirectional.

In Mixxx, it syncs the Sync-Leader (the deck with SYNC and Crown-Button active) with the other peers.

The most important part of this PR is the hosttime filter implemetation, which provides a jitter free timestamp for each audio buffer start - this timestamp is in host time (computer clock not soundcard clock) which is the needed input for the Ableton Link library.

What does not always work automatical, is to determine the latency of the Sound IO. This is because portaudio does not report reliable latency information for all sound apis. On my system it works well for ASIO API, but not so well for the others. Therefore I added a manual latency compensation setting in the preferences, to allow the user to correct the latency:

I tested this with the official LinkHut-App of the Ableton Link package and with the Android App "G-Stomper Rythm", which is a free Drummachine, but with advertizing. A very cool Ableton Link software is also the music visualisation and lighting software from spensbot: https://captivatesynth.com/

Test Plan
Any Ableton Link software, should pass the following test plan:
https://github.com/Ableton/link/blob/master/TEST-PLAN.md

To install the official Linkhut reference tools used in the test plan, you can use VCPKG: ./vcpkg install ableton[hut,hutsilent]

Closes #8650

obsoleszenz · 2022-11-03T23:14:16Z

Awesome! <3

Needed for mixxxdj/mixxx#10999

octopuscabbage · 2022-12-17T21:17:13Z

Please finish merging this! I'm probably going to try bulding this branch tomorrow. I would use ableton link a lot.

daschuer

Thank you for this nice PR
Here some comments:

fwcd · 2023-02-21T23:31:51Z

Any updates on this? Super excited by Link support in Mixxx

JoergAtGithub · 2023-02-21T23:41:42Z

Try the builds of this PR - it should work in general.

See mixxxdj/mixxx#10999

fwcd · 2023-02-22T00:58:07Z

Pretty cool, I've tested it and tempo sync seems to work pretty well! Two things:

Mixxx seems to freeze occasionally during a session, I've tested it with two Mixxx clients talking to each other, but it seems to happen with other Ableton Link clients too
I haven't gotten phase sync to work, neither with nor without quantization enabled (I'm testing 2 Mixxx instances, on separate machines, each with a single track playing and sync crown enabled). Perhaps I'm missing something here?

Also I think this would be a prime candidate for bar detection if/when Mixxx finally gets it (#4489).

JoergAtGithub · 2023-02-22T22:51:22Z

I updated this PR to my local development state.
If phase doesn't sync, try to scratch the waveform by mouse, does the phase sync then?

varoudis · 2023-05-02T10:32:35Z

Any Mac Builds I can test? This is soo cool!

fwcd · 2023-05-02T10:36:14Z

Any Mac Builds I can test? This is soo cool!

Check the GitHub Actions builds: https://github.com/mixxxdj/mixxx/actions/runs/4558513041

luzpaz · 2023-06-24T12:35:00Z

Is there an ETA on this ?

JoergAtGithub · 2023-06-26T10:16:49Z

You can download a build of this PR now. General availability depends much on testing on different platforms with different sound driver configurations. It's developed under Windows11 with ASIO sounddriver. I would be happy if users of other OSes would execute the Ableton Link test plan: https://github.com/Ableton/link/blob/master/TEST-PLAN.md

JoergAtGithub · 2026-03-13T20:06:48Z

Just a friendly ping - all review requests are addressed and this is ready for merge!

daschuer

some more comments. Review is in progress.

daschuer · 2026-03-13T23:33:58Z

+                &AbletonLink::slotControlSyncEnabled);
+    }
+
+    // Destroy control objects before releasing Link.


The comment describes the code we can see anyway. Why is this required?

I would prefer to leave the three comments as they describe the required order of the three steps

Can you extend it "..because ..."?

Co-authored-by: Daniel Schürmann <daschuer@mixxx.org>

daschuer · 2026-03-17T07:05:49Z

+                &AbletonLink::slotControlSyncEnabled);
+    }
+
+    // Destroy control objects before releasing Link.


Can you extend it "..because ..."?

daschuer · 2026-03-17T20:57:26Z

+}
+
+double AbletonLink::getBeatDistance() const {
+    const auto sessionState = m_pLink->captureAudioSessionState();


getBeatDistance() is called more than once during an audio callback. However within a single audio callback it is assumed that all theses calls return the same distance. This is the case for all internal syncables.
The play position is advanced at a single point in the audio callback.
If we create a new session state at every call this assumption becomes void.

I am not sure how the Link thread is scheduled. I assume that it is scheduled asynchrony. To not have changing values we need to call captureAudioSessionState() only one a suitable point during the audio callback and use the sessionState as const during the callback. Probably along with onCallbackStart() when setting m_absTimeWhenPrevOutputBufferReachesDac.

A brief comment how the Link thread is scheduled would be helpfull at the new location of captureAudioSessionState()

See also:
https://github.com/Ableton/link/blob/b6d5c597a1027f333a06459c8d6e064d603bbe7c/include/ableton/Link.hpp#L183

This must be captured every time again, as the world around is not stoping while the Mixxx engine is processing a buffer callback.

I think we need first find a common understanding of the issue. So please correct me if I am wrong:

We have two independent threads firing asynchronously. The audio callback prepares the samples that are passed to the DAC ahead of time. The runtime of the Audio callback itself must not matter, if it is at least finished before the next audio callback is scheduled. This means a timing value gathered at the beginning of the callback for let's say deck 1 shall have the same timestamp in its calculation as one that is gathered later for let's say deck 4. Both produce samples that are played simultaneously and shall use the same beat distance to Link clients.

You're right that the Link timeline doesn't stop and we want to stay responsive to network updates. However, we need a reliable relation between the audio and the link thread. A kind of freeze, process, continue.

The core issue is this: Within a single audio callback, getBeatDistance() is called multiple times by different parts of the Mixxx engine. Each callback need to evaluates the session state at the freezed time, a fixed timestamp that is not effected by code runtime differences or CPU load.

But when getBeatDistance() is called again moments later in the same callback, it's asking Link the same question: "What will be the beat distance in the when the buffer I prepare now is processed in the DAC"
But if captureAudioSessionState() is called again between those two getBeatDistance() Link is advanced and we use a new session state no longer related to the first one used during the first part of the audio callback. This violates the a fundamental assumption: within one audio callback, all calculations referencing the same timestamp should be consistent and causes subtle timing glitches or phase discontinuities.

So I think we need to consider where the freeze is required and where we need a fresh timing. Here we need to consider the DAC timing. We need to compensate all CPU runtime differences and remove all time that comes from CPU processing from the calculation. We need to capture once each audio callback.

The key is ensuring all audio calculations within one callback see a consistent snapshot while still allowing the system to respond to Link updates at callback boundaries.

Does that make sense?

I just tried to change this to make sessionState a memeber variable of the AbletonLink class. But it completly broke the functionality, as these member functions are also called outside of the engine callback.
The local capturing of the sessionState is clearly the correct implementation!

daschuer · 2026-03-17T22:19:39Z

+            timeSinceLastCbSecs < bufferSizeSec * 2) {
+        m_meanOutputLatency.insert(timeInfo->outputBufferDacTime - soundCardTimeNow);
+
+        m_absTimeWhenPrevOutputBufferReachesDac = filteredHostTimeNow +


I am not sure if this works. I have not fully understand the code but I assume it does not work.

Why not just follow the example? It use the same clock which is used in captureAudioSessionState() which is required:

https://github.com/Ableton/link/blob/b6d5c597a1027f333a06459c8d6e064d603bbe7c/examples/linkaudio/AudioPlatform_Portaudio.ipp

This serves a probably well tested version that works OKisch.

However I think we can do a better alternative when the API provides the timing:

We have already solved the issue when syncing the wavefoms inupdateCallbackEntryToDacTime() This is pretty much the same task of predicting the reach of the DAC and sort out jitter noise and clock differences.

See: https://github.com/JoergAtGithub/mixxx/blob/37b47f8c5cc37a0f1caa5f8f0de1e48f13d14d6b/src/soundio/sounddeviceportaudio.cpp#L1136

captureAudioSessionState() has a clock for reference and does a snapshot for "now".
All data is extracted by passing m_absTimeWhenPrevOutputBufferReachesDac to transpose the result to the actual point of interest and not "now". Inside the functions a jittery "now" is subtracted from a jittery m_absTimeWhenPrevOutputBufferReachesDac, so the jitter noise disappears.

This means we actually need the time form taking "now" to the to the point when reaching the DAC including jitter. This varies each callback and this variation should be part of the value to actually compensate such issues. I think we can even reuse "updateCallbackEntryToDacTime()" or extend it as desired.

See:
https://github.com/Ableton/link/blob/b6d5c597a1027f333a06459c8d6e064d603bbe7c/include/ableton/link/Controller.hpp#L239

I am not sure if this works.

It 100% does, I spend months of testing until I reached this point. This is the essence of the whole PR!

Why not just follow the example?

I started with the example, and it did not work very well. Even the Ableton developers wrote somewhere that they never got the PortAudio implementation working compareable to the other backends.

We have already solved the issue when syncing the wavefoms inupdateCallbackEntryToDacTime() This is pretty much the same task of predicting the reach of the DAC and sort out jitter noise and clock differences.

This trial-and-error approach is completely unsuitable here, as it provides neither a steady increase nor jitter-free timing information. Any errors must be averaged out by the filter ignoring individual buffer callbacks is not an option here. And this delivers an absolute time with a jitter far lower than anywhere else in Mixxx.

The implemented algorithm is tested for very long time (there is a reason, why this PR took me 4 years), and I tested many variants starting from the official Ableton examples. Believe me that this is far better than what I started from!

I am not sure if this works.

It 100% does, I spend months of testing until I reached this point. This is the essence of the whole PR!

Oh sorry. This shall not come along as general critic of this PR. It was meant as inline comment for the local scope.

I obviously do not understand the code and the reasons why it shall be like that. As a reviewer I like to understand it. This is required to verify all edge cases. Ideally it results in some nice code comments that also secures your implementation against future changes form other authors.

So let's try to get a common understanding:

I started with the example, and it did not work very well.

What was the issue?

Even the Ableton developers wrote somewhere that they never got the PortAudio implementation working compareable to the other backends.

Do you have a reference for this? This is probably an extremely important information for our GSoC project.
Lets not repeat such PortAudio issue.

I know that the timing information of PortAudio is broken when we uses the ALSA loop back pulse or pipewire devices. The ALSO timing of the hardware soundcards is very stable.
Which API do you use on windows? For my understanding native ASIO and WDM-KS also provide good timing even though PortAudio.

Any errors must be averaged out by the filter ignoring individual buffer callbacks is not an option here.

Can you explain the reasons?

I added the requested explanations as comments!

whattheheckman · 2026-04-04T17:26:15Z

Hey I just tested this today using Ableton Live 12 and Serato DJ 3 and it seems to be working as intended for the most part! There are some oddities I encountered with Mixxx not matching the behavior/UX I have come to expect while using Ableton Link with Serato, and while I know that Mixxx isn't always aiming to match other software exactly, I think some of those changes are worth while. I'm happy to detail those here or on Zulip, not exactly sure which one is preferred, and I'd be willing to help add those code changes potentially.

Destroy m_pLink before control objects

daschuer · 2026-05-05T06:30:34Z

+}
+
+double AbletonLink::getBeatDistance() const {
+    const auto sessionState = m_pLink->captureAudioSessionState();


I think we need first find a common understanding of the issue. So please correct me if I am wrong:

We have two independent threads firing asynchronously. The audio callback prepares the samples that are passed to the DAC ahead of time. The runtime of the Audio callback itself must not matter, if it is at least finished before the next audio callback is scheduled. This means a timing value gathered at the beginning of the callback for let's say deck 1 shall have the same timestamp in its calculation as one that is gathered later for let's say deck 4. Both produce samples that are played simultaneously and shall use the same beat distance to Link clients.

You're right that the Link timeline doesn't stop and we want to stay responsive to network updates. However, we need a reliable relation between the audio and the link thread. A kind of freeze, process, continue.

The core issue is this: Within a single audio callback, getBeatDistance() is called multiple times by different parts of the Mixxx engine. Each callback need to evaluates the session state at the freezed time, a fixed timestamp that is not effected by code runtime differences or CPU load.

But when getBeatDistance() is called again moments later in the same callback, it's asking Link the same question: "What will be the beat distance in the when the buffer I prepare now is processed in the DAC"
But if captureAudioSessionState() is called again between those two getBeatDistance() Link is advanced and we use a new session state no longer related to the first one used during the first part of the audio callback. This violates the a fundamental assumption: within one audio callback, all calculations referencing the same timestamp should be consistent and causes subtle timing glitches or phase discontinuities.

So I think we need to consider where the freeze is required and where we need a fresh timing. Here we need to consider the DAC timing. We need to compensate all CPU runtime differences and remove all time that comes from CPU processing from the calculation. We need to capture once each audio callback.

The key is ensuring all audio calculations within one callback see a consistent snapshot while still allowing the system to respond to Link updates at callback boundaries.

Does that make sense?

daschuer · 2026-05-05T06:56:36Z

+            timeSinceLastCbSecs < bufferSizeSec * 2) {
+        m_meanOutputLatency.insert(timeInfo->outputBufferDacTime - soundCardTimeNow);
+
+        m_absTimeWhenPrevOutputBufferReachesDac = filteredHostTimeNow +


I am not sure if this works.

It 100% does, I spend months of testing until I reached this point. This is the essence of the whole PR!

Oh sorry. This shall not come along as general critic of this PR. It was meant as inline comment for the local scope.

I obviously do not understand the code and the reasons why it shall be like that. As a reviewer I like to understand it. This is required to verify all edge cases. Ideally it results in some nice code comments that also secures your implementation against future changes form other authors.

So let's try to get a common understanding:

I started with the example, and it did not work very well.

What was the issue?

Even the Ableton developers wrote somewhere that they never got the PortAudio implementation working compareable to the other backends.

Do you have a reference for this? This is probably an extremely important information for our GSoC project.
Lets not repeat such PortAudio issue.

I know that the timing information of PortAudio is broken when we uses the ALSA loop back pulse or pipewire devices. The ALSO timing of the hardware soundcards is very stable.
Which API do you use on windows? For my understanding native ASIO and WDM-KS also provide good timing even though PortAudio.

Any errors must be averaged out by the filter ignoring individual buffer callbacks is not an option here.

Can you explain the reasons?

…alization (kValueUndefined = 0.0) instead of arbitrary 9999.9 value.

…ee time reference. Added comments about the weaknesses in timepoint and the latency reporting. Explained why the official AbletonLink example for PortAudio is not working well.

daschuer

Some more comments.

The filter for measuring the current buffer time works nice.

The surrounding code is redundant with the already existing timing code for waveform anti jitter. We need to join it to make the waveforms smooth on windows as well.
On Linux we can skip the filter because ALSA and Pipewire has its own reliable timing

I guess the the mentioned issues with Portaudio And ableton Link are widows only issues.

daschuer · 2026-06-02T19:57:59Z

    // After local bpms are updated, trigger the rest of the post-processing
    // which ensures that all channels are updating certain values at the
-    // same point in time. This prevents sync from failing depending on
+    // same point in time.  This prevents sync from failing depending on


extra space

daschuer · 2026-06-02T20:51:25Z

+    }
+
+    if (CmdlineArgs::Instance().getDeveloper()) {
+        qWarning() << "Pa_GetStreamTime: "


We must not print in the engine thread because it is a locking operation, xcept there is a strong reason for it. I suggest to maintain this as commted qDebug output. When we need it for debugging we can uncomment compile and enjoy.

daschuer · 2026-06-02T20:56:49Z

+
+    // With the cumulated buffer time an the linear regression in the host time filter we smooth
+    // and host time point for each soundcard callback - with a jitter of some 100us.
+    auto filteredHostTimeNow = m_hostTimeFilter.calcHostTime(m_cummulatedBufferTime);


The type can't be guessed and is important to understand the following code.

Suggested change

auto filteredHostTimeNow = m_hostTimeFilter.calcHostTime(m_cummulatedBufferTime);

std::chrono::microseconds filteredHostTimeNow = m_hostTimeFilter.calcHostTime(m_cummulatedBufferTime);

It took me a while to understand. I think I got it now.
For my understanding the output is not filteredHostTimeNow because the input is not "time now". The input is the jitter free time DAC time. So the output is the DAC time transposed to Host time (+ the average call delay). Somehow the Host time for the currently received buffer. If we subtract the measured hostTime we see the different delays (jutter) that may happen due to CPU load or other high priority task.

Can you rename it to bufferTimeAsHostTime or such?

daschuer · 2026-06-02T22:13:32Z

+
+    // Calculates the host time based on the auxiliary time using linear regression.
+    // Returns kInvalidHostTime if there are not enough points or if the calculation isn't possible.
+    std::chrono::microseconds calcHostTime(double auxiliaryTime) const {


insertTimePoint() and calcHostTime() are always called after each other. You may create function the does the work of both but faster than the single functions.

daschuer · 2026-06-02T22:25:52Z

+    if (filteredHostTime != HostTimeFilter::kInvalidHostTime) {
+        m_absTimeWhenPrevOutputBufferReachesDac = filteredHostTime + outputLatency;
+    } else {
+        m_absTimeWhenPrevOutputBufferReachesDac = hostTime + outputLatency;


externalSyncLatencyUs is missing here. The user may also need a manual sync.

daschuer · 2026-06-02T22:50:48Z

+    // the time points.
+    m_cummulatedBufferTime += bufferSizeSec;
+    auto hostTime = std::chrono::duration_cast<std::chrono::microseconds>(
+            ClockT::now().time_since_epoch());


Same here, you can reuse m_clkRefTimer here

daschuer · 2026-06-02T22:55:21Z

+            m_pStream); // There is a delay & jitter to timeInfo->currentTime
+
+    // The time points reported by PortAudio (timeInfo->currentTime or PaStreamCallbackTimeInfo)
+    // are not reliable (on Windows no backend reported satisfactory values - all had huge jitter).


On Linux ALSA and Pipewire the are reliable. So I think we can skip our own filter here.
You can see it by the smooth waveform. Linux smooth, Windows jittery.

On the other hand the filter is fast, compared to all the other things we do in the engine. Mabe we can use it anyway ... ??

daschuer · 2026-06-02T23:11:18Z

+    PaTime soundCardTimeNow = Pa_GetStreamTime(
+            m_pStream); // There is a delay & jitter to timeInfo->currentTime


Use timeInfo->currentTime, it is the same, just measured at the very beginning of the callback.

daschuer · 2026-06-02T23:21:02Z

+            timeSinceLastCbSecs < bufferSizeSec * 2) {
+        m_meanOutputLatency.insert(timeInfo->outputBufferDacTime - soundCardTimeNow);
+
+        m_absTimeWhenPrevOutputBufferReachesDac = filteredHostTimeNow +


The sanity check for wrong API data below is not considered here. I think it was required of DirectSound on windows.

daschuer · 2026-06-03T06:39:04Z

This is Pipewire 0.3.48 via Pulse API (Bad timing)

timeInfo->outputBufferDacTime - soundCardTimeNow
m_meanOutputLatency.mean()

This is the corresponding:

hostTime.count() - filteredHostTimeNow.count()

daschuer · 2026-06-03T06:46:48Z

This is the same with ALSA:

daschuer · 2026-06-03T15:39:43Z

Takeaways from the graphs:
ALSA:

Direct ALSA delivers good timing
In the Direct ALSA timing, we probably see the scheduler quantization of 1 ms.
The reporter value matches the host filtered value.

ALSA Pulse Pipewire ALSA stack

The delivered timing is bumpy
Some in instances in the stack are trying to compensate a drift
In the host measured timer we see the same "desired" 1 ms jitter, but also a big slope trying to compensate something. Maybe a missed frame or such.

We can also see that the time constants from both filters do not match. We need to fix the issue that we subtract two values filters with different time constances.

If we use the filtered value + the reported time, we overcompensate the jitter noise.

DatanoiseTV · 2026-06-08T13:45:45Z

Thanks for digging into the PipeWire/Pulse vs. ALSA timing — the two-filter time-constant mismatch is a nice catch.

I took a small stab at exactly that part on a branch: feat/ableton-link (0bf8ffd). It derives the host-time-at-DAC from the single host-time regression, evaluated at cumulatedBufferTime + outputLatency, and matches the latency-filter window to the regression window — so the "now" filter and the latency filter no longer fight each other. On CoreAudio/ASIO/direct-ALSA it's numerically near-identical, so it shouldn't regress the cases that already work well.

The honest caveat: I could only confirm it builds and behaves on CoreAudio. I don't have a PipeWire/Pulse-over-ALSA rig with a Link peer and the scope-trace harness you used above, so I can't tell whether it actually helps the bumpy case. If someone with that setup could give it a spin, that'd be hugely helpful. Happy to turn it into a proper PR against this branch if it pans out.

github-actions Bot added build skins labels Oct 24, 2022

JoergAtGithub mentioned this pull request Nov 1, 2022

Update VCPKG and add Ableton Link package to the Mixxx buildenv mixxxdj/vcpkg#54

Merged

obsoleszenz added a commit to obsoleszenz/mixxx-ci-docker that referenced this pull request Nov 3, 2022

Add abletonlink to dependencies

0b6f0ee

Needed for mixxxdj/mixxx#10999

obsoleszenz mentioned this pull request Nov 3, 2022

Add abletonlink to dependencies Holzhaus/mixxx-ci-docker#2

Closed

obsoleszenz added a commit to obsoleszenz/mixxx-ci-docker that referenced this pull request Nov 3, 2022

Add abletonlink to dependencies

71f03df

Needed for mixxxdj/mixxx#10999

obsoleszenz mentioned this pull request Nov 3, 2022

Add abletonlink to dependencies Holzhaus/mixxx-ci-docker#3

Open

daschuer requested changes Dec 19, 2022

View reviewed changes

JoergAtGithub force-pushed the abletonlink branch from 67bb0c2 to a2bf288 Compare December 22, 2022 20:39

github-actions Bot added the code quality label Dec 22, 2022

JoergAtGithub force-pushed the abletonlink branch from af87be3 to 958b49a Compare December 22, 2022 22:00

Holzhaus reviewed Dec 28, 2022

View reviewed changes

Comment thread src/engine/enginemaster.cpp Outdated

fwcd added a commit to fwcd/m1xxx that referenced this pull request Feb 21, 2023

Point mixxx to JoergAtGithub:abletonlink

95c152d

See mixxxdj/mixxx#10999

JoergAtGithub force-pushed the abletonlink branch from 7812f3e to da63a02 Compare February 22, 2023 22:46

JoergAtGithub added feature sync and removed code quality labels Mar 25, 2023

github-actions Bot added the code quality label Mar 29, 2023

JoergAtGithub removed the code quality label Mar 29, 2023

github-actions Bot added the code quality label Jun 1, 2023

JoergAtGithub force-pushed the abletonlink branch from 292d3a5 to ed68fc9 Compare February 15, 2026 11:04

JoergAtGithub added the needs review label Feb 15, 2026

JoergAtGithub requested a review from daschuer February 15, 2026 15:09

mxmilkiib mentioned this pull request Mar 13, 2026

Ableton Link transport support? ahlstromcj/seq66#16

Closed

daschuer reviewed Mar 13, 2026

View reviewed changes

Apply suggestions from code review

64ef6ef

Co-authored-by: Daniel Schürmann <daschuer@mixxx.org>

JoergAtGithub force-pushed the abletonlink branch from 1dd602d to 64ef6ef Compare March 14, 2026 18:31

Merge remote-tracking branch 'upstream/main' into abletonlink2

3d4e84e

github-actions Bot added the packaging label Mar 14, 2026

JoergAtGithub force-pushed the abletonlink branch from 3455e8c to 311fb44 Compare March 14, 2026 20:18

JoergAtGithub added 2 commits March 14, 2026 22:38

Fix flatpack builds

af17306

Adjusted order of private vars and private methods in header

37b47f8

mxmilkiib mentioned this pull request Mar 15, 2026

Add support for Ableton Link Audio? #16167

Open

daschuer reviewed Mar 17, 2026

View reviewed changes

daschuer requested changes Mar 17, 2026

View reviewed changes

JoergAtGithub mentioned this pull request Apr 19, 2026

Ableton Link Integration #3783

Closed

JoergAtGithub added 2 commits May 4, 2026 22:05

Added good detailed comment for non obvious isPlaying method

e68344c

Change destruction order in AbletonLink destructor

ff2628f

Destroy m_pLink before control objects

daschuer requested changes May 5, 2026

View reviewed changes

JoergAtGithub added 2 commits May 5, 2026 19:31

Remove unnecessary kDefaultBpm. m_oldTempo now uses default Bpm initi…

f760a06

…alization (kValueUndefined = 0.0) instead of arbitrary 9999.9 value.

Improve comments to explain the determinition of the nearly-jitter fr…

3bba07c

…ee time reference. Added comments about the weaknesses in timepoint and the latency reporting. Explained why the official AbletonLink example for PortAudio is not working well.

JoergAtGithub mentioned this pull request May 17, 2026

proposal: PipeWire backend mixxxdj/proposals#19

Open

daschuer requested changes Jun 2, 2026

View reviewed changes

daschuer mentioned this pull request Jul 9, 2026

Add local time sync ref (for AbletonLink etc.) selection to SoundManager #14164

Open

	auto filteredHostTimeNow = m_hostTimeFilter.calcHostTime(m_cummulatedBufferTime);
	std::chrono::microseconds filteredHostTimeNow = m_hostTimeFilter.calcHostTime(m_cummulatedBufferTime);

		PaTime soundCardTimeNow = Pa_GetStreamTime(
		m_pStream); // There is a delay & jitter to timeInfo->currentTime

Uh oh!

Uh oh!

Conversation

JoergAtGithub commented Oct 24, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

obsoleszenz commented Nov 3, 2022

Uh oh!

octopuscabbage commented Dec 17, 2022

Uh oh!

daschuer left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

fwcd commented Feb 21, 2023

Uh oh!

JoergAtGithub commented Feb 21, 2023

Uh oh!

fwcd commented Feb 22, 2023

Uh oh!

JoergAtGithub commented Feb 22, 2023

Uh oh!

varoudis commented May 2, 2023

Uh oh!

fwcd commented May 2, 2023

Uh oh!

luzpaz commented Jun 24, 2023

Uh oh!

JoergAtGithub commented Jun 26, 2023

Uh oh!

JoergAtGithub commented Mar 13, 2026

Uh oh!

daschuer left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

whattheheckman commented Apr 4, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JoergAtGithub commented Oct 24, 2022 •

edited

Loading

daschuer left a comment •

edited

Loading

daschuer commented Jun 3, 2026 •

edited

Loading

daschuer commented Jun 3, 2026 •

edited

Loading