Pipewire modules loading order

[wkl3968]

is there plan to migrate the audio system from pipewire-pulseaudio to just pipewire? sometimes the way the audio nodes bring up using pactl can be sequence dependent.

[hudiy]

is there plan to migrate the audio system from pipewire-pulseaudio to just pipewire? sometimes the way the audio nodes bring up using pactl can be sequence dependent.

pipewire-pulse is a compatibility layer for the old PulseAudio interface. This tool is part of the PipeWire package and has no dependencies on PulseAudio. As far as we know, there is no difference in loading modules between pactl and the PipeWire configuration file. What problem with the module loading order occurs in your setup?

https://docs.pipewire.org/page_man_pipe ... lse_1.html

[wkl3968]

I'm not an expert but I have been playing with custom snd card codec (Hifiberry DAC8x and ADC8x) together with Camilladsp. I always ran into issue how the audio nodes been generated along with custom pipewire, wireplumber, pro-audio. of course I leverage a lot of chatgpt to help me understand the code and help troubleshoot. here is one of the observation we had on how $EQ_Sink and $EC_Sink been arranged in the hudiy_startup.sh. if we swap it, a different kind of connection form. somehow pipewire and pulseaudio interaction is complicated. snippet from chatgpt after I swap the EQ and EC. Why would this happen?

Look carefully at the dependency chain:

HUDIY
│
module-ladspa-sink
│
master = echo_cancel_sink

But echo_cancel_sink doesn't exist yet when you're loading the LADSPA sink.

Normally, PulseAudio/PipeWire modules are supposed to resolve this once the master appears, but in PipeWire's Pulse compatibility layer the timing isn't always deterministic.

What likely happens is:

module-ladspa-sink is requested.
The Pulse compatibility layer begins constructing the graph.
During that process, module-echo-cancel gets loaded.
Echo cancel opens the ALSA device.
WirePlumber sees an active client and finishes exporting the ALSA card.
The LADSPA sink then attaches to the now-existing master.

Ironically, the "wrong" order gives WirePlumber time to finish creating the ALSA nodes.

[hudiy]

Module loading in PipeWire is asynchronous. The fact that the pactl command finishes does not mean that the module has already been loaded and integrated into the routing. The order in which modules are loaded does not matter, because once new virtual sinks appear, WirePlumber will generate the routing based on the sink_master parameters. The only problems we encountered while working with PipeWire were loading modules when an application is already using audio and when the sound card is detected after the modules have been loaded. In such cases, WirePlumber might not be able to generate the correct routing based solely on automatic/default rules.

In the default setup, Hudiy is the first application to use audio, and this happens only after the modules have been loaded (hudiy_startup.sh loads the modules first and only then launches Hudiy). All the audio devices we tested had very fast startup times and were ready well before the modules were loaded.

If in your setup you launch an application that uses audio before Hudiy, it is highly recommended to load the equalizer and echo cancel modules first to avoid routing issues. The same applies to DSP software you are using - if such software creates a virtual device or additional sinks, this must be included in the sink_master parameters of the modules loaded by hudiy_startup.sh.

Unfortunately, AI is really bad when it comes to PipeWire and its configuration. It hallucinates a lot and mixes up the behaviors of PipeWire and PulseAudio. It is definitely better to rely on the official documentation and the PipeWire Wiki:

https://docs.pipewire.org
https://pipewire.pages.freedesktop.org/wireplumber/
https://gitlab.freedesktop.org/pipewire ... wikis/home
https://gitlab.freedesktop.org/pipewire ... -/boards#/