You need to make some changes to get things loaded on boot. I would recommend to use the alsa loopback, not a pipewire null-sink.
Loopback kernel module: https://github.com/HEnquist/camilladsp-config#step-2-load-loopback-driver-on-boot
Pipewire config: https://github.com/HEnquist/camilladsp-config#pipewire
Loopback kernel module: https://github.com/HEnquist/camilladsp-config#step-2-load-loopback-driver-on-boot
Pipewire config: https://github.com/HEnquist/camilladsp-config#pipewire
Thanks for reply!
Could you elaborate on why Alsa loopback and not Pipewire? I thought that using Alsa could cause some strange issues when on a desktop like mine, since alsa can only cope with one source at a time.
If choosing not to use Pipewire, then there is no need to make changes in Gnome sound settings?
PS; The links you provided is much appreciated. Actually I was looking for that readme, but for the life of me I couldn't find it. Under Pipewire paragraph it's referred to with a link, but camilladsp-config are not listed there. Attached screenshot of what I mean
Anyhow, step 6 in configuration example is about Pipewire and desktop audio. It says it's optional but still not sure if I need it or not
Thanks in advance for any feedback
Anyhow, step 6 in configuration example is about Pipewire and desktop audio. It says it's optional but still not sure if I need it or not
Thanks in advance for any feedback
Attachments
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!
Hej, I’m having a problem with very short interrupts in the sound when plying from both HD and streaming from qobuz. I’m getting the following reports from camilla:
And I’m using the following config:
I’ve tried to change some of the parameters without any clear improvment. Any suggestion on how to resolve this is much appreciated!
Br Thomas
And I’m using the following config:
I’ve tried to change some of the parameters without any clear improvment. Any suggestion on how to resolve this is much appreciated!
Br Thomas
I have seen this with Virtual Cable. Don't quite know what causes it, and I haven't found any way to trigger it (or avoid it). I haven't seen it with any other device than virtual cable, so I think it doesn't quite like the event driven mode that camilladsp uses in the wasapi backend. The alternative would be to use the older polling mode, but camilladsp doesn't support that because it's inefficient and clunky.
Can you try instead with hifi cable? It's quite similar but simpler than virtual cable.
https://vb-audio.com/Cable/index.htm
Can you try instead with hifi cable? It's quite similar but simpler than virtual cable.
https://vb-audio.com/Cable/index.htm
hello,
i am user of camilladsp since ca. 1.5 years, I use it in my main system and all works fine,
These last days i have started experimenting with one of these multichannel HDMI extractors connected to my raspberry pi:
to make it work with camilladsp, i use the KMS HDMI driver:
dtoverlay=vc4-kms-v3d
and in camilladsp i use the alsa device:
iec958:vc4hdmi0
This works with these extractors and allows me to output 8 channels up to 24bit 192kHz (i modded the card to output 4x stereo SPDIF outs)
However, i am experiencing a very extrange behaviour. The sound each physical channel of the card outputs changes from one channel to another randomly every couple of minutes.
I tried with this card in the picture and with an amazon basics hdmi extractor that is based on the same chip, and i have exactly the same behavior.
I have the feeling it could be related to the driver but i have no clue.
Any similar experience or any idea of what could be happening and how to solve it?
thanks!
i am user of camilladsp since ca. 1.5 years, I use it in my main system and all works fine,
These last days i have started experimenting with one of these multichannel HDMI extractors connected to my raspberry pi:
to make it work with camilladsp, i use the KMS HDMI driver:
dtoverlay=vc4-kms-v3d
and in camilladsp i use the alsa device:
iec958:vc4hdmi0
This works with these extractors and allows me to output 8 channels up to 24bit 192kHz (i modded the card to output 4x stereo SPDIF outs)
However, i am experiencing a very extrange behaviour. The sound each physical channel of the card outputs changes from one channel to another randomly every couple of minutes.
I tried with this card in the picture and with an amazon basics hdmi extractor that is based on the same chip, and i have exactly the same behavior.
I have the feeling it could be related to the driver but i have no clue.
Any similar experience or any idea of what could be happening and how to solve it?
thanks!
hi Henrik
- downloaded a demo wav 8 channels file with a voice naming the different channels one by one here:
https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Samples/Microsoft/8_Channel_ID.wav
- stopped camilladsp service
- played the file entering:
aplay -c 8 -t wav -r 48000 -f S24_LE -D iec958:vc4hdmi0 ~/8_Channel_ID.wav
have been playing the file for a while several times. It plays the correct channels without any sweeping channels.
I notice as well that it plays the channels correctly, that is, the output labeled FR is FR, FL is FL, etc. while in camilladsp, besides the sweeping issue, the assignment of the channels was always random (what would not be a problem by itself, but wanted to mention).
I use camilladsp in a raspberry pi 4b running ubuntu server, all set up following mdsimon tutorial.
any help solving this will be very much appreciated.
- downloaded a demo wav 8 channels file with a voice naming the different channels one by one here:
https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Samples/Microsoft/8_Channel_ID.wav
- stopped camilladsp service
- played the file entering:
aplay -c 8 -t wav -r 48000 -f S24_LE -D iec958:vc4hdmi0 ~/8_Channel_ID.wav
have been playing the file for a while several times. It plays the correct channels without any sweeping channels.
I notice as well that it plays the channels correctly, that is, the output labeled FR is FR, FL is FL, etc. while in camilladsp, besides the sweeping issue, the assignment of the channels was always random (what would not be a problem by itself, but wanted to mention).
I use camilladsp in a raspberry pi 4b running ubuntu server, all set up following mdsimon tutorial.
any help solving this will be very much appreciated.
@HenrikEnquist ah ok, i understand. Lets see if i can find a longer file. However, still calls my attention that the channel assignment is right, while in camilladsp the channel assigment is a mess from the start.
(edit: i think it will be faster to create my own with audacity)
@phofman I have not tried to play the test file through camilladsp. But after reading your post i have been trying to play it through LMS > squeezelite > camilladsp but i dont manage to find the way (if there is one) to play multichannel files in LMS. Other suggestions how to do it?
to add more info, the channel inconsistency issue happens with this setup:
stereo music -> alsa loopback 2 channels -> camilladsp 2 channel in 8 channel out -> HDMI out to the HDMI sound card
the way i recognize which channel is which is apply different gains, or strong high pass or low pass filters, or mute...
(edit: i think it will be faster to create my own with audacity)
@phofman I have not tried to play the test file through camilladsp. But after reading your post i have been trying to play it through LMS > squeezelite > camilladsp but i dont manage to find the way (if there is one) to play multichannel files in LMS. Other suggestions how to do it?
to add more info, the channel inconsistency issue happens with this setup:
stereo music -> alsa loopback 2 channels -> camilladsp 2 channel in 8 channel out -> HDMI out to the HDMI sound card
the way i recognize which channel is which is apply different gains, or strong high pass or low pass filters, or mute...
Last edited:
E.g. play the multichannel file in aplay -> snd_aloop -> CDSP with appropriate config. The point is to localize more the possible place where your problem occurs.
@phofman i think i need some help there.
I start again camilladsp, create a config that i believe seems ok to play this file (8channel, 48kHz, 24bit:
from the comand line, i enter:
aplay -c 8 -t wav -r 48000 -f S24_3LE -D hw:Loopback,0 ~/8_Channel_ID_long.wav
and i get no error, but i dont get any sound either....
I guess i am doing something wrong but i dont know what, i am not used to play files with aplay....
edit: sorry, got it, needed to play to Loopback,1
I start again camilladsp, create a config that i believe seems ok to play this file (8channel, 48kHz, 24bit:
from the comand line, i enter:
aplay -c 8 -t wav -r 48000 -f S24_3LE -D hw:Loopback,0 ~/8_Channel_ID_long.wav
and i get no error, but i dont get any sound either....
I guess i am doing something wrong but i dont know what, i am not used to play files with aplay....
edit: sorry, got it, needed to play to Loopback,1
Last edited:
ok, playing to the loopback and through camilladsp as phofman suggested:
aplay -c 8 -t wav -r 48000 -f S24_3LE -D hw:Loopback,1 ~/8_Channel_ID_long.wav
Some channels get mixed from start (not all of them and not always the same way, but sort or random) and by each two or three repeats (each ca. 2 minutes) some of them have changed again outputs. That is, the same experience than described in post #4110...
aplay -c 8 -t wav -r 48000 -f S24_3LE -D hw:Loopback,1 ~/8_Channel_ID_long.wav
Some channels get mixed from start (not all of them and not always the same way, but sort or random) and by each two or three repeats (each ca. 2 minutes) some of them have changed again outputs. That is, the same experience than described in post #4110...