Skip to content

proposal: PipeWire backend #19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
pri-yan-shu wants to merge 8 commits into
base: main
Choose a base branch
from
+98 −0
Open

proposal: PipeWire backend #19

Changes from 1 commit
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
d9644fe
proposal: PipeWire backend
pri-yan-shu May 14, 2026
f47832e
fix line length lint failure
pri-yan-shu May 18, 2026
526254b
remove alternatives section
pri-yan-shu May 18, 2026
be055fa
Address following issues
pri-yan-shu May 22, 2026
32954a1
Add timeline
pri-yan-shu May 24, 2026
a359ef1
fix typo
pri-yan-shu May 24, 2026
0cb7b40
Update timeline, add PRs targetting tasks
pri-yan-shu Jun 16, 2026
fd9d99d
Update Action Plan for coding phase 2
pri-yan-shu Jul 13, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
56 changes: 56 additions & 0 deletions proposals/2026-05-14_pipewire.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@
# PipeWire support for Mixxx

* **Owners:**
* `@pri-yan-shu`

* **Implementation Status:** `Not implemented`

> TL;DR: This proposes PipeWire audio API support to Mixxx, SoundDevice hotplug for PipeWire,
> ability to route audio from Mixxx UI, and react to external changes.

## Why

PipeWire is an audio API for Linux. It replaces the multiple audio APIs already present on Linux, like ALSA, JACK, PulseAudio, and has compatibility layer for all those APIs. It also supports connecting any audio source/sink (from any application) to Mixxx, like the system audio inputs/outputs. This allows for flexibility in routing, for example adding an effect before input/after output.

### Pitfalls of the current solution

