That looks OK. Now why should the card be gone? If the card were taken by pipewire (have you disabled your cards in pipewire/pulseaudio?), the error should be EBUSY. But ENODEV (no device) should mean no device was recognized by your string specifications.
I do not understand your description. How does "going to camilladsp gui" fix the problem?
I do not understand your description. How does "going to camilladsp gui" fix the problem?
Well then IIUC the initial CDSP config uses some nonexisting device and only after applying your correct config to CDSP the new config overruns the initial non-working config. You need to manage to configure CDSP correctly from the start - that's something I cannot help with but others will certainly help.
Voila, did a second (or third) look at systemd service file as suggested. Thanks.
I have used User=pi in the file but had to remove it. Then it works...
From:
To:
I´ll remove that -debug flag now.
I have used User=pi in the file but had to remove it. Then it works...
From:
Code:
[Unit]
After=syslog.target
StartLimitIntervalSec=10
StartLimitBurst=10
[Service]
Type=simple
User=pi
WorkingDirectory=~
ExecStart=camilladsp -s camilladsp/statefile.yml -w -o camilladsp/camilladsp.log -l error -p 1234
Restart=always
RestartSec=1
StandardOutput=journal
StandardError=journal
SyslogIdentifier=camilladsp
CPUSchedulingPolicy=fifo
CPUSchedulingPriority=10
[Install]
WantedBy=multi-user.targetTo:
Code:
[Unit]
After=syslog.target
StartLimitIntervalSec=10
StartLimitBurst=10
[Service]
Type=simple
#User=pi
#WorkingDirectory=~
ExecStart=camilladsp -s /home/pi/camilladsp/statefile.yml -w-o /home/pi/camilladsp/camilladsp.log -l error -p 1234
Restart=always
RestartSec=1
StandardOutput=journal
StandardError=journal
SyslogIdentifier=camilladsp
CPUSchedulingPolicy=fifo
CPUSchedulingPriority=10
[Install]
WantedBy=multi-user.targetI´ll remove that -debug flag now.
Hello,
After 24h of wrestling with this, looks like I need some help.
I can't get CamillaDSP to produce any output.
samplerate: 48000
chunksize: 4096
capture:
type: CoreAudio
device: "BlackHole 2ch"
channels: 2
format: FLOAT32LE
playback:
type: CoreAudio
device: "MacBook Pro Speakers"
channels: 2
format: FLOAT32LE
Attempts so far:
I'm looking for suggestions on how to troubleshoot this further. Is there something I'm overlooking in my config or setup? Any advice would be greatly appreciated.
After 24h of wrestling with this, looks like I need some help.
I can't get CamillaDSP to produce any output.
- Setup: CamillaDSP on MacOS Ventura 13.3.1, 2019 MBP. Configured to capture audio from "BlackHole 2ch" and output through "MacBook Pro Speakers" or "SABAJ USB AUDIO"
- Problem: No sound output. I'm able to run CamillaDSP, but is not capturing input and/or not producing output (gui shows no input/output signs of life)
- Current config:
samplerate: 48000
chunksize: 4096
capture:
type: CoreAudio
device: "BlackHole 2ch"
channels: 2
format: FLOAT32LE
playback:
type: CoreAudio
device: "MacBook Pro Speakers"
channels: 2
format: FLOAT32LE
Attempts so far:
- Ensured BlackHole is functional with other apps.
- Ensured sample rate consistency in Audio MIDI Setup.
- Restarted Core Audio and CamillaDSP multiple times.
- Tested audio routing through BlackHole.
- Adjusted chunk sizes and sample rates
- Tried Soundflower
- Tried changing formats or omitting them
- Tried different outputs incl. SABAJ USB AUDIO
I'm looking for suggestions on how to troubleshoot this further. Is there something I'm overlooking in my config or setup? Any advice would be greatly appreciated.
Attachments
As
Do we need to POST to set single parameters, or are my syntax incorrect?
What I'm trying to implement is to have the volume control in Material Skin (MS) forward control values to CDSP. I can do this with CLI and Python. But where thinking rather than have a service pulling CLI information from LMS a lightweight implementation would be to simply have MS send command from its UI direcly to CDSP's web api. Preferd without having to mess with adding a new FORM on MS UI.
http://192.168.1.128:5000/api/getparam/volume return current main faider setting I where hoping a simple GET would set volume as in http://192.168.1.128:5000/api/setparam/volume?-12.4Do we need to POST to set single parameters, or are my syntax incorrect?
What I'm trying to implement is to have the volume control in Material Skin (MS) forward control values to CDSP. I can do this with CLI and Python. But where thinking rather than have a service pulling CLI information from LMS a lightweight implementation would be to simply have MS send command from its UI direcly to CDSP's web api. Preferd without having to mess with adding a new FORM on MS UI.
Yes you need a POST. There is no documentation of the api endpoints , but you can see their definitions here: https://github.com/HEnquist/camilla...373dfad4c3d731c3155e54f/backend/routes.py#L38
just my 2ct, working in IT. These restrictions to GET/POST are mostly just "cosmetic", trying to adhere to REST standards. If you can, just make these accept either POST and GET requests. Makes people's lives using your API a lot easier.
That backend is built together with the gui, for the gui. It's not really intended for other consumers.There isn't really any grand strategy for the endpoints and they change whenever the gui needs them to. That's also why they aren't documented, it's not intended as a public api.
This issue is now resolved, so building the GUI dependencies with Python 3.12 works now.
The next issue I came across was getting a system service to run the GUI directly from the Python Venv as created by the setup script from Github.
/home/username/camilladsp/camillagui_venv/bin/python /home/username/camilladsp/gui/main.py was working correctly from the command line, however when run from a system service was failing with error 203. Turns out SELinux was blocking the execution of the symlink in the Venv bin directory. Running sealert -l "*" confirmed the SELinux denial and provided the correct instructions for resolving the problem. Running Fedora 39.
This will be solved in v2.0.2! PR here: https://github.com/HEnquist/camilladsp/pull/319
It looks like CoreAudio in coms cases replies with a null pointer when asking for the clock source name. The PR adds a check for this.
From post #4,610 - If anyone interested I finished a little daemon that will subscribe to LMS CLI and forward volume changes ment for the Player to CamillaDSP. It rescale values and forward them to CamillaDSP main volume slider.
It make use of a funtion in Material Skin where players loked to 100% still can have its volume slider enabled. Legacy Logitech devises should be also have this ability through some trickery by installing any plug that have similar functionality - see more at github
https://github.com/StillNotWorking/.../volume_from_lms#adjust-volume-on-camilladsp-
It make use of a funtion in Material Skin where players loked to 100% still can have its volume slider enabled. Legacy Logitech devises should be also have this ability through some trickery by installing any plug that have similar functionality - see more at github
https://github.com/StillNotWorking/.../volume_from_lms#adjust-volume-on-camilladsp-
For month I've had an issue with my Win10 machine running Firefox that have given me some consern. As we know SSD have a limited lifespan when we do frequently writes to the disc. Well, on my laptop the Drive LED is blinking constantly just like we see when running backup or indexing.
Yesterday I finally found the culpit is CamillaDSP UI. With the web page opens all browser I've testet with seem to now access the SSD drive. @HenrikEnquist - can you verify if this is read or more harmfull writes the brower are performing?
Material Skin do simliar, but less frequent disk access.
Yesterday I finally found the culpit is CamillaDSP UI. With the web page opens all browser I've testet with seem to now access the SSD drive. @HenrikEnquist - can you verify if this is read or more harmfull writes the brower are performing?
Material Skin do simliar, but less frequent disk access.
@DEQ+TheEnd how often does it blink? Do you see it no matter which tab in the gui is active? I think it's just a read so it should be harmless, but there should be no need to do it continuously.