Closed alex-vyverman closed 3 years ago
HEnquist
commented
3 years ago Does it work if you let only the capture or playback side use the RME card? Then use for example an Alsa loopback for the other one. Another thought, you aplay output mentions Pulse. Are you sure that Pulse isn't keeping the device open? That would give the same error.
alex-vyverman
commented
3 years ago Hi Henrik,
Thanks for replying.
Another thought, you aplay output mentions Pulse. Are you sure that Pulse isn't keeping the device open? That would give the same error.
I am suspecting Pulse to do nasty things. I am not planning on using Pulse for my system, but the precompiled Camilladsp needed a pulse lib, so I took the path of least resistance and installed Pulse anyway. Which could have been a bad idea. I have since uninstalled Pulse, but traces appear to have been left behind. I'm contemplating a reinstall of the system as a sanity check at this point. (dedicated to CamillaDSP)
Does it work if you let only the capture or playback side use the RME card? Then use for example an Alsa loopback for the other one.
Since I only have one card, do I use "null" as either input or output device to test this?
Some more info if deemed relevant.
Linux ubuntudsp 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:39:42 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
CamillaDSP 0.5.1
alex@ubuntudsp:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 122 model name : Intel(R) Pentium(R) Silver J5040 CPU @ 2.00GHz
alex@ubuntudsp:~$ cat /proc/asound/cards 0 [HDSPMx7423ee ]: HDSPM - RME AES32_7423ee RME AES32 S/N 0x7423ee at 0xa1200000, irq 22
alex-vyverman
commented
3 years ago Does it work if you let only the capture or playback side use the RME card? Then use for example an Alsa loopback for the other one.
If I insert "null" in either capture or playback, Camilla seems to start up. So using the capture side seems to be blocking the playback side and vice versa.
I am going to see if I'm smart enough at setting up the alsa loopback to test this :)
Part of the reason why I am using this card and setup is because I want to achieve Camilla processing at as low a latency as possible (when using IIR that is). So I am fearfull that loopback "hacks" will impact this goal if ever so slightly.
Many thanks for the help. Alex
HEnquist
commented
3 years ago Ok, then there is probably something strange with setting up the device twice (since capture and playback are the same device). Could you run camilladsp once in trace more (-vv) and copy everything it prints? It probably gets quite large so just attach it as a txt file.
alex-vyverman
commented
3 years ago Not very large, so here we go:
alex@ubuntudsp:~$ camilladsp -vv ./camilladsp/configs/test.yaml May 24 11:21:13.426 DEBG Read config file Some("./camilladsp/configs/test.yaml"), module: camilladsp May 24 11:21:13.426 DEBG Config is valid, module: camilladsp May 24 11:21:13.426 DEBG Wait for config, module: camilladsp May 24 11:21:13.426 DEBG Config ready, module: camilladsp May 24 11:21:13.426 DEBG Using channels [true, true], module: camilladsp May 24 11:21:13.426 DEBG Buffer frames 2048, module: camillalib::alsadevice May 24 11:21:13.426 DEBG Build new pipeline, module: camillalib::filters May 24 11:21:13.426 DEBG build filters, waiting to start processing loop, module: camillalib::processing May 24 11:21:13.427 ERRO Capture error: ALSA function 'snd_pcm_open' failed with error 'EBUSY: Device or resource busy', module: camilladsp May 24 11:21:13.427 DEBG Error while starting, release barrier, module: camilladsp May 24 11:21:13.427 DEBG Wait for playback thread to exit.., module: camilladsp May 24 11:21:13.428 ERRO Message channel error: receiving on a closed channel, module: camillalib::processing May 24 11:21:13.428 DEBG Restarting with new config, module: camilladsp May 24 11:21:13.428 DEBG Wait for config, module: camilladsp May 24 11:21:13.428 DEBG No config and not in wait mode, exiting!, module: camilladsp
Using this config:
devices: samplerate: 48000 chunksize: 1024 capture: type: Alsa channels: 2 device: "plughw:CARD=HDSPMx7423ee,DEV=0" format: S16LE playback: type: Alsa channels: 2 device: "plughw:CARD=HDSPMx7423ee,DEV=0" format: S16LE
mixers: stereo: channels: in: 2 out: 2 mapping:
- dest: 0 sources:
- channel: 0 gain: 0 inverted: false
- dest: 1 sources:
- channel: 1 gain: 0 inverted: false
pipeline:
- type: Mixer name: stereo
HEnquist
commented
3 years ago Hmm this was a different error, not the same Playback error: ALSA function 'snd_pcm_hw_params' failed with error 'EBUSY: Device or resource busy', module: camilladsp as above. This new error means the device is already in use by some other process.
HEnquist
commented
3 years ago I have tried reproducing this, but it doesn't happen with any of the devices I have. My first guess is that the capture and playback sides of the rme card aren't completely independent, and that it doesn't like when setting the parameters for both at the same time. Do you have rustc and cargo set up so you can compile camilladsp yourself? Then we can try some things.
HEnquist
commented
3 years ago Is this still an issue or did you get it working? Since I can't reproduce the problem, I can't do much without help.
HEnquist
commented
3 years ago Closing due to lack of activity. Feel free to reopen.
ghost
commented
2 years ago fwiw I'm having the same issue...
Configuration tested with CamillaDSP:
ALSA function 'snd_pcm_hw_params' failed with error 'EBUSY: Device or resource busy')Same issue with initializing the M4 as capture with arecord [M4...] | aplay [loopback...] and having alsa/loopback as capture in CamillaDSP and M4 as playback.
It indeed seems that the M4 doesn't "like" being initialized both as capture and playback. It's strange because people reported no such error before.
Attaching:
-vvvstrace -f ... | grep '\(SNDRV\|open\)'[btw thanks for your work - camilladsp really rocks!]
HEnquist
commented
2 years ago This is surprising, the M4 was reported as working fine with simultaneous capture and playback. There were some initial issues that were solved in 1.0.1. See the discussion here, and the following few pages: https://audiosciencereview.com/forum/index.php?threads/rpi4-camilladsp-tutorial.29656/post-1255615 What kernel version are you using? There were some changes to usb in 5.18 that seem to have made it more robust.
ghost
commented
2 years ago See the discussion here
Yes - I've read that thread and that's why I bought the M4 :)
What kernel version are you using?
Fedora 36's 5.19.yy on amd64, and 5.15.69 on aarch64
I just did a few more tests - results are all over the place:
On a recent PC (Ryzen 5500, ddr4 3200 ram, ...), kernel 5.19.11:
arecord -D "sysdefault:CARD=M4" -c 4 -r 96000 -f S32_LE | aplay -D "sysdefault:CARD=M4"
Recording WAVE 'stdin' : Signed 32 bit Little Endian, Rate 96000 Hz, Channels 4 Segmentation fault
the same command ran 1 second later (without any change):
ALSA lib pcm_direct.c:1332:(snd1_pcm_direct_initialize_slave) unable to install hw params ALSA lib pcm_dsnoop.c:577:(snd_pcm_dsnoop_open) unable to initialize slave arecord: main:867: audio open error: Device or resource busy aplay: read_header:2950: read error
and again; it's working after the 3rd try !
Recording WAVE 'stdin' : Signed 32 bit Little Endian, Rate 96000 Hz, Channels 4 Playing WAVE 'stdin' : Signed 32 bit Little Endian, Rate 96000 Hz, Channels 4
But on that machine CamillaDSP consistently fails (device busy).
Now, on a thinkpad x250 laptop - pretty underspec by today's standards - both arecord|aplay and CamillaDSP work without any issue (kernel 5.19.8 - it's not the last one but I'm on 4G data now, can't update it ; I doubt that's the issue though).
Except performance the only difference between the more powerful PC and the laptop is that the former had a "clean" fedora 36 install, while the laptop has seen a few version updates (eg. fedora 32 -> 33 -> 34 ...). It could be something with how pulseaudio/pipewire got updated but it rather looks like some timing/race issues as one machine is significantly faster than the other.
However the embedded board (rockpi-S / kernel 5.15.69 / aarch64) is way slower than the laptop and yet camilladsp always fails (device busy).
But... arecord|aplay works consistently there (I hadn't tried that yesterday):
arecord -D "sysdefault:CARD=M4" -c 4 -r 96000 -f S32_LE | aplay -D "sysdefault:CARD=M4"
Recording WAVE 'stdin' : Signed 32 bit Little Endian, Rate 96000 Hz, Channels 4 Playing WAVE 'stdin' : Signed 32 bit Little Endian, Rate 96000 Hz, Channels 4
However the following fails (device busy), and then any subsequent (previously working) arecord|aplay command as above then fails with "device busy"
arecord -D "sysdefault:CARD=M4" -c 4 -r 96000 -f S32_LE -d 1 > /tmpr
arecord -D "sysdefault:CARD=M4" -c 4 -r 96000 -f S32_LE -d 1 > /dev/null &
cat /tmp/r | aplay -D "sysdefault:CARD=M4" &Puzzling - it reminds me of working with MS Windows back in the day: black magic.
It could be that errors are unrelated - ie. that the problem with the embedded board is because of the older kernel, while the one with the recent kernel is an unfixed timing issue.
Does any of the above makes sense to you ?
I could try the following:
HEnquist
commented
2 years ago Something I just remembered.. Do these systems have PulseAudio or Pipewire installed? They often open devices even if they aren't using them at the moment which can cause these device busy errors.
ghost
commented
2 years ago Do these systems have PulseAudio or Pipewire installed?
The fedora machines do, the board doesn't (bare-bone distro / armbian). I doubt the issue is related to pipewire though since CamillaDSP works on the laptop but not on the recent PC.
It really seems like an issue with initialization timing...
I'm trying to compile a custom armbian kernel atm but it's taking forever downloading some stuff. I'll report back when (/if) I manage to boot with a newer kernel...
ghost
commented
2 years ago So - I managed to install a newer kernel (5.19.10) but the issue persists.
tl;dr; - don't bother, something's broken with usb audio, CamillaDSP probably only triggers the problem and isn't the issue.
To sum up:
Doesn't work: CamillaDSP with the M4 configured both as capture and playback devices: consistently fails with "device busy"
Works inconsistently: arecord|aplay pipeline from/to the M4: arecord -D "sysdefault:CARD=M4" -c 4 -r 96000 -f S32_LE | aplay -D "sysdefault:CARD=M4" (inconsistent because it sometimes triggers a kernel oops because of snd-usb-audio and/or segfaults). I tried to put CamillaDSP in the "middle" of the pipe with Stdin/Stdout devices but aplay then fails with "device busy".
Doesn't work: recording from the M4 to Loopback,0 and then playing from Loopback,1 to the M4 with either CamillaDSP or aplay. Eg. with arecord -D "sysdefault:CARD=M4" -f S32_LE -c 4 -r 96000 | aplay -D "hw:CARD=Loopback,DEV=0" running in parallel:
CamillaDSP consistently fails with:
Playback error: ALSA function 'snd_pcm_hw_params_set_rate' failed with error 'EINVAL: Invalid argument'
aplay consistently fails with:
aplay: set_params:1407: Unable to install hw params:
I'm done with this and will revisit that setup in a few months. (my main use for the M4 is as a streamer with 2.1 sub crossover - that part works ; however I wanted to be able to switch to analog input when playing from analog sources - that part doesn't work, at least on the hardware I use).
Have a nice day/evening !
HEnquist
commented
2 years ago ghost
commented
2 years ago Maybe something here is useful
Unfortunately not - I've recompiled the kernel with the patch mentioned in the kernel thread but no luck...
Thanks for the pointer though ! I'll do another test with the latest kernel in a few weeks and see if there's some improvement...
jeffreyameyer
commented
1 year ago Just encountered the same issue on a build & initial setup using Ubuntu 23.10
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=23.10
DISTRIB_CODENAME=mantic
DISTRIB_DESCRIPTION="Ubuntu 23.10"$ /home/user/camilladsp/camilladsp -g-40 -p 1234 /home/user/camilladsp/configs/ultralitemk5_streamer.yml -v
2023-11-11 21:52:16.533485 INFO [src/bin.rs:711] CamillaDSP version 1.0.3
2023-11-11 21:52:16.533726 INFO [src/bin.rs:712] Running on linux, aarch64
2023-11-11 21:52:16.534059 DEBUG [src/bin.rs:754] Read config file Some("/home/jeffme/camilladsp/configs/ultralitemk5_streamer.yml")
2023-11-11 21:52:16.566917 DEBUG [src/bin.rs:773] Config is valid
2023-11-11 21:52:16.567172 DEBUG [src/socketserver.rs:260] Start websocket server on 127.0.0.1:1234
2023-11-11 21:52:16.567788 DEBUG [src/bin.rs:857] Wait for config
2023-11-11 21:52:16.568016 DEBUG [src/bin.rs:890] Config ready
2023-11-11 21:52:16.569241 DEBUG [src/bin.rs:213] Using channels [true, true]
2023-11-11 21:52:16.570104 DEBUG [src/alsadevice.rs:917] Buffer frames 2048
2023-11-11 21:52:16.570133 DEBUG [src/filters.rs:450] Build new pipeline
2023-11-11 21:52:16.570467 DEBUG [src/filters.rs:355] Build from config
2023-11-11 21:52:16.570779 DEBUG [src/filters.rs:355] Build from config
2023-11-11 21:52:16.570994 DEBUG [src/filters.rs:355] Build from config
2023-11-11 21:52:16.571204 DEBUG [src/filters.rs:355] Build from config
2023-11-11 21:52:16.571432 DEBUG [src/filters.rs:355] Build from config
2023-11-11 21:52:16.571638 DEBUG [src/filters.rs:355] Build from config
2023-11-11 21:52:16.571846 DEBUG [src/filters.rs:355] Build from config
2023-11-11 21:52:16.571966 DEBUG [src/alsadevice.rs:932] Creating resampler
2023-11-11 21:52:16.572052 DEBUG [src/filters.rs:355] Build from config
2023-11-11 21:52:16.572266 DEBUG [src/filters.rs:355] Build from config
2023-11-11 21:52:16.572472 DEBUG [src/filters.rs:355] Build from config
2023-11-11 21:52:16.572684 DEBUG [src/filters.rs:355] Build from config
2023-11-11 21:52:16.572901 DEBUG [src/filters.rs:355] Build from config
2023-11-11 21:52:16.573108 DEBUG [src/filters.rs:355] Build from config
2023-11-11 21:52:16.573313 DEBUG [src/filters.rs:355] Build from config
2023-11-11 21:52:16.573460 DEBUG [src/filters.rs:355] Build from config
2023-11-11 21:52:16.573576 DEBUG [src/filters.rs:355] Build from config
2023-11-11 21:52:16.573693 DEBUG [src/filters.rs:355] Build from config
2023-11-11 21:52:16.573837 DEBUG [src/filters.rs:355] Build from config
2023-11-11 21:52:16.573965 DEBUG [src/processing.rs:19] build filters, waiting to start processing loop
ALSA lib confmisc.c:165:(snd_config_get_card) Cannot get card index for UltraLitemk5
2023-11-11 21:52:16.581338 ERROR [src/bin.rs:344] Playback error: ALSA function 'snd_pcm_open' failed with error 'ENODEV: No such device'
2023-11-11 21:52:16.581489 DEBUG [src/bin.rs:349] Error while starting, release barrier
2023-11-11 21:52:16.582280 DEBUG [src/alsadevice.rs:413] Capture: supported channels, min: 1, max: 32, list: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32]
2023-11-11 21:52:16.582421 DEBUG [src/alsadevice.rs:414] Capture: setting channels to 2
2023-11-11 21:52:16.582584 DEBUG [src/alsadevice.rs:418] Capture: supported samplerates: Range(8000, 192000)
2023-11-11 21:52:16.582711 DEBUG [src/alsadevice.rs:419] Capture: setting rate to 44100
2023-11-11 21:52:16.582852 DEBUG [src/alsadevice.rs:423] Capture: supported sample formats: [S16LE, S24LE, S24LE3, S32LE, FLOAT32LE]
2023-11-11 21:52:16.582976 DEBUG [src/alsadevice.rs:424] Capture: setting format to S32LE
2023-11-11 21:52:16.583396 DEBUG [src/alsadevice.rs:455] Opening audio device "hw:Loopback,0" with parameters: HwParams { channels: Ok(2), rate: "Ok(44100) Hz", format: Ok(S32LE), access: Ok(RWInterleaved), period_size: "Ok(512) frames", buffer_size: "Ok(4096) frames" }, SwParams(avail_min: Ok(2048) frames, start_threshold: Ok(0) frames, stop_threshold: Ok(4096) frames)
2023-11-11 21:52:16.583573 DEBUG [src/alsadevice.rs:460] Audio device "hw:Loopback,0" successfully opened
2023-11-11 21:52:16.583751 DEBUG [src/alsadevice.rs:958] Starting captureloop
2023-11-11 21:52:16.583790 DEBUG [src/bin.rs:352] Wait for capture thread to exit..
2023-11-11 21:52:16.583930 DEBUG [src/processing.rs:21] Processing loop starts now!
2023-11-11 21:52:16.584665 INFO [src/alsadevice.rs:592] Capture device supports rate adjust
2023-11-11 21:52:16.584815 DEBUG [src/alsadevice.rs:627] Exit message received, sending EndOfStream
2023-11-11 21:52:16.585048 INFO [src/processing.rs:37] Playback thread has already stopped.
2023-11-11 21:52:16.586504 DEBUG [src/bin.rs:915] Restarting with new config
2023-11-11 21:52:16.586662 DEBUG [src/bin.rs:857] Wait for config
2023-11-11 21:52:16.586805 DEBUG [src/bin.rs:860] No config and not in wait mode, exiting!@jeffreyameyer the error is "ENODEV: No such device", meaning that it wasn't able to find the playback device. Can you post the output of "aplay -l"?
Hi!
I am using an RME PCIe HDSPe AES audio card on Ubuntu (x86_64).
I've had excellent results with camilladsp on a different platform before, but I now need more I/O, so opted for this card.
From the commandline (Aplay, alsaloop, speakertest,...) it all works fine, but whatever I try with Camilladsp, I always get
Playback error: ALSA function 'snd_pcm_hw_params' failed with error 'EBUSY: Device or resource busy', module: camilladsphere is an example of my config:
And here the output of aplay -L
I've tried searching around, but couldn't find relevant info. Tried every possible combination of ALSA devices and formats in Camilla. but keep encountering the same issue. Any ideas?
Many thanks, Alex