Well then again ask google. If you do not need pipewire (which is useful only for a desktop device or switching/mixing devices but with CDSP it requires a much more involved setup), uninstall it. But some distributions bundle pipewire package with the desktop packages and uninstalling may not be trivial...Not sure what pipewire is.
How did you switch to USB Gadget mode and enable loopback? It seems a bit that my issue to get camilladsp-setrate to work properly is centered around these settings. Could you please do me the favour and send me a few screenshots of your camillaDSP devices settings? Especially also from the Capture Device and Playback Device drop down menus, to see which device you've selected. Attached you'll see what I mean, I've highlighted with the mouse curser the device from the drop down menu that plays audio in my setup currently. Thank you!I just saw your post. For installation I followed the installation instructions. At first I had a lot of issues trying to get it to work with SPDIF input. Once I got the WiiM Ultra, and on my Pi switched to USB Gadget mode and enabled loopback, it worked. I did increase the multiplier for the MAX_PAYLOAD_SIZE parameter in the setrate.h file.
I do use a USB-C Y-splitter cable, and it works well. I use this one:
https://a.co/d/6qQIX6C
Attachments
Here is the output:I do not know, the mapping between ID and name is listed e.g. byaplay -l
orls -l /proc/asound/
. Check on your system.
Code:
airharder@raspberrypi:~ $ aplay -l
** List of PLAYBACK Hardware Devices **
card 0: vc4hdmi0 [vc4-hdmi-0], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: vc4hdmi1 [vc4-hdmi-1], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 3: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 3: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 4: sndrpihifiberry [snd_rpi_hifiberry_dac8x], device 0: HifiBerry DAC8x HiFi pcm5102a-hifi-0 [HifiBerry DAC8x HiFi pcm5102a-hifi-0]
Subdevices: 0/1
Subdevice #0: subdevice #0
Code:
airharder@raspberrypi:~ $ ls -l /proc/asound/
total 0
dr-xr-xr-x 4 root root 0 Oct 18 18:47 card0
dr-xr-xr-x 4 root root 0 Oct 18 18:47 card1
dr-xr-xr-x 4 root root 0 Oct 18 18:47 card2
dr-xr-xr-x 10 root root 0 Oct 18 18:47 card3
dr-xr-xr-x 4 root root 0 Oct 18 18:47 card4
-r--r--r-- 1 root root 0 Oct 18 19:34 cards
-r--r--r-- 1 root root 0 Oct 18 19:34 devices
lrwxrwxrwx 1 root root 5 Oct 18 19:34 Loopback -> card3
-r--r--r-- 1 root root 0 Oct 18 19:34 modules
dr-xr-xr-x 4 root root 0 Oct 18 19:34 oss
-r--r--r-- 1 root root 0 Oct 18 19:34 pcm
dr-xr-xr-x 6 root root 0 Oct 18 19:34 seq
lrwxrwxrwx 1 root root 5 Oct 18 19:34 sndrpihifiberry -> card4
-r--r--r-- 1 root root 0 Oct 18 19:34 timers
lrwxrwxrwx 1 root root 5 Oct 18 19:34 UAC2Gadget -> card2
lrwxrwxrwx 1 root root 5 Oct 18 19:34 vc4hdmi0 -> card0
lrwxrwxrwx 1 root root 5 Oct 18 19:34 vc4hdmi1 -> card1
-r--r--r-- 1 root root 0 Oct 18 19:34 version
I use the GUI, as I don't know much about Linux commands. All Linux commands, I learned / looked up only in the context of setting up CamillaDSP and CamillaDSP-Setrate. What is the exact file name of the CDSP config file? I'll try to have a look. This is what I see in the CamillaDSP directory:Well, the GUI config is another layer. I would recommend to modify the CDSP config file directly, no extra layer of complexity. But your choice...
Code:
airharder@raspberrypi:~ $ dir
Bookshelf camilladsp-setrate Documents Music Public Videos
camilladsp Desktop Downloads Pictures Templates
airharder@raspberrypi:~ $ cd camilladsp
airharder@raspberrypi:~/camilladsp $ dir
camilladsp-linux-aarch64.tar.gz camillagui.zip configs
camilladsp-linux-aarch64.tar.gz.1 camillagui.zip.1 statefile.yml
camilladsp.log camillagui.zip.2
camillagui coeffs
Where do I find the g_audio config?g_audio config
By now I understood, how I can open and edit the .yml camillaDSP configuration file (see screenshot). I also changed the device in nano to hw:UAC2Gadget, but that still doesn't allow me to play sound, so I reverted to plughw:CARD=UAC2Gadget,DEV=0 for now.
Attachments
Hi,
I'm am interested in the secondary functionality of Setrate. I have a RPi hooked up via USB to a set of active KEF LSX II speakers that have a build in DAC.
I mainly use the RPi as a streamer with either SharePoint Sync or TidalConnect, not as a USB gadget. My issue is waking up the DAC from sleep which currently requires me to start playing music and then manually switching profiles a few times in CDSP. I switch profiles with a remote using FLIRC, so it's not a major issue.
However, it would be cool to have an automated way of waking up the DAC, just to make it feel less DIY. I read the readme, and am aware that it's not it's intended purpose setrate. I tried experimenting but was so far unable to make this work. Am I trying to do something that is not possible?
Thank you in advance!
I'm am interested in the secondary functionality of Setrate. I have a RPi hooked up via USB to a set of active KEF LSX II speakers that have a build in DAC.
I mainly use the RPi as a streamer with either SharePoint Sync or TidalConnect, not as a USB gadget. My issue is waking up the DAC from sleep which currently requires me to start playing music and then manually switching profiles a few times in CDSP. I switch profiles with a remote using FLIRC, so it's not a major issue.
However, it would be cool to have an automated way of waking up the DAC, just to make it feel less DIY. I read the readme, and am aware that it's not it's intended purpose setrate. I tried experimenting but was so far unable to make this work. Am I trying to do something that is not possible?
Thank you in advance!
No idea how you load the kernel module in your setup specifically. There the module would have its params specified (c_rate, c_size, etc.).Where do I find the g_audio config?
If you want me to help, please do not post screenshots. Post the whole text info wrapped into the code tag so that one can read it easily.By now I understood, how I can open and edit the .yml camillaDSP configuration file (see screenshot).
I also changed the device in nano to hw:UAC2Gadget, but that still doesn't allow me to play sound, so I reverted to plughw:CARD=UAC2Gadget,DEV=0 for now.
Likely the accepted device format (samplerate?) does not fit the configured one in CDSP. CDSP logs would tell the details. Did you actually check the CDSP logs?
The secondary functionality of camilladsp-setrate forces CamillaDSP to reload its configuration setting the samplerate to that of the stream being captured by the USB Gadget. If you do not redirect your stream to a capture device, camilladsp-setrate has no information about the current samplerate and will set the wrong value.Am I trying to do something that is not possible?
So camilladsp-setrate Is not useful in your case, but you could take inspiration from its code to get what you want.
Thank you for the reply. I tried to redirect to Loopback, but I wasn't sure if I did it correctly, and am aware it was not recommended from the readme.If you do not redirect your stream to a capture device, camilladsp-setrate has no information about the current samplerate and will set the wrong value.
It was this part that made me think I might make it work anyway:
https://github.com/marcoevang/camilladsp-setrate
This describes my problem pretty much exactly. Since I don't need to switch sample rate, I just needed to keep this functionality active. I was hoping it would just read the samplerate from the Loopback and reload the config for me until the DAC wakes up."CamillaDSP as it must be, stops working when the playback device is no longer available. This happens, for example, when your DAC is switched off or you switch to another input. Unfortunately, CamillaDSP remains blocked even when the playback device becomes available again."
Ok. Sadly, I don't know how to code, but maybe I could make a suggestion to Henrik Enquist to incorporate such a feature directly into CDSP. Probably a lot of other users will have DACs connected that will autosleep.So camilladsp-setrate Is not useful in your case, but you could take inspiration from its code to get what you want.
Thanks a lot again for your time!
I am not expert enough to help you about using the loopback device. But please note that in camilladsp-setrate you must use the --device flag to specify the capture side of the loopback device as capture device.I tried to redirect to Loopback,
Unfortunately, these days I have no time to do some tests.
Maybe you could modify the udev rule (.rules file) to have CamillaDSP restarted when the USB DAC wakes up (and get rid of camilladsp-setrate).Sadly, I don't know how to code
What is required to wake it up? Most devices that sleep keep the digital parts in a working state and only shut down amplifiers etc, where there is significant power to save. This seems to partly shut down the digital side as well, to end up in some weird state where things look ok but don't actually work.maybe I could make a suggestion to Henrik Enquist to incorporate such a feature directly into CDSP. Probably a lot of other users will have DACs connected that will autosleep.
@mevang
camilladsp-setrate --device hw:Loopback
@HenrikEnquist
kef@kef:~ $ aplay -D hw:II,0 /media/usb/pinknoise16.wav -f S16_LE -c2 -r44100
Playing WAVE '/media/usb/pinknoise16.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
aplay: pcm_write:2127: write error: No such device
For the case of CamillaDSP, it's the same behavior. When starting playing CDSP will in very quick succession go: "Starting", "Running", "Inactive" (the speakers makes the "puff" sound).
A subsequent click on "Apply to DSP" (or switching to another profile) will put CDSP back in "Starting", "running" and the music will start playing.
So I assume CDSP gets the same "write error: No such device" as aplay on the first attempt. The electronics wake up from the signal and is good to go.
The speakers have two power save modes. ECO which KEF claims to be the most power savings. With this mode, the speaker will disappear completely from aplay -l, same as if unplugging the cable. I this mode the speaker will only wake from a wifi signal (which I completely bypass with the RPi).
To allow the speakers to wake from a USB signal, the speakers needs to be taken out of ECO mode and use a 30 min timer with no signal before they shut off.
I can't say if there is a bug in their firmware, and it shuts down the DAC when it shouldn't in this mode? Or maybe KEF are just hunting every little bit of savings they can get?
Thank you very much for chiming in as well!! It's much appreciated both of you.
And I want to say again that this is a minor issue for me that I can work around this with a FLIRC and a remote to switch profiles. From the description of setrate, I just wanted to give it a try to see if it would solve this minor issue.
And I also want to thank very much for all the work you do for the community, at this point I could not imagine not having CDSP running along side any speakers. 🙂
This is the command I used:please note that in camilladsp-setrate you must use the --device flag to specify the capture side of the loopback device as capture device.
camilladsp-setrate --device hw:Loopback
Thanks for the suggestion, I will look into that.Maybe you could modify the udev rule (.rules file) to have CamillaDSP restarted when the USB DAC wakes up (and get rid of camilladsp-setrate).
@HenrikEnquist
This is what I figured out too. They still present themselves when using aplay -l. But when trying to play a wav file to them using aplay it returns a write error. For example:This seems to partly shut down the digital side as well, to end up in some weird state where things look ok but don't actually work.
kef@kef:~ $ aplay -D hw:II,0 /media/usb/pinknoise16.wav -f S16_LE -c2 -r44100
Playing WAVE '/media/usb/pinknoise16.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
aplay: pcm_write:2127: write error: No such device
I assume the "audio signal" (digital signal - don't know how to describe it) wakes up the speakers (you can hear physically a slight "puff" from the speakers), and on the next attempt they will play.What is required to wake it up?
For the case of CamillaDSP, it's the same behavior. When starting playing CDSP will in very quick succession go: "Starting", "Running", "Inactive" (the speakers makes the "puff" sound).
A subsequent click on "Apply to DSP" (or switching to another profile) will put CDSP back in "Starting", "running" and the music will start playing.
So I assume CDSP gets the same "write error: No such device" as aplay on the first attempt. The electronics wake up from the signal and is good to go.
I can't say, but KEF claims very low power usage in standby. Bu: since I experimented with it I can explain the behavior in the different modes they offer.Most devices that sleep keep the digital parts in a working state and only shut down amplifiers etc, where there is significant power to save.
The speakers have two power save modes. ECO which KEF claims to be the most power savings. With this mode, the speaker will disappear completely from aplay -l, same as if unplugging the cable. I this mode the speaker will only wake from a wifi signal (which I completely bypass with the RPi).
To allow the speakers to wake from a USB signal, the speakers needs to be taken out of ECO mode and use a 30 min timer with no signal before they shut off.
I can't say if there is a bug in their firmware, and it shuts down the DAC when it shouldn't in this mode? Or maybe KEF are just hunting every little bit of savings they can get?
Thank you very much for chiming in as well!! It's much appreciated both of you.
And I want to say again that this is a minor issue for me that I can work around this with a FLIRC and a remote to switch profiles. From the description of setrate, I just wanted to give it a try to see if it would solve this minor issue.
And I also want to thank very much for all the work you do for the community, at this point I could not imagine not having CDSP running along side any speakers. 🙂
You should also indicate the device number to specify the capture side of the loopback deviceThis is the command I used:
camilladsp-setrate --device hw:Loopback
Ah, ok. I'm wondering if I even ever got setrate running then, because it gives an error message when I specify a subdevice (such as hw:Loopback,1).You should also indicate the device number to specify the capture side of the loopback device
I assumed it didn't need to specify a device as hw:UAC2Gadget is specified without device as well. And fails too if I e.g. use: hw:UAC2Gadget,1
What should actually happen when I use the command? If I don't specify anything (just setrate without parameters), I get a blank response, and have to press ctrl+C to get my cursor back. I assumed this was normal behavior and it means it's running?
The same happens if I use
camilladsp-setrate
camilladsp-setrate --device hw:UAC2Gadget
camilladsp-setrate --device hw:Loopback
Just the blank response. If I specify a device I get:
E.g:
:~ $ camilladsp-setrate -device hw:UAC2Gadget,1
ALSA lib conf.c:5516: (parse_args) Unknown parameter 1
ALSA lib conf.c:5687: (snd_config_expand) Parse arguments error: No such file or directory
ALSA lib control.c:1528: (snd_ctl_open_noupdate) Invalid CTL hw:UAC2Gadget,1
alsa_init START Fatal error: Cannot open alsa controls for the device hw:UAC2Gadget,1: No such file or directory
Or:
:~ $ camilladsp-setrate -device hw:Loopback,1
ALSA lib conf.c:5516: (parse_args) Unknown parameter 1
ALSA lib conf.c:5687: (snd_config_expand) Parse arguments error: No such file or directory
ALSA lib control.c:1528: (snd_ctl_open_noupdate) Invalid CTL hw:Loopback,1
alsa_init START Fatal error: Cannot open alsa controls for the device hw:Loopback,1: No such file or directory
What should actually happen if done correctly?
Thanks a lot again!
@xxAncientMarinerxx
First of all, I recommend you to do as suggested by @phofman and report your findings using text and not screenshots. It is easy, why not?
camilladsp-setrate requires the specification of a capture device providing the sample rate of the current audio stream. And the capture device specified for camilladsp-setrate must be the same specified as catpure device for camilladsp. Therefore you must check that such a device is available. To do so, please read the section "Requirements" in the home page of camilladsp-setrate.
If I have understood correctly, your streamer is the same machine where camilladsp runs. Then, to use the loopback device, you must instruct your streamer to playback to 'hw:Looback,0', i.e. the playback side of the loopback device. Then you must specify 'hw:Loopback,1' (i.e. the capture side of the loopback device) as the capture device for both camilladsp and camilladsp-setrate. NOTE: please do not expect camilladsp-setrate to update the samplerate for camilladsp when it changes because the Loopback device does not allow this.
(It goes without saying that you must have previously installed a alsa loopback device. see https://github.com/TheSalarKhan/Linux-Audio-Loopback-Device/tree/master)
I recommend you learn at least the basics of the alsa sound system.
First of all, I recommend you to do as suggested by @phofman and report your findings using text and not screenshots. It is easy, why not?
camilladsp-setrate requires the specification of a capture device providing the sample rate of the current audio stream. And the capture device specified for camilladsp-setrate must be the same specified as catpure device for camilladsp. Therefore you must check that such a device is available. To do so, please read the section "Requirements" in the home page of camilladsp-setrate.
If I have understood correctly, your streamer is the same machine where camilladsp runs. Then, to use the loopback device, you must instruct your streamer to playback to 'hw:Looback,0', i.e. the playback side of the loopback device. Then you must specify 'hw:Loopback,1' (i.e. the capture side of the loopback device) as the capture device for both camilladsp and camilladsp-setrate. NOTE: please do not expect camilladsp-setrate to update the samplerate for camilladsp when it changes because the Loopback device does not allow this.
(It goes without saying that you must have previously installed a alsa loopback device. see https://github.com/TheSalarKhan/Linux-Audio-Loopback-Device/tree/master)
I recommend you learn at least the basics of the alsa sound system.
Last edited:
I did read everything thoroughly multiple times. But they are not entirely specific.camilladsp-setrate requires the specification of a capture device providing the sample rate of the current audio stream. And the capture device specified for camilladsp-setrate must be the same specified as catpure device for camilladsp. Therefore you must check that such a device is available. To do so, please read the section "Requirements" in the home page of camilladsp-setrate.
For example:
Will slave-rate do? This is a snipet I get of the output using amixer -D hw:Loopback controls:If the device driver sports the required alsa control, the above command should list a control whose name contains the word 'rate' (or something like that). In any case, please check the documentation of your device.
Code:
numid=5,iface=PCM,name='PCM Slave Rate'
My system is indeed configured the way you described it. Input to the Loopback is 0 and output 1 (I'm actually doing this opposite of what is specified by the mdsimon2 guide for other reasons). So I'm aware how ALSA works.I recommend you learn at least the basics of the alsa sound system.
It's good info that the input to setrate needs to be the same side that goes to CDSP. I would have thought that to be irrelevant as the sample rate should be the same on both sides of the loopback? So I just set it to what I figured would be the source.
Unfortunately, it yields no difference in result:
Code:
xxx@xxx:~ $ camilladsp-setrate --device "hw:Loopback,1"
ALSA lib conf.c:5516:(parse_args) Unknown parameter 1
ALSA lib conf.c:5687:(snd_config_expand) Parse arguments error: No such file or directory
ALSA lib control.c:1528:(snd_ctl_open_noupdate) Invalid CTL hw:Loopback,1
alsa_init START Fatal error: Cannot open alsa controls for the device hw:Loopback,1: No such file or directory
xxx@xxx:~ $ camilladsp-setrate --device hw:"Loopback,1"
ALSA lib conf.c:5516:(parse_args) Unknown parameter 1
ALSA lib conf.c:5687:(snd_config_expand) Parse arguments error: No such file or directory
ALSA lib control.c:1528:(snd_ctl_open_noupdate) Invalid CTL hw:Loopback,1
alsa_init START Fatal error: Cannot open alsa controls for the device hw:Loopback,1: No such file or directory
tor@kef:~ $
(Hope the text is readable, because the formatting looks terrible, which is why I resorted to screenshot. I will try to add a code tag to see if it will fix it).
At this point I'm pretty well versed in how the ALSA system works. My main issue is not yet having a full graps on Linux (beginner since 3 month of getting into CDSP and RPi). For example when you say to use Quotation marks, I'm not sure if hw should be included (which is why I tried both in the example above and previous examples. Thanks again for the help and understanding.
@xxAncientMarinerxx
Don't forget to replace the control name in the file setrate.h (the first "#define" line) and rebuild the executable.
It is impossible to provide detailed instructions for each device. Sorry. But actually camilladsp-setrate is intended for the usb gadget, for which I have provided an example.But they are not entirely specific.
Indeed, the device number does not have to be specified. I apologise for giving you incorrect information; as I have already said, I am not an expert on the alsa sound system, I only learnt just enough to develop the software.xxx@xxx:~ $ camilladsp-setrate --device "hw:Loopback,1"
There is a possibility of that control working like the ‘Capture Rate’ control of the USB gadget, but I have not done any tests on it.Will slave-rate do? This is a snipet I get of the output using amixer -D hw:Loopback controls:
numid=5,iface=PCM,name='PCM Slave Rate'
Don't forget to replace the control name in the file setrate.h (the first "#define" line) and rebuild the executable.
- Home
- Source & Line
- PC Based
- Sample rate switcher for CamillaDSP