Currently Mixxx supports all audio APIs through PortAudio, which abstracts over audio APIs for multiple platforms. Features specific to a single API are not exposed, which leads to poor experience on Linux (for example, [incorrect naming of JACK ports](https://github.com/mixxxdj/mixxx/issues/5979)).

* There is no hotplug for SoundDevices

@daschuer daschuer May 19, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You may also mention the port model vs. the soundcard model.


## Goals

Goals and use cases for the solution as proposed in [How](#how):

* Refactor code related to current audio backends, and allow the selection of PipeWire among the available backends.
* Get feature parity with the current PortAudio backend. Ensure that drift and jitter correction is happening properly.
* Hotplug for audio devices on PipeWire
* Synchronize routing UI with changes through external patchbays
* Have a design style that is concise and covers all the essential information.

@daschuer daschuer May 19, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you plan significant changes.

@pri-yan-shu pri-yan-shu May 19, 2026 •
edited
Loading

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes about what? The

Have a design style that is concise and covers all the essential information.

was left by mistake from the template, I'll remove it


@daschuer daschuer May 19, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Support external patch bays. (Not like now with Jack where only anyway connected ports are exposed)

@pri-yan-shu pri-yan-shu May 19, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what I meant by:

Synchronize routing UI with changes through external patchbays

I'll be more explicit.

### Audience

This change affects linux users using PipeWire.

## Non-Goals

* To be decided

## How

* The proposal will be implemented as a PipeWire client which listens for all node/port/link objects (similar to existing PipeWire patchbays), and creates SoundDevices accordingly. Since this happens for all source/sink available, not just soundcard source/sink, we can route any source/sink to Mixxx. This will work with the current routing UI in Sound Hardware preference page. Same mechanism will be used to update the routing UI to reflect any changes made by an external patchbay.

@daschuer daschuer May 18, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here we need more details.

We have two use cases:

  1. Normal Linux "Souncard" based approach. -> The hardware GUI can remain.
  2. The Ubuntu Studio based approach. The wiring is outsourced to an external patch bay application.

Which use case do you want to focus one (first)

There is another degree of freedom JACK Support on windows and MacOS. Pipewire does support the JACK API. So we may use Pipewire via the JACK API on all platforms.

@pri-yan-shu pri-yan-shu May 18, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By the first usecase you mean the Mixxx GUI for selecting inputs and outputs? If that's the case, I would prefer to focus on this first, arguing that Mixxx should provide a completely self sufficient experience first, without relying on external tools (later we can integrate them).

I agree that JACK support can be used on Windows and MacOS, but we need to figure out if anyone is using JACK over WASAPI (on Windows) or over whatever MacOS native API is. Are there any advantages of our dedicated JACK implementation over the PortAudio backend, apart from better patchbay routing and naming conventions? Can we do a poll somewhere, to ask what is preferable? I also read that PipeWire has a better security/permisson model, paraphrasing from their website:

PipeWire was designed with a powerful security model that makes interacting with audio and video devices > from containerized applications easy, with support for Flatpak applications being the primary goal.

I'll have to look a bit to see how Flatpak is different on JACK vs PipeWire, and how it would affect end user.

@daschuer daschuer May 18, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you propose to not implement the jack API of Pipewire? Would be an option.
I wonder if we need the jack API later anyway because if Ubuntu Studio.

Yes a poll would be nice if anyone is even interested in jack on windows and macOS and what the favorite alternative would be.
Maybe it is for your project enough, to keep that in mind and make a later introduction of these alternatives easy.

@pri-yan-shu pri-yan-shu May 18, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ubuntu Studio 24.04 LTS has PipeWire by default. Is there any other reason we need JACK API for Ubuntu Studio? Older versions compat?

@daschuer daschuer May 19, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ther is no reason to use the jack API on Ubuntu Studio. Implementating the jack API in Mixxx would allow to use original Jack server as well. But I don't see a reason to do it on Linux because Pipewire outperforms Jack.
All native Jack tools the user might want to user are compatible via the replacement library pipewire-jack.


* On Linux systems, PipeWire would show up in the Sound API option in the preference panel, among other audio APIs offered by PortAudio. The existing soundio code would be refactored into enumerators for different audio backends, similar to Controller enumerators.

@daschuer daschuer May 18, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This requires an internal abstraction of PortAudio and Pipwire devices, which might be unnecessary complexity.

For the first approach a Pipwire (JACK API) only solution would be OK for me.

If we in addition find out how to run Mixxx directly with the ALSA callbacks, (via pipwire or bypassing it) we can retire Portaudio on Linux entirely.

I can Imagine to have a ALSA and a Pipwire/Jack mode finally, nothing else.
ALSA for the lowest possible latency and Pipewire for routing system sound and other applications.

@daschuer daschuer May 18, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just found this: https://www.omglinux.com/pipewire-gains-a-zero-latency-jack-d-bus-bridge-performance-improvements/

Not exactly sure what it means, but when it manages to remove the extra latency cycle of Jack and early pipe wire, we can even dispose the direct ALSA access.

The test is copy the incoming date directly to the output.
In case of ALSA we receive the captured audio in one buffer and can copy it to the output buffer. The output buffer will reach the DAC, after this single cycle.

Jack was delaying this write back by one cycle in my tests documented here:
https://mixxx.org/news/2021-05-09-jack-zero-latency/

I think the very first task is to repeat the test with the latest pipewire. Than we can decide to add or remove the direct ALSA mode.

@daschuer daschuer May 18, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pipewire is now at V 1.6 in the test it was with Pipewire V 0.3.36

@pri-yan-shu pri-yan-shu May 18, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the very first task is to repeat the test with the latest pipewire

I wrote a simple PipeWire program where I copied the input buffer to output, and measured its latency with jack_iodelay, where I got ~23 ms roundtrip latency for 1024 buffer size. I wrote about this in the GSOC channel on Zulip, can you comment on that?

I can try with implementing PipeWire client in Mixxx, is there any case I'm missing with the simple program?

@daschuer daschuer May 18, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The simple program is probably good enough.
For a first test.

@daschuer daschuer May 19, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did the test and I can confirm that there is no latency difference between the Portaudio ALSA solution and Pipewire.
There is only a minor concern that we probably give away some usable latency CPU for Mixxx to manage the additional context switch. Not sure how much this is, hopefully negligible for the 1:1 copy case.

This means we can target a solution that is pure pipewire on linux without any Portaudio options.


## Alternatives

An alternative is to use a different crossplatform library which has fine grained API for different backends. One such contender is [libsoundio](https://github.com/andrewrk/libsoundio). The issue is that this library is not maintained, and does not support PipeWire on linux, only PulseAudio and JACK.

@daschuer daschuer May 18, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can sort out this option.

@pri-yan-shu pri-yan-shu May 18, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By sort out you mean remove this option?

@daschuer daschuer May 18, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.


## Action Plan

The tasks to do in order to migrate to the new idea.

* [ ] Implement support for PipeWire backend.

@daschuer daschuer May 19, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[ ] test the multi soundcard sync of Pipwwire.

* [ ] Add soundcard hotplug support.
* [ ] Modify PipeWire graph from Mixxx UI

@daschuer daschuer May 19, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if this is beneficial work. Can't we just add a button to open the system installed Graph editor?
qpwgraph/Helvum than the user feels at home with the known tool.

It is unlikely that the user opens Mixxx for doing this. The GUI in Mixxx shall be optimized to do the easy Mixxx only tasks. The graphical representation seem to be overdone.

Maybe we can put a bit of business logic on top of it. For automatically suggest mappings.

@daschuer daschuer May 19, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder who is responsible for rewire the graph after restart.
At one point we have discussed two modes to switch between. The media player mode at home and the DJ mode when connecting the controller soundcard.

@daschuer daschuer May 19, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be super great if we finally can access the fader in the sound hardware via Mixxx.

@pri-yan-shu pri-yan-shu May 19, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By "Modify PipeWire graph from Mixxx UI", I meant how currently in PortAudio backends, we can set the Mixxx Main/Headphone/Deck 1/2/3/4 outputs and Microphone 1/2/3/4 inputs from the Sound Hardware preference page, that UI is completely sufficient for routing to and from Mixxx. Only case it is lacking is to be able to input from multiple sources, or output to multiple sinks (if we want to address this too, we can add a plus (+) button to add additional source/sink to a single Mixxx input/output).

qpwgraph allows saving and loading patchbays. So if we edit the graph in qpwgraph (or from Mixxx UI, like mentioned above), we can save the patchbay, and qpwgraph sets the connections accordingly. We can include this feature in Mixxx, with above mentioned routing, to be independent of qpwgraph. Is this worth it?.
I do remember the discussion about the two modes, but I cannot recall the specifics or find the discussion, can you explain?

About accessing the analog volume, I still have to read about it, I will add this as TODO.

@daschuer daschuer May 20, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this worth it?.

IMHO not. When we look at the eco system of different audio application actions, it does not seem to be reasonable that any of these has its own idea of routing and storing the pipe wire graph. And finally may have evrn concurrent settings.

@pri-yan-shu pri-yan-shu May 23, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I checked, it is possible to access soundcard hardware volume. There is a very nifty program pw-volume for reference. One issue is that PipeWire in Pro Audio mode does not manage setting hardware volume, so if we want that we will have to look other way (use ALSA API?).

@pri-yan-shu pri-yan-shu May 23, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In normal mode, its a bit more complex, because even though we set the parameter on the soundcard, we need to mention the route we want to affect (in desktop case speaker or headphone route), so we need to keep track of the current route from the events.

@daschuer daschuer May 24, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if this is a manual choice, it would be a great benefit to be able to adjust the hardware volume from the controller.

* [ ] Update Mixxx UI from external graph changes

@daschuer daschuer May 19, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once the list is complete, you need to define mergable PRs with a testable goal and an estimated time frame.

Loading