marcosch@raspcamilla:~$ sudo amixer -c G6 cset numid=20 'External Mic'
[sudo] password for marcosch:
numid=20,iface=MIXER,name='PCM Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=4
; Item #0 'Line In'
; Item #1 'External Mic'
; Item #2 'S/PDIF In'
; Item #3 'What U Hear'
: values=0
but again, in direct mode it is possible to select spdif in. But that doesnt help to get camilladsp working
marcosch@raspcamilla:~$ uname -r
5.13.0-1017-raspi
marcosch@raspcamilla:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 21.10
Release: 21.10
Codename: impish
Thanks for the answer, I did not have rate adjust enabled. I enabled it and that seems to have done the trick.
here's a startup script for camilladsp that might be handy for people wanting to use it with pulseaudio:
Code:
#!/bin/sh
pactl set-card-profile alsa_card.usb-ASUSTeK_ASUS_XONAR_U5-00 off
pactl list sinks|grep camilladsp >/dev/null || \
pactl load-module module-alsa-sink device="hw:Loopback,1,1" \
sink_name=camilladsp sink_properties="device.description='CamillaDSP-Input'"
pactl set-default-sink camilladsp
killall camilladsp >/dev/null 2>&1; sleep 1 && \
chrt -f 90 camilladsp -l trace -p 1234 /path/to/camilladsp.yamlExplanations:
- You have to replace "alsa_card.usb-ASUSTeK_ASUS_XONAR_U5-00" with the actual card that you want camilladsp to output to. This command tells pulseaudio that it should not use the card, so there is no conflict with camilladsp that wants to write to it. You can find your card's device string with "pactl list cards".
- If you don't need/want camilladsp running with realtime scheduling priorities remove the "chrt -f 90 "
- Replace "/path/to/camilladsp.yaml" with the actual path to your config file
- The script assumes camilladsp binary to be in your path. If that's not the case replace it with a complete path to your camilladsp binary
Code:
devices:
samplerate: 192000
chunksize: 8192
queuelimit: 1
capture_samplerate: 192000
enable_rate_adjust: true
silence_threshold: -65
silence_timeout: 10
capture:
channels: 2
type: Alsa
device: "hw:Loopback,0,1"
format: FLOAT32LE
playback:
type: ALSA
channels: 6
device: "hw:U5,0"
format: S24LE3Explanations:
- You need to replace "capture_samplerate: 192000" with the samplerate pulseaudio runs at (determined by /etc/pulse/daemon.conf (search for the line with default-sample-rate)
- Replace "hw:U5,0" with the your alsa card's device name where camilladsp should output to
Code:
high-priority = yes
nice-level = -15
flat-volumes = no
remixing-consume-lfe = yes
remixing-produce-lfe = no
avoid-resampling = false
resample-method = soxr-vhq
default-sample-format = float32le
default-sample-rate = 192000Explanations:
- Lines 1 and 2 are not needed, if you don't want to run pulseaudio with realtime scheduling privileges. They don't hurt either, if the user has no rights to gain RT scheduling privileghes.
- "resample-method = soxr-vhq" might not be available on your distro, in this case pulseaudio will not start with that line, replace it with for example "resample-method = speex-float-10"
- "avoid-resampling = false" is needed, because we define a fixed capture sample rate in camilladsp's config file and we need to prevent pulseaudio from using it's alternate sample rate.
- "default-sample-format = float32le" must also match camilladsp's capture sample format!
@HenrikEnquist : If you want me to update the existing documentation feel free to tell me!
Last edited:
Gave updating the kernel a try for raspi os bullseye 64 bit. New at this so just followed the instructions in the raspberry pi documentation pages for building the kernel.
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 5.15.26-v8+ #1 SMP PREEMPT Sun Mar 6 12:39:57 EST 2022 aarch64 GNU/Linux
The errors I reported in previous post would occur seemingly randomly when resuming play after camilladsp was in pause status. I could normally trigger the error within a few minutes of repeatedly pausing then resuming play. I have been trying to recreate the issue for 30 or so minutes and have not had the error with kernel 5.15 ! So far it looks like the error does not occur with the kernel 5.15.
With kernel 5.15, I did notice the occasional very low buffer level when resuming play. The lowest I saw was 15% of the target buffer of 4096, chunksize is 4096, sample rate is 96k, I dont remember seeing this before upgrading to this new kernel.
I added a lot more logging, and maybe some improvements for the strange timeouts.
It's here: https://github.com/HEnquist/camilladsp/tree/alsatest
@Tfive and @ChrisPatlach can you give it a try? With some luck it works better. If not, then it should log some useful stuff on trace level.
It's here: https://github.com/HEnquist/camilladsp/tree/alsatest
@Tfive and @ChrisPatlach can you give it a try? With some luck it works better. If not, then it should log some useful stuff on trace level.
Compiled and running in the background on my NUC with trace log enabled. Will see if camilladsp process survives the night...
Unfortunately the camilladsp process already died on my NUC. here's the log: https://t-5.eu/nextcloud/index.php/s/2ZjJBtp7qCnWZRX
Thanks for the logs!
For Tfive it crashed because it failed to read from the capture device. It alls looked good until it called readi(), which failed with a broken pipe error.
For ChrisPatlach there was a playback error, exactly the one the small fix was intended to help for. The playback device reports that it's buffer is full (avail=0), then waiting for it to drain times out. Then it tries to write anyway, which fails with an EAGAIN error, meaning the write should be retried. But doing that just seems to give EAGAIN over and over.
Neither case makes much sense. What systems and kernels did you run on?
Maybe phofman has some ideas?
For Tfive it crashed because it failed to read from the capture device. It alls looked good until it called readi(), which failed with a broken pipe error.
For ChrisPatlach there was a playback error, exactly the one the small fix was intended to help for. The playback device reports that it's buffer is full (avail=0), then waiting for it to drain times out. Then it tries to write anyway, which fails with an EAGAIN error, meaning the write should be retried. But doing that just seems to give EAGAIN over and over.
Neither case makes much sense. What systems and kernels did you run on?
Maybe phofman has some ideas?
For ChrisPatlach's case: perhaps accompanying the CDSP trace with tzshark USB capture dump from the same time with system timestamps https://stackoverflow.com/a/52151161/15717902 + dmesg dump. This looks more like a problem on the USB -> XMOS side.
For Tfive: I do not know what could cause the aloop device stall. Typically the capture side does not stall when playback side stops delivering samples. This looks more like timing in CDSP, IMO. Timing in CDSP is of crucial importance and we are looking at options for advancing the timing debug.
For Tfive: I do not know what could cause the aloop device stall. Typically the capture side does not stall when playback side stops delivering samples. This looks more like timing in CDSP, IMO. Timing in CDSP is of crucial importance and we are looking at options for advancing the timing debug.
I am running the latest release of Raspberry Pi OS 64 bit bullseye Desktop on a raspberrypi 4b. It has kernel 5.10.
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 5.10.92-v8+ #1514 SMP PREEMPT Mon Jan 17 17:39:38 GMT 2022 aarch64 GNU/Linux
On the positive side, with your fix, I did not see this error anymore:
Playback error: ALSA function 'snd_pcm_prepare' failed with error 'EBUSY: Device or resource busy'
Also, still have not had any errors by building and using kernel 5.15.
I am willing to try but no promises, my experience and abilities maybe a bit limited for this. Will see if I can figure it out .
This is a very interesting point. IIRC Tfive is also running 5.10. Seems a bit like there is something odd in that kernel version.
I'm running 5.13.0-30-lowlatency. Also tried 5.14 oem kernel, no difference. I will compile a fresh 5.15 or 5.16 today evening when I come home and try that. Btw. The errors are VERY sporadic, on the NUC they occured twice within 10min and then it is playing music since yesterday evening nonstop. Even survived the "critical time" around 4pm when lots of backups are rolling in to this machine's raid array. Yes I use my HTPC as a NAS
No need to fight with it if your current setup finally works OK
So far I have installed tshark, ran sudo modprobe usbmon. tshark -D command listed usbmon0,1,2. usbmon1 and 2 seemed to be outputing when music was playing. For both, does not look like the right thing though, just seems to be the same lines over and over, this is usbmon2 with command:
sudo tshark -i 9 -t a > usb_dump.txt
54835 10:01:21.518882 1.3.1 → host USB 160 URB_ISOCHRONOUS out
54836 10:01:21.518891 host → 1.3.1 USB 2864 URB_ISOCHRONOUS out
54837 10:01:21.519515 1.3.1 → host USB 84 URB_ISOCHRONOUS in
54838 10:01:21.519520 host → 1.3.1 USB 80 URB_ISOCHRONOUS in
54839 10:01:21.519756 1.3.1 → host USB 176 URB_ISOCHRONOUS out
54840 10:01:21.519767 host → 1.3.1 USB 2864 URB_ISOCHRONOUS out
54841 10:01:21.520513 1.3.1 → host USB 160 URB_ISOCHRONOUS out
54842 10:01:21.520522 host → 1.3.1 USB 2464 URB_ISOCHRONOUS out
54843 10:01:21.520534 1.3.1 → host USB 84 URB_ISOCHRONOUS in
54844 10:01:21.520538 host → 1.3.1 USB 80 URB_ISOCHRONOUS in
54845 10:01:21.521387 1.3.1 → host USB 176 URB_ISOCHRONOUS out
the DAC8PRO is on Bus 001: Device 003 so assume that corresponds to the 1.3.1
Anyhow happy to try a few more things if it could contribute to the project or help someone out but I could use a few tips on how to get the proper usb capture. If its not worth the effort, no problem I seem to be doing fine with kernel 5.15.
Playing with the GUI, Volume, and Loudness filters tonight I have a few observations.
1) The --mute or -m command line option doesn't seem to do anything. At least not in 0.6.2 and 1.0.0-rc2. It gets parsed as listing it twice gives an error but it doesn't actually mute the sound regardless of whether or not a gain argument is also present.
2) The GUI doesn't reflect live volume if it it set outside the GUI. Seems like something that should be monitored along with the level meters.
3) The GUI only shows integer volumes and only has a slider range from -100 to 0. Apparently float values and positive values are acceptable. I understand limiting the slider to 0 so people don't do bad and loud things, but maybe the float value should be listed.
1) The --mute or -m command line option doesn't seem to do anything. At least not in 0.6.2 and 1.0.0-rc2. It gets parsed as listing it twice gives an error but it doesn't actually mute the sound regardless of whether or not a gain argument is also present.
2) The GUI doesn't reflect live volume if it it set outside the GUI. Seems like something that should be monitored along with the level meters.
3) The GUI only shows integer volumes and only has a slider range from -100 to 0. Apparently float values and positive values are acceptable. I understand limiting the slider to 0 so people don't do bad and loud things, but maybe the float value should be listed.
I pushed a new update the alsa_cdsp plugin. It now has the option to be given a file to read for gain and mute values and pass them along to camilladsp when it starts the process. This could allow gain and mute to be maintained across restarts of camilladsp which the plugin does on any hw param change and for most players anytime audio is started or stopped.
To be effective some means of updating the file must exist. I tossed together a really ugly python program to poll the websocket for the values and update the file if they change. As I'm typing this I'm thinking instead I should add another command option to the plugin so it can call a program to query camilladsp for the values and update the file right before the plugin kills the process. A good enhancement for another day.
To be effective some means of updating the file must exist. I tossed together a really ugly python program to poll the websocket for the values and update the file if they change. As I'm typing this I'm thinking instead I should add another command option to the plugin so it can call a program to query camilladsp for the values and update the file right before the plugin kills the process. A good enhancement for another day.