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

Jump to Latest
M

mdsimon2

Member
Joined 2013
You are setting your playback device as default:CARD=UltraLitemk5 which seems to be using some sort of format conversion as you are specifying 8 output channels. The MOTU changes channel counts as you change sample rates so I imagine that is part of your issue.

If you are going to stay at a single sample rate, I suggest you specify your playback device as hw:UltraLitemk5 and use the correct number of playback channels in your configuration, i.e. 44/48 = 22, 88/96 = 18, 176/192 = 10.

Michael
 
  • Thank You
  • Like
Reactions: 1 users
K

k3rry

Member
Joined 2023
HenrikEnquist said:
This would happen if there is something preventing the config from working when started by systemd. That could be for example that it starts too early, before the dac is available. The systemd service logs should show what is going wrong.
Click to expand...
Thanks for the quick reply, a 10 second delay before starting Camilla DSP solved it. Big thanks for the awesome software and incredible support. You are appreciated 🙏
 
W

Wirrunna

Member
Joined 2016
Henrik,
Thank you for CamillaGUI V2.1.1

Here is a first go at documenting Import Config from REW.
Too big with all the screenshots, so it is a zipped PDF aimed at a user that can make a measurement with REW.

Any chance of adding a process to import .dbl files from rePhase into the Filters folder ?
 

Attachments

  • 1 Measure drivers using REW and then EQ revised.pdf
    4 MB · Views: 56
  • Like
Reactions: 1 user
W

Wirrunna

Member
Joined 2016
HenrikEnquist said:
You can do that in the Files tab. There is a fir coeff file listing under the config files, and there is a button for uploading.
Click to expand...
Thank you, just tried it and it worked.
I'm updating and expanding the guide I wrote a while ago, so I will add that method of getting rePhase .dbl files into CamillaDSP.
It makes me wonder how many other bits of magic there are that I haven't discovered.
 
  • Like
Reactions: 1 user
Q

Quickmcj

Member
Joined 2015
HenrikEnquist said:
You should still use pipewire! What I mean is that you should let pipewire output to an Alsa loopback, and let Camilladsp capture from that via the Alsa backend. The alternative is to define a null-sink in pipewire and let camilladsp capture from that via the PulseAudio backend. The Alsa loopback has several advantages, where the most important one is that it supports adjusting the virtual sample clock. Camilladsp can use that to sync it to the dac. That's not possible with the null-sink, so you need to use the asynchronous resampler to sync.


Oops that's a bit misleading, will fix.


You need it!
Click to expand...
I am trying a new setup where I am not using the standard Alsa Loopback method with a pipewire sink for desktop audio into camilladsp (2.0.3).

If installing latest Fedora 39 and keeping pipewire and wireplumber completly vanilla, I have no luck in using the camilladsp pulseaudio backend to connect to either monitor outputs of a virtual pipewire sink, or to a "coupled stream" (Virtual Devices) where virtual sink input is forward to a virtual source, then used as capture device in camilladsp. Nothing pipewire related seems to work with the pulseaudio backend in camilladsp, log -v serves lemons:

"
2024-03-22 14:24:15.832269 ERROR [src/bin.rs:307] Capture error: PulseAudio error: Connection refused, code: 6
2024-03-22 14:24:15.832293 DEBUG [src/bin.rs:309] Error while starting, release barrier
"
This also happens with an entirely newly created, unused basic virtual sink via pactl load-module, no connection on monitor. Gnome sound settings will connect to the monitor outputs to said sink (for showing output on the simpel spl meter). Can be visualized with coppwr.

Anybody have had any luck using pulseaudio backend in camilladsp (2.0 onward) with vanilla pipewire, bypassing alsa loopback method? I may have confused myself by now!
 
Last edited:
TNT

TNT

Member
Joined 2003
Paid Member
I'm getting crazy ;D ..... Please add naming to channels that is consistent between Mixer and Pipeline... they are the same - it must be possible.

Mixer: Destination
=
Pipeline: Channel

and, let the user assign an own name; e.g. Right_HF etc....

Pretty please - to keep me sane...

//
 
Q

Quickmcj

Member
Joined 2015
HenrikEnquist said:
That looks as if it can't connect to pipewire at all. Is it possible that camilladsp started before pipewire? Do you start it with systemd or manually?
Click to expand...
Hi Henrik

I start it with systemd, I tried using "ExecStartPre=/bin/sleep 10", but makes no difference. I also start and stop the service via systemctl manually.

If I change the capture device in camilladsp to alsa and use the null provided, camilladsp will start running. When I change back to pulse audio backend and use any entry I can imagine usable, including manually created sinks via pactl or pw-cli (or a source but not using monitor ports), camilladsp will not proceed from "Starting" and give connection refused, code 6 in its log.

I am not sure the .monitor syntax is still valid with pipewire, I assume so (So one can do "my-sink.monitor" as entry in Capture device for camilladsp. I use "node.name" from pipewire, not "media.name" or "node.description"). Monitor ports seem avaliable as Gnome Sound Settings will attach to those for input for its visual dbfs meter, seen in coppwr or helvum.

Some kind of permission error possibly? Something wireplumber related?

You can see on attached screenshots that gnome settings and a random audio application will attach to the sinks monitor ports (That sink is created with coupled stream Virtual Device - Coupled stream), but I currently cannot get camilladsp to do the same.
 

Attachments

  • Screenshot from 2024-03-19 20-12-54.png
    Screenshot from 2024-03-19 20-12-54.png
    35.8 KB · Views: 31
  • Screenshot from 2024-03-19 20-20-55.png
    Screenshot from 2024-03-19 20-20-55.png
    53.9 KB · Views: 29
F

fb

Member
Joined 2005
I can confirm the systemd service has to run as user, however I would advise against going down this route and just stick to the standard ALSA / Pipewire mix with CamillaDSP service running as root. I spent many hours trying to fix latency issues running direct to Pipewire and could never get it sorted out - latency was sometimes fine but would randomly push out to 2-3 seconds. I went back to the standard setup and haven’t had an issue since.
 
  • Like
Reactions: 1 user
Q

Quickmcj

Member
Joined 2015
HenrikEnquist said:
So then CamillaDSP probably runs as root. Pipewire and Pulseaudio are user services, root is probably not allowed to to connect. Try starting CamillaDSP manually from your normal user account. If that works, then you can modify the service file so that CamillaDSP runs as that user.
Click to expand...
I am running it as my regular user, but will try to load it entirely manual just to make sure. User error cannot be ruled out by any means!
Edit: It runs when I launch manually so I messed up! Will figure out how to launch as user via systemd.

Here is the service file for camilladsp:

[Unit]
After=syslog.target
StartLimitIntervalSec=10
StartLimitBurst=10

[Service]
Type=simple
User=michael
WorkingDirectory=~
ExecStartPre=/bin/sleep 10
ExecStart=camilladsp -s camilladsp/statefile.yml -w -o camilladsp/camilladsp.log -p 1234 -l debug
Restart=always
RestartSec=1
StandardOutput=journal
StandardError=journal
SyslogIdentifier=camilladsp
CPUSchedulingPolicy=fifo
CPUSchedulingPriority=10

[Install]
WantedBy=multi-user.target
 
Last edited:
You must log in or register to reply here.
Top Bottom