CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc

Long storey ... but basically I have been using only kodi for media consumption and I now wish to ALSO use other software (streaming via browser). I DO NOT have an AVR ... just going from player on PC out to multi-channel DAC ... all in a single x866 box (nuc)

Pipewire allows multiple sources to send audio to single destination - like Pulse but better (new in shiny wrapper !)

I used Loopback because it looked easier than trying to write a custom graph and builds on the existing approach (kodi direct to alsa loopback) which was not "shareable"

The 8 channel problem is of secondary interest since I actually only have 6 speakers ... BUT I was unable to rule some channel mapping issues out without accessing all 8 of the loopback channels normally allocated

I tried using the alsa facilities dsnoop, multi and route but none of them were reliable & stable. Pipewire is stable and produces a pretty good outcome ... note that it also offers some up-mix facilities that look really attractive .. if only (a) I could get the basics right (b) it would selectively upmix .. vs my current automated sledge-hammer approach
 
I used Loopback because it looked easier than trying to write a custom graph and builds on the existing approach (kodi direct to alsa loopback) which was not "shareable"
I understand you want to use PW. But please excluse my ignorance - why linking alsa speaker-test source to alsa loopback sink and alsa loopback source to alsa CDSP sink, instead of linking alsa speaker-test (or the actual player) source to alsa CDSP sink, without the loopback in the middle? IMO the alsa loopback inside PW chain only increases latency and presents possible timing issues.
 
Re-reading Henrik's documentation .... should I
  1. create a null sink
  2. configure Camilladsp to read from the null sink
  3. configure the players to write to the null sink
?
Yes, that's the basic process - something not obvious though is that Pipewire and Pulseaudio run as user services, whereas the standard CamillaDSP install using the alsa loopback runs as a system/root service. You'll need to be running CamillaDSP as the same user as Pipewire otherwise they won't talk to each other.

I'm very interested to see how you go with this, I tried to use this method previously and had massive latency issues (variable and often progressively increasing latency). Maybe a configuration issue on my part? I tried a lot of different pipewire settings, but maybe it was a CamillaDSP buffer setting. I'm back to the alsa loopback these days with no issues, but I only use 2 channel loopback.
 
I tried the Pipewire null sink, defined as
{ factory = adapter
args = {
factory.name = support.null-audio-sink
node.name = "RE-null-sink"
media.class = Audio/Sink
audio.channels = 6
audio.position = [ FL FC FR RL RR LFE ]
object.linger=1
monitor.channel-volumes = true
monitor.passthrough = true
resample.quality = 10
}
}
it works, in that audio data flows BUT
  1. Data is very slow to arrive at Camilladsp
  2. Channel mappings are still messed up
  3. Still no access to all 8 channels defined, camilladsp fails to open the src when requesting 8 channels ... see error message from log ... but 6 channels works A Ok
2025-02-17 20:50:00.015690 DEBUG [src/bin.rs:272] Playback thread ready to start
2025-02-17 20:50:00.016649 ERROR [src/bin.rs:314] Capture error: PulseAudio error: Invalid argument, code: 3
2025-02-17 20:50:00.016667 DEBUG [src/bin.rs:316] Error while starting, release barrier

Actual mappings from speaker-test to Camilladsp, where null sink is pipewire default and alsa default points to pulseaudio(pipewire), so for testing 6 channels one at a time so we can see where they land
speaker-test -c 6 -s 1
.... and they're still being consolidated ... see table below
Speaker Test Id #Channel NameChannel IndexCamilladsp Channel
1FL00
2FC12
3FR23
4RR35
5RL45
6LFE52
 
@fb

yeah, seems to work better with loopback than null sink. Much much much less latency with loopback
It's just the channel mappings driving me crazy and both loopback and nullsink exhibit the same wierd channel mappings. Would be nice to obtain all 8 channels too ... but that's much less important

fwiw I have created the following user specific configs...
  1. ~/config/pipewire/pipewire.conf enable / update with <systemctl --user restart wireplumber pipewire pipewire-pulse pipewire-pulse.socket>
  2. ~/.config/systemd/user/camilladsp.service enable with <systemctl --user enable camilladsp> note that camilladsp also restarts when wireplumber restarts
  3. ~/camilladsp/configs/....
  4. /etc/systemd/system/camillads_gui.service enable with <sudo systemctl enable camilladsp_gui>
and some other stuff to run a systemd timer to run a pyhton script which inspects kodi current state and changea camilladsp config on the basis of (a) type of media playing (b) number of source channels ... this allows different up-mixing based on channel count and TV vs Music

I have been watching video on the Kubuntu 22.04 machine using piepewire-loopback and there's no noticeable lag .... plus it's been completely stable for the last few days.
The "combined" Centre & LFE channels are just split using frequency ... surround channels don't matter to me that much they're just ambience ... so it works but not the not greatest

Maybe we shoudl take this to another thread.
 
  • Like
Reactions: fb
redger, I think I misunderstood your initial config. Have you tried the following setup? This (with GNOME instead of KDE) is what I'm using to allow multiple software (Kodi, shairport-sync, browser etc) to pass audio to camilladsp:
KDE (or speaker-test) -> Pipewire api.alsa.pcm.sink device -> alsa loopback device hw:Loopback,0,0 (or hw:0,0,0 on latest Fedora) -> camilladsp alsa input device hw:Loopback,1,0 -> camilladsp outputting to alsa multichannel soundcard

Pipewire api.alsa.pcm.sink device setup per your previously posted pipewire.conf, but:
 
TNT,

In my excitement (I know you know) NOW became not. Sure wish this was not such an esoteric item. The price of them is high and only two of them will work with Linux - DIGIGRAM seems to be the obvious choice. I will get up the courage to order it in a few days and then the real fun can begin.

Take care,
 
  • Like
Reactions: TNT
fb, thanks for the suggestion. It was only when I (a) installed qpwgraph and (b) tried the null sink that I realised there was a monitor function to these sinks so the loopback "source " definition is unnecessary. I just tried configuring camilladsp to read from "my-loopback-snk.monitor" and it works ! My working config is as you described it ... but I may just go one of
  1. player --> pipewire loopback (alsa Loopback,0) as "my-loopback-snk" --> camilladsp read "my-loopback-snk.monitor" --> camilladsp write to dac
  2. player --> pipewire null sink as "my-null-snk" --> camilladsp read "my-nullsnk.monitor" --> camilladsp write to dac
both of the above "work" in the sense that audio data flows. But both of them exhibit the same channel mapping issues and channel count limit

As for rates, formats etc, yes I have tried them. I set the pipewire rate globally (to 96000) and found the default format etc. acceptable (looks like pipewire uses float32 internally by choice, which is fine by me ..... I set camilladsp to reformat on output to S24LE3 as required by the DAC).
My full pipewire config file (not posted) contains all sorts of commented lines as I tried various combinations of rate & format etc etc but decided most were unnecessary so stripped back to a "minimum" for debugging
 
But both of them exhibit the same channel mapping issues and channel count limit
Only other thing I can think of is that Pipewire or Pulseaudio is messing with the profile of the sink/loopback or audio devices. Might be worth checking in pavucontrol (Volume Control):
  • on the Configuration tab, checking if there are different profile options to try
  • on the Recording and Output tabs, ungrouping the channels to confirm channel count
 
I've just created an "issue" on the camilladsp github repository .... after testing with
  • speaker-test --> pipewire loopback sink --> pipewire dac
where qpwgraph was used to connect the loopback-sink.monitor directly to the dac ... and that worked without issue, both channel mappings and access to full channel count were OK

Note that alsa default is set to pulse (which really means pipewire via the compatibility layer) so speaker-test is actually sending output via pipewire
 
  • Like
Reactions: fb
I'm having an intermittent fault with my rpi5 and dac8x setup. Randomly, (after 2mins - 2 hours) the sound switches to mono and very euphonic sounding. I can cure the fault by switching to another config and back again. I've tried various input settings but with the same behaviour. Nothing of interest appears on the Log file. My config is attached.

Anyone got any ideas?
 

Attachments

sorry to be dim. where and how do I use the top command?
In the terminal.

Open the terminal, they just type "top" and hit enter.

Here is a screenshot of mine:

Top.png
 
Last edited: