Thank you, this helped to get some outputs:
Code:
airharder@raspberrypi:~ $ less /boot/firmware/config.txt
[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1
[all]
dtoverlay=dwc2
dtoverlay=hifiberry-dac8x
dtoverlay=hifiberry-dac8x
dtoverlay=dwc2
dtoverlay=dwc2
dtoverlay=dwc2
dtoverlay=dwc2
dtoverlay=dwc2
dtoverlay=dwc2
dtoverlay=dwc2
dtoverlay=dwc2
dtoverlay=dwc2
dtoverlay=dwc2
dtoverlay=dwc2Then the command less /etc/modules gives:
Code:
airharder@raspberrypi:~ $ less /etc/modules
g_audio
dwc2
g_audio
dwc2
g_audio
dwc2
g_audio
dwc2
g_audio
dwc2
g_audio
dwc2
g_audio
dwc2
g_audio
dwc2
g_audio
dwc2
g_audio
dwc2
g_audio
dwc2
g_audioThen the command less /etc/modprobe.d/usb_g_audio.conf gives this:
Code:
airharder@raspberrypi:~ $ less /etc/modprobe.d/usb_g_audio.conf
options g_audio c_srate=44100 c_ssize=4 c_chmask=3 p_chmask=0
options g_audio c_srate=44100,48000,88200,96000,192000 c_ssize=4 c_chmask=3 p_chmask=0
options g_audio c_srate=48000 c_ssize=4 c_chmask=3 p_chmask=0
options g_audio c_srate=44100,48000,88200,96000,192000 c_ssize=4 c_chmask=3 p_chmask=0
options g_audio c_srate=44100,48000,88200,96000 c_ssize=4 c_chmask=3 p_chmask=0
options g_audio c_srate=48000 c_ssize=4 c_chmask=3 p_chmask=0
options g_audio c_srate=44100,48000 c_ssize=4 c_chmask=3 p_chmask=0
options g_audio c_srate=44100, 48000 c_ssize=4 c_chmask=3 p_chmask=0
options g_audio c_srate=48000 c_ssize=4 c_chmask=3 p_chmask=0
options g_audio c_srate=48000 c_ssize=4 c_chmask=3 p_chmask=0
options g_audio c_srate=48000 c_ssize=4 c_chmask=3 p_chmask=0
options g_audio c_srate=44100 c_ssize=4 c_chmask=3 p_chmask=0Ok, now the above looks suspicious to me. Looks like I can see all the different parameters, that I've tried to get different sample rates to work.
What needs to be in here? I tend to delete everything but one line:
Code:
options g_audio c_srate=48000 c_ssize=4 c_chmask=3 p_chmask=0If this would work, then I should at least be back on a fixed 48000 Hz sample rate. Guess I'll give it a try - currently looks like too many conflicting code lines in there.
Anyone else (@Hendrik and/or @mevang) see anything that needs to be corrected in these files? Thank you all for your patience and help - I keep on learning a lot here 🙏.
To configure the USB Gadget I use the method described in post #239. I am not able to help you on the method you are currently using, sorry.
You were so right! The problem was very obvious! In /etc/modprobe.d/usb_g_audio.conf I had to delete all unnecessary and double code lines like I described above - I left only this:
Code:
options g_audio c_srate=48000 c_ssize=4 c_chmask=3 p_chmask=0
Code:
options g_audio c_srate=44100,48000,88200,96000,192000 c_ssize=4 c_chmask=3 p_chmask=0Maybe it never worked for me, as I only used these echo commands, that kept on adding conflicting command lines in usb_g_audio.conf?!
I'll have to figure out, how I can create an image of this working SD card with all the Raspberry OS and CamillaDSP stuff, so I always have a backup, when I mess something up 🙂
Thank you and no worries! I'm at least back to where I was before, after the fix I described in the above post. USB Gadget works again and for now I'm stuck again with the 48000 Hz sample rate. I might try to include the other sample rates
options g_audio c_srate=44100,48000,88200,96000,192000 c_ssize=4 c_chmask=3 p_chmask=0
now that I know how to enter and edit usb_g_audio.conf.
The easiest is probably to use a windows machine and an SD card reader, and use a tool such as https://sourceforge.net/projects/win32diskimager/
Hi @mevang, let's give the camilladsp-setrate another try. Here is quickly my status:
Capture device: hw:UAC2Gadget -> works
With this code line in /etc/modprobe.d/usb_g_audio.conf:
Code:
options g_audio c_srate=48000 c_ssize=4 c_chmask=3 p_chmask=0I get sound everything works well, but sample rate is stuck on 48000 Hz (to be expected).
When I change the code line in /etc/modprobe.d/usb_g_audio.conf to:
Code:
options g_audio c_srate=44100,48000,88200,96000,176400,192000 c_ssize=4 c_chmask=3 p_chmask=0
Code:
airharder@raspberrypi:~ $ /usr/local/bin/camilladsp-setrate --loglevel=notice
main INIT ================================================
main INIT camilladsp-setrate v2.2.1
main INIT An automatic sample rate switcher for CamillaDSP
main INIT ================================================
fsm_init INIT Finite-state machine initialised
LWS: 4.1.6-, loglevel 1031
NET CLI SRV H1 H2 WS IPV6-on
websocket_init START Websocket environment initialised
alsa_init START Alsa initialised for the device hw:UAC2Gadget
websocket_callback START Connected to websocket server at localhost:1234
fsm_transit START Event : CONNECT
fsm_transit START Action : NULL
fsm_transit START Next State: WAIT_RATE_CHANGE
alsa_callback WAIT_RATE_CHANGE BEGIN : Incoming Sample Rate = 96000 Hz
fsm_transit WAIT_RATE_CHANGE Event : RATE_CHANGE
fsm_transit WAIT_RATE_CHANGE Action : callback_on_writeable
fsm_transit WAIT_RATE_CHANGE Next State: RATE_CHANGED
fsm_transit RATE_CHANGED Event : WRITEABLE
fsm_transit RATE_CHANGED Action : send_get_config
fsm_transit RATE_CHANGED Next State: WAIT_CONFIG
fsm_transit WAIT_CONFIG Event : CONFIG_KO
fsm_transit WAIT_CONFIG Action : callback_on_writeable
fsm_transit WAIT_CONFIG Next State: CONFIG_RECEIVED_KO
fsm_transit CONFIG_RECEIVED_KO Event : WRITEABLE
fsm_transit CONFIG_RECEIVED_KO Action : send_get_previous_config
fsm_transit CONFIG_RECEIVED_KO Next State: WAIT_PREVIOUS_CONFIG
fsm_transit WAIT_PREVIOUS_CONFIG Event : CONFIG_OK
fsm_transit WAIT_PREVIOUS_CONFIG Action : callback_on_writeable
fsm_transit WAIT_PREVIOUS_CONFIG Next State: CONFIG_RECEIVED_OK
fsm_transit CONFIG_RECEIVED_OK Event : WRITEABLE
fsm_transit CONFIG_RECEIVED_OK Action : send_set_config
fsm_transit CONFIG_RECEIVED_OK Next State: WAIT_RESPONSE
fsm_transit WAIT_RESPONSE Event : RESPONSE_KO
fsm_transit WAIT_RESPONSE Action : notify_failure
fsm_transit WAIT_RESPONSE Next State: WAIT_RATE_CHANGE
notify_failure WAIT_RESPONSE END : Configuration update abort
alsa_callback WAIT_RATE_CHANGE BEGIN : Incoming Sample Rate = 44100 Hz
fsm_transit WAIT_RATE_CHANGE Event : RATE_CHANGE
fsm_transit WAIT_RATE_CHANGE Action : callback_on_writeable
fsm_transit WAIT_RATE_CHANGE Next State: RATE_CHANGED
fsm_transit RATE_CHANGED Event : WRITEABLE
fsm_transit RATE_CHANGED Action : send_get_config
fsm_transit RATE_CHANGED Next State: WAIT_CONFIG
fsm_transit WAIT_CONFIG Event : CONFIG_KO
fsm_transit WAIT_CONFIG Action : callback_on_writeable
fsm_transit WAIT_CONFIG Next State: CONFIG_RECEIVED_KO
fsm_transit CONFIG_RECEIVED_KO Event : WRITEABLE
fsm_transit CONFIG_RECEIVED_KO Action : send_get_previous_config
fsm_transit CONFIG_RECEIVED_KO Next State: WAIT_PREVIOUS_CONFIG
fsm_transit WAIT_PREVIOUS_CONFIG Event : CONFIG_OK
fsm_transit WAIT_PREVIOUS_CONFIG Action : callback_on_writeable
fsm_transit WAIT_PREVIOUS_CONFIG Next State: CONFIG_RECEIVED_OK
fsm_transit CONFIG_RECEIVED_OK Event : WRITEABLE
fsm_transit CONFIG_RECEIVED_OK Action : send_set_config
fsm_transit CONFIG_RECEIVED_OK Next State: WAIT_RESPONSE
fsm_transit WAIT_RESPONSE Event : RESPONSE_KO
fsm_transit WAIT_RESPONSE Action : notify_failure
fsm_transit WAIT_RESPONSE Next State: WAIT_RATE_CHANGE
notify_failure WAIT_RESPONSE END : Configuration update abort
Code:
2024-11-16 12:49:08.860073 INFO [src/bin.rs:683] CamillaDSP version 2.0.3
2024-11-16 12:49:08.860090 INFO [src/bin.rs:684] Running on linux, aarch64
2024-11-16 12:49:08.965186 ERROR [src/bin.rs:307] Capture error: ALSA function 'snd_pcm_hw_params_set_rate' failed with error 'EINVAL: Invalid argument'
2024-11-16 12:49:08.965251 ERROR [src/processing.rs:50] Message channel error: receiving on a closed channel
2024-11-16 12:50:02.760092 ERROR [src/bin.rs:307] Capture error: ALSA function 'snd_pcm_hw_params_set_rate' failed with error 'EINVAL: Invalid argument'
2024-11-16 12:50:02.775478 ERROR [src/processing.rs:50] Message channel error: receiving on a closed channel
2024-11-16 12:50:10.046778 ERROR [src/socketserver.rs:1126] Error validating config: target_level can't be larger than 8184
2024-11-16 12:50:10.110431 ERROR [src/socketserver.rs:1126] Error validating config: target_level can't be larger than 4096
2024-11-16 12:51:14.184393 ERROR [src/bin.rs:307] Capture error: ALSA function 'snd_pcm_hw_params_set_rate' failed with error 'EINVAL: Invalid argument'
2024-11-16 12:51:14.207695 ERROR [src/processing.rs:50] Message channel error: receiving on a closed channel
2024-11-16 12:52:05.668112 ERROR [src/bin.rs:307] Capture error: ALSA function 'snd_pcm_hw_params_set_rate' failed with error 'EINVAL: Invalid argument'
2024-11-16 12:52:05.691441 ERROR [src/processing.rs:50] Message channel error: receiving on a closed channel
2024-11-16 12:52:50.254036 ERROR [src/bin.rs:307] Capture error: ALSA function 'snd_pcm_hw_params_set_rate' failed with error 'EINVAL: Invalid argument'
2024-11-16 12:52:50.277656 ERROR [src/processing.rs:50] Message channel error: receiving on a closed channel
2024-11-16 12:58:43.811699 ERROR [src/socketserver.rs:1126] Error validating config: target_level can't be larger than 4096
2024-11-16 12:58:43.812092 ERROR [src/socketserver.rs:1126] Error validating config: target_level can't be larger than 4096
2024-11-16 12:58:43.875489 ERROR [src/socketserver.rs:1126] Error validating config: target_level can't be larger than 2048
2024-11-16 12:58:43.875886 ERROR [src/socketserver.rs:1126] Error validating config: target_level can't be larger than 2048I guess, this line might give the hint where the issue can be found: Capture error: ALSA function 'snd_pcm_hw_params_set_rate' failed with error 'EINVAL: Invalid argument'
Just one thing to know: I use 6channels of the HifiBerry DAC8X (2x Hi, Mid, Low) so I also tried to set c_chmask=63 for 6 channels in usb_g_audio.conf
Code:
options g_audio c_srate=44100,48000,88200,96000,176400,192000 c_ssize=4 c_chmask=63 p_chmask=0Else please see my device settings screenshot attached. I still get no sound. Any idea what I'm missing here?
Attachments
I have one more idea, where the issue might be located, that prevents camilladsp-setrate to work properly, but I would still need help:
In the tutorial: https://github.com/marcoevang/camilladsp-setrate
Point 5:
Here is the code line in my 85-DAC.rules file:
As stated above, I use 6channels of the HifiBerry DAC8X (for 2x Hi, Mid, Low).
Checking the result for the command
I get:
So, in line P I get:
P: Vendor=1d6b ProdID=0002
and also
P: Vendor=1d6b ProdID=0003
Vendor=1d6b, this is clear and I've included this.
But in my 85-DAC.rules file as stated above, I've only specified
ENV{ID_MODEL_ID}=="0002"
-> Now looking at this, there is a second Model_ID, I'm pretty certain I also have to specify the
ENV{ID_MODEL_ID}=="0003"
for using all 6 channels.
Can someone please help me with the correct syntax?
Is it something like
ENV{ID_MODEL_ID}=="0002","0003"
or
ENV{ID_MODEL_ID}=="0002,0003"
or do I need two entries like:
Looking at the outcome of the log files and messages from my previous post, I feel, this could be what I'm missing. What do you think?
I'd be happy about any hint to point me in the right direction 🙂.
In the tutorial: https://github.com/marcoevang/camilladsp-setrate
Point 5:
- Edit the file 85-DAC.rules and replace the values of the parameters ID_VENDOR_ID and ID_MODEL_ID with those of your USB DAC. You can obtain those values with the following command: usb-devices
(Vendor corresponds to ID_VENDOR_ID and ProdID corresponds to ID_MODEL_ID)
Here is the code line in my 85-DAC.rules file:
Code:
SUBSYSTEM=="usb", ACTION=="add", ENV{ID_VENDOR_ID}=="1d6b", ENV{ID_MODEL_ID}=="0002", RUN+="/usr/bin/pkill -f -SIGHUP camilladsp-setrate"As stated above, I use 6channels of the HifiBerry DAC8X (for 2x Hi, Mid, Low).
Checking the result for the command
Code:
usb-devicesI get:
Code:
airharder@raspberrypi:~ $ usb-devices
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev=06.06
S: Manufacturer=Linux 6.6.28+rpt-rpi-2712 xhci-hcd
S: Product=xHCI Host Controller
S: SerialNumber=xhci-hcd.0
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 1
D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1
P: Vendor=1d6b ProdID=0003 Rev=06.06
S: Manufacturer=Linux 6.6.28+rpt-rpi-2712 xhci-hcd
S: Product=xHCI Host Controller
S: SerialNumber=xhci-hcd.0
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev=06.06
S: Manufacturer=Linux 6.6.28+rpt-rpi-2712 xhci-hcd
S: Product=xHCI Host Controller
S: SerialNumber=xhci-hcd.1
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
T: Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 1
D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1
P: Vendor=1d6b ProdID=0003 Rev=06.06
S: Manufacturer=Linux 6.6.28+rpt-rpi-2712 xhci-hcd
S: Product=xHCI Host Controller
S: SerialNumber=xhci-hcd.1
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
T: Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev=06.06
S: Manufacturer=Linux 6.6.28+rpt-rpi-2712 dwc2_hsotg
S: Product=DWC OTG Controller
S: SerialNumber=1000480000.usb
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256msSo, in line P I get:
P: Vendor=1d6b ProdID=0002
and also
P: Vendor=1d6b ProdID=0003
Vendor=1d6b, this is clear and I've included this.
But in my 85-DAC.rules file as stated above, I've only specified
ENV{ID_MODEL_ID}=="0002"
-> Now looking at this, there is a second Model_ID, I'm pretty certain I also have to specify the
ENV{ID_MODEL_ID}=="0003"
for using all 6 channels.
Can someone please help me with the correct syntax?
Is it something like
ENV{ID_MODEL_ID}=="0002","0003"
or
ENV{ID_MODEL_ID}=="0002,0003"
or do I need two entries like:
Code:
SUBSYSTEM=="usb", ACTION=="add", ENV{ID_VENDOR_ID}=="1d6b", ENV{ID_MODEL_ID}=="0002", NV{ID_MODEL_ID}=="0003", RUN+="/usr/bin/pkill -f -SIGHUP camilladsp-setrate"Looking at the outcome of the log files and messages from my previous post, I feel, this could be what I'm missing. What do you think?
I'd be happy about any hint to point me in the right direction 🙂.
As already told, camilladsp is responding with an error message to the configuration update command sent by camilladsp-setrate.
The log file produced by camilladsp indicates that something in the configuration is wrong. Please run camilladsp-setrate with the
--timestampflag so we can correlate camilladsp-setrate and camilladsp log traces. More information is required to diagnose this problem. Please add the DEBUG option in setrate.h (see post #231).the file usb_g_audio.conf concerns the capture device and c_chmask sets the number of channels for the capture device according to the number of channels of your digital source. The HifiBerry DAC8X is your playback device.
The file 85-DAC.rules is meant for a secondary functionality of camilladsp-setrate and is not necessary for the automatic rate change. Once again, to simplifiy things, for the moment, remove that file.
A few final questions:
1) what is the size of your camilladsp configuration file?
2) What is the value set in the setrate.h file for the constant MAX_PAYLOAD_SIZE?
3) If camilladsp-setrate is not active, does your system consisting of digital source, capture device, camilladsp and Hifiberry DAC8X work with a fixed sampling frequency, e.g. 44100 Hz? If the answer is yes, let's go on with the debug. Otherwise, please fix the issues of your system first before attempting to make camilladsp-setrate work properly.
Last edited:
Just a post that may be helpful to others upgrading to CamillaDSP version 3.0. I have simplified my CamillaDSP configuration after upgrading to version 3.0, and camilladsp-setrate is working well for me, even better than before. Here is a screen shot of my Device tab:
Notably, previously I had Buffers --> chunksize set to 8192. I was experiencing an issue where the samplerate would adjust fine when samplerate increased, but not when it decreased. My CamillaDSP log file gave an error that 4096 is the maximum buffer chunksize. I changed it, and the problem went away.
Also, the format of the configuration file has changed. Importing the old configuration files only worked if there were no filters specified. Once I had the Devices tab and Mixer tab configured in the new configuration, I setup my first filter and saved that. Then I copied the rest of the filters from my old configuration document into my new configuration document. I then went back into the GUI and setup the Pipeline. That worked well for me. Of course, you can create your filters anew if you so choose.
The main difference that I see is the in how the "Pipeline" is configured in the new version. Once I had the Devices tab and Mixer tab configured in the new configuration, I copied the filters from my old configuration document into my new configuration document, then went back into the GUI and setup the Pipeline. That worked well for me.
Notably, previously I had Buffers --> chunksize set to 8192. I was experiencing an issue where the samplerate would adjust fine when samplerate increased, but not when it decreased. My CamillaDSP log file gave an error that 4096 is the maximum buffer chunksize. I changed it, and the problem went away.
Also, the format of the configuration file has changed. Importing the old configuration files only worked if there were no filters specified. Once I had the Devices tab and Mixer tab configured in the new configuration, I setup my first filter and saved that. Then I copied the rest of the filters from my old configuration document into my new configuration document. I then went back into the GUI and setup the Pipeline. That worked well for me. Of course, you can create your filters anew if you so choose.
The main difference that I see is the in how the "Pipeline" is configured in the new version. Once I had the Devices tab and Mixer tab configured in the new configuration, I copied the filters from my old configuration document into my new configuration document, then went back into the GUI and setup the Pipeline. That worked well for me.
Attachments
Last edited:
I am happy camilladsp-setrate works well for you with CDSP v3. Thank you for the tips about the configuration of CDSP.
I tried importing an old configuration file again, and this time it worked without having to create a new configuration. I followed these instructions: https://github.com/mdsimon2/RPi-CamillaDSP#converting-configurations-from-v2-to-v3
Yesterday I ran into issues, but those issues seem to be gone today. I must have done something wrong yesterday.
@TerryForsythe : does the default valu for rate adjust mean the rate adjust is enabled? It should be for the gadget to work properly with CDSP.
I assume it does because camilladsp-setrate is working without any issues.
Here is some history that may or may not be relevant:
I had camilladsp-setrate working with the previous version of CamillaDSP. At some point it stopped working properly, but neither CamillaDSP nor camilladsp-setrate had been updated recently. I surmized that it was due to a Linux update or an update to my streamer. I downgraded my WiiM to the previous firmware version I had been using when everything worked, but that did not fix it.
On Friday I upgraded CamillaDSP, and ran into some problems. Yesterday I did a clean install of everything. Using the settings shown in my screenshot, both CamillaDSP and camilladsp-setrate have been working flawlessly.
@TerryForsythe, in your setup CamillaDSP and your player run on distinct machines, each with their own clock. Those clocks are not perfectly synchronised. Thus the player produces data at a rate marginally different from the rate at which CamillaDSP processes it. Over time this likely causes buffer underrun or buffer overrun. Please monitor the "Buffer level' in CamillaGUI. If, for example, it is slowly decreasing, you may end up in a a buffer underrun. Setting 'enable_rate_adjust=yes', as suggested by @phofman, avoids this issue.
OK. Thank you!
I have been playing music for a few hours and the buffer level was around 6600. I just set "enable_rate_adjust=yes" and the buffer level is hovering around 2000. I'll keep an eye on it.
EDIT: Have "enable_rate_adjust" set to "yes", and the buffer level is back up over 6000.
I have been playing music for a few hours and the buffer level was around 6600. I just set "enable_rate_adjust=yes" and the buffer level is hovering around 2000. I'll keep an eye on it.
EDIT: Have "enable_rate_adjust" set to "yes", and the buffer level is back up over 6000.
Last edited:
Rate adjust is disabled unless specifically enabled in the config file https://github.com/HEnquist/camilla...7e436de888c24c17182b63d051/src/config.rs#L640 . Also the rate adjust is closely related to option target_level which specifies, how large a buffer fill the rate adjust will try to maintain.
It's always good to look at CDSP logs when setting up the project - you should see this info-level entry https://github.com/HEnquist/camilla...6de888c24c17182b63d051/src/alsadevice.rs#L792
As of the complaint about maximum chunksize - the gadget alsa device has maximum buffer size of 16 * pagesize 4kB = 64kB https://github.com/torvalds/linux/b...b55/drivers/usb/gadget/function/u_audio.c#L26 . That corresponds to 8k samples at 32bit/2ch. Since CDSP requires at least two chunks per buffer, 4k per chunk is maximum.
My camilladsp.log does indeed indicate "Capture devices supports rate adjust". Also, my journal log entries after I changed the chunksize to 4096 look clean.
Nonetheless, I updated my Devices configuration based on the above comments. Now it is as follows. Please let me know if you have any further suggestions:
EDIT: After setting "enable_rate_adjust" to "yes" my camilladsp.log gives the following warning: Needless 1:1 sample rate conversion active. Not needed since capture device supports rate adjust
Nonetheless, I updated my Devices configuration based on the above comments. Now it is as follows. Please let me know if you have any further suggestions:
EDIT: After setting "enable_rate_adjust" to "yes" my camilladsp.log gives the following warning: Needless 1:1 sample rate conversion active. Not needed since capture device supports rate adjust
Last edited:
The fact that the capture device supports rate adjust allows you to do without resampling, which would otherwise have been necessary. In any case, if your player and camilladsp have distinct clocks, the rate adjust option must be enabled.
If you can afford larger latency, I would recommend raising the target level to 3/4 of the buffer size for timing safety. Right now your timing safety is around 30ms (3k of 96k).