Thanks for the «Wasabi backend with support for exclusive mode»
That is perfect for USB and old Windows Atom Pads.
Wondering if CamillaDSP will support CUDA at one time?
Remember the avangard forum user KOON3876
nVidia CUDA GPU computing PC FIR
Now CUDA have rust support ?
At least Pyton support Accelerated Signal Processing with cuSignal | NVIDIA Developer Blog and the price is getting low for a Nvidia Jetson Nano Developer Kit
That is perfect for USB and old Windows Atom Pads.
Wondering if CamillaDSP will support CUDA at one time?
Remember the avangard forum user KOON3876
nVidia CUDA GPU computing PC FIR
Now CUDA have rust support ?
At least Pyton support Accelerated Signal Processing with cuSignal | NVIDIA Developer Blog and the price is getting low for a Nvidia Jetson Nano Developer Kit
This is brilliant! I'll add a link in the camilladsp readme. Could you open a dedicated thread about it? I'm afraid it won't get the attention it deserves here, on page 216 out of (today) 217...
Get is nice and short, let's go with that!
I just realized that this tooltip isn't always true, it will always claim to save to a default file even when the backend is configured not to. This needs some rework. Just deleting the "and save to"-part is one option. But I think it makes sense to let the user know if the default config will be updated. Right now the GUI doesn't know if the backend is going to update the default config or not.
Of course I don't try to make it hard to use on purposedon't go by the "if it was hard to implement, it should be hard to use"
But it's not easy to figure out what parts can be safely hidden. It's a work in progress, and feedback is much appreciated!
I'm not very interested in CUDA since it's completely tied to Nvidia hardware. But there really isn't much need, any half-decent cpu has enough processing power to do quite long fir filters at high sample rates.
What filter lengths and sample rates do you have in mind?
... Of course I don't try to make it hard to use on purpose
And I know that of course! ;-)
//
New version v0.6.1
Release v0.6.1 * HEnquist/camilladsp * GitHub
## 0.6.1
New features:
- Add lists of supported device types in help message
Bugfixes:
- Fix broken Wasapi shared mode
- Correct "built with features" list in help.
- Correct list of supported device types.
Release v0.6.1 * HEnquist/camilladsp * GitHub
## 0.6.1
New features:
- Add lists of supported device types in help message
Bugfixes:
- Fix broken Wasapi shared mode
- Correct "built with features" list in help.
- Correct list of supported device types.
Henrik,
Just posted the thread. I kept the main post relatively short since all of the information is on GitHub already:
I2S-Hat: A Raspberry Pi Hat for SPDIF <-> I2S Communication and DSP
Problem with pycamilladsp 0.6.0
I upgraded my Pi 4 camilladsp implementation to the latest versions of camalladsp (0.6.1), pycamilladsp (0.6.0) and pycamilladsp-plot (0.6.0).
The DSP functionality is fine but the camillagui is having an issue with the added Enum functionality in pycamilladsp and I am encountering the following trace:
This prevents camillagui from displaying the current status of the DSP.
It seems python JSON doesn't know how to deal with serializing Enums out of the box.
As a quick and dirty work-around I changed the class to ProcessingState(str, Enum) and modified the values to use strings. This works as I don't think you are relying on values being ordinal (yeah, I know it's bad to assume).
I think the same issue will come up with the StopReason Enum class as well. But this isn't causing an issue for me, at this point.
I upgraded my Pi 4 camilladsp implementation to the latest versions of camalladsp (0.6.1), pycamilladsp (0.6.0) and pycamilladsp-plot (0.6.0).
The DSP functionality is fine but the camillagui is having an issue with the added Enum functionality in pycamilladsp and I am encountering the following trace:
Code:
Error handling request
Traceback (most recent call last):
File "/usr/local/lib/python3.7/dist-packages/aiohttp/web_protocol.py", line 422, in _handle_request
resp = await self._request_handler(request)
File "/usr/local/lib/python3.7/dist-packages/aiohttp/web_app.py", line 499, in _handle
resp = await handler(request)
File "/opt/camillagui/backend/views.py", line 57, in get_status
return web.json_response(status)
File "/usr/local/lib/python3.7/dist-packages/aiohttp/web_response.py", line 773, in json_response
text = dumps(data)
File "/usr/lib/python3.7/json/__init__.py", line 231, in dumps
return _default_encoder.encode(obj)
File "/usr/lib/python3.7/json/encoder.py", line 199, in encode
chunks = self.iterencode(o, _one_shot=True)
File "/usr/lib/python3.7/json/encoder.py", line 257, in iterencode
return _iterencode(o, 0)
File "/usr/lib/python3.7/json/encoder.py", line 179, in default
raise TypeError(f'Object of type {o.__class__.__name__} '
TypeError: Object of type ProcessingState is not JSON serializableIt seems python JSON doesn't know how to deal with serializing Enums out of the box.
As a quick and dirty work-around I changed the class to ProcessingState(str, Enum) and modified the values to use strings. This works as I don't think you are relying on values being ordinal (yeah, I know it's bad to assume).
I think the same issue will come up with the StopReason Enum class as well. But this isn't causing an issue for me, at this point.
ERRO Playback error: ALSA function 'snd_pcm_hw_params_set_rate' failed ...
Can you help me spot the rookie error error in this? I know I'll feel really stupid when you point it out!
Here's my debug log:
Here's my basic config file:
And here's what
tells me:
Thanks!
Can you help me spot the rookie error error in this? I know I'll feel really stupid when you point it out!
Here's my debug log:
ubuntu@ubuntu:/usr/local/etc/camilladsp$ camilladsp --loglevel debug /usr/local/etc/camilladsp/config.yml
Aug 20 15:15:47.298 DEBG Read config file Some("/usr/local/etc/camilladsp/config.yml"), module: camilladsp
Aug 20 15:15:47.300 DEBG Config is valid, module: camilladsp
Aug 20 15:15:47.300 DEBG Wait for config, module: camilladsp
Aug 20 15:15:47.301 DEBG Config ready, module: camilladsp
Aug 20 15:15:47.301 DEBG Using channels [true, true], module: camilladsp
Aug 20 15:15:47.302 DEBG Buffer frames 2048, module: camillalib::alsadevice
Aug 20 15:15:47.302 DEBG Build new pipeline, module: camillalib::filters
Aug 20 15:15:47.303 DEBG build filters, waiting to start processing loop, module: camillalib:
Aug 20 15:15:47.307 ERRO Playback error: ALSA function 'snd_pcm_hw_params_set_rate' failed with error 'EINVAL: Invalid argument', module: camilladsp
Aug 20 15:15:47.308 DEBG Error while starting, release barrier, module: camilladsp
Aug 20 15:15:47.309 DEBG Opening audio device "hw:CARD=Loopback,DEV=1" with parameters: HwParams { channels: Ok(2), rate: "Ok(44100) Hz", format: Ok(S16LE), access: Ok(RWInterleaved), period_size: "Ok(512) frames", buffer_size: "Ok(4096) frames" }, SwParams(avail_min: Ok(512) frames, start_threshold: Ok(0) frames, stop_threshold: Ok(4096) frames), module: camillalib::alsadevice
Aug 20 15:15:47.310 DEBG Audio device "hw:CARD=Loopback,DEV=1" successfully opened, module: camillalib::alsadevice
Aug 20 15:15:47.310 DEBG Starting captureloop, module: camillalib::alsadevice
Aug 20 15:15:47.311 DEBG Wait for capture thread to exit.., module: camilladsp
Aug 20 15:15:47.311 DEBG Processing loop starts now!, module: camillalib:
Aug 20 15:15:47.312 INFO Capture device supports rate adjust, module: camillalib::alsadevice
Aug 20 15:15:47.312 DEBG Exit message received, sending EndOfStream, module: camillalib::alsadevice
Aug 20 15:15:47.313 INFO Playback thread has already stopped., module: camillalib:
Aug 20 15:15:47.313 DEBG Restarting with new config, module: camilladsp
Aug 20 15:15:47.314 DEBG Wait for config, module: camilladsp
Aug 20 15:15:47.315 DEBG No config and not in wait mode, exiting!, module: camilladsp
Here's my basic config file:
Code:
ubuntu@ubuntu:/usr/local/etc/camilladsp$ cat config.yml
devices:
samplerate: 44100
chunksize: 1024
enable_resampling: false
capture:
type: Alsa
channels: 2
device: "hw:CARD=Loopback,DEV=1"
format: S16LE
playback:
type: Alsa
channels: 10
device: "hw:CARD=UltraLitemk5,DEV=0"
format: S24LE3
mixers:
to10chan:
channels:
in: 2
out: 10
mapping:
- dest: 0
sources:
- channel: 0
gain: 0
inverted: false
- dest: 1
sources:
- channel: 1
gain: 0
inverted: false
pipeline:
- type: Mixer
name: to10chanAnd here's what
Code:
aplay -v -D hw:UltraLitemk5 /dev/zero --dump-hw-paramsThanks!
Fellow Ultralite Mk5 CamilaDSP user here. I think your issue is the number of channels you have specified for your Mk5, you need to specify the exact number of output channels that the Mk5 presents.
I run at 96 kHz so for me that is 18 channels. I believe at 44.1 kHz it is 20, run cat /proc/asound/Ultralitemk5/stream 0 to confirm.
Michael
I run at 96 kHz so for me that is 18 channels. I believe at 44.1 kHz it is 20, run cat /proc/asound/Ultralitemk5/stream 0 to confirm.
Michael
That's very likely. If you look at the relevant source code camilladsp/alsadevice.rs at master * HEnquist/camilladsp * GitHub - first number of channels is set (that goes OK), then rate is set. While the soundcard supports the requested rate 44100Hz, the selected channels count restricted the samplerates set and the 44.1kHz is not available anymore - hence the error.
Hey Michael, Thanks for the pointer. The number at 44.1kHz is 22 according to this output (without the space before the 0):
So that clears the error on starting up:
Aug 20 16:43:00.727 DEBG Read config file Some("/usr/local/etc/camilladsp/config.yml"), module: camilladsp
Aug 20 16:43:00.728 DEBG Config is valid, module: camilladsp
Aug 20 16:43:00.728 DEBG Wait for config, module: camilladsp
Aug 20 16:43:00.729 DEBG Config ready, module: camilladsp
Aug 20 16:43:00.729 DEBG Using channels [true, true], module: camilladsp
Aug 20 16:43:00.730 DEBG Buffer frames 2048, module: camillalib::alsadevice
Aug 20 16:43:00.730 DEBG Build new pipeline, module: camillalib::filters
Aug 20 16:43:00.731 DEBG build filters, waiting to start processing loop, module: camillalib:
Aug 20 16:43:00.735 DEBG Opening audio device "hw:CARD=Loopback,DEV=1" with parameters: HwParams { channels: Ok(2), rate: "Ok(44100) Hz", format: Ok(S16LE), access: Ok(RWInterleaved), period_size: "Ok(512) frames", buffer_size: "Ok(4096) frames" }, SwParams(avail_min: Ok(512) frames, start_threshold: Ok(0) frames, stop_threshold: Ok(4096) frames), module: camillalib::alsadevice
Aug 20 16:43:00.736 DEBG Audio device "hw:CARD=Loopback,DEV=1" successfully opened, module: camillalib::alsadevice
Aug 20 16:43:00.736 DEBG Capture thread ready to start, module: camilladsp
Aug 20 16:43:00.739 DEBG Opening audio device "hw:CARD=UltraLitemk5,DEV=0" with parameters: HwParams { channels: Ok(22), rate: "Ok(44100) Hz", format: Ok(S243LE), access: Ok(RWInterleaved), period_size: "Ok(256) frames", buffer_size: "Ok(2048) frames" }, SwParams(avail_min: Ok(256) frames, start_threshold: Ok(768) frames, stop_threshold: Ok(2048) frames), module: camillalib::alsadevice
Aug 20 16:43:00.740 DEBG Audio device "hw:CARD=UltraLitemk5,DEV=0" successfully opened, module: camillalib::alsadevice
Aug 20 16:43:00.741 DEBG Playback thread ready to start, module: camilladsp
Aug 20 16:43:00.742 DEBG Both capture and playback ready, release barrier, module: camilladsp
Aug 20 16:43:00.742 DEBG Supervisor loop starts now!, module: camilladsp
Aug 20 16:43:00.743 DEBG Starting playback loop, module: camillalib::alsadevice
Aug 20 16:43:00.744 DEBG Starting captureloop, module: camillalib::alsadevice
Aug 20 16:43:00.744 INFO Capture device supports rate adjust, module: camillalib::alsadevice
Aug 20 16:43:00.745 DEBG Starting capture, module: camillalib::alsadevice
Aug 20 16:43:00.746 DEBG Processing loop starts now!, module: camillalib:
Aug 20 16:43:00.777 INFO Starting playback from Prepared state, module: camillalib::alsadevice
But I'm still getting nothing out when I stream from Roon, and the debug logs just look like this (rather quiet!):
I've tried both Loopback devices listed in Roon, but still nothing. Any thoughts?
I do not remember exactly but I do think I had to run the Cuemix software (on PC or Mac) to map the computer USB channels to the appropriate line out channels (computer USB 1-2 -> line out 1-2, computer USB 3-4 -> line out 3-4, etc). Although I thought channels 1-2 come mapped like that out of the box and it was just the other ones that needed mapping.
Michael
Michael
Thanks Michael. That's a good point. I've already done that prior to running tests using Windows 10 and Big Sur, so I'm confident the UltraLite itself is properly configured and can work (and when it does it sounds great!). But clearly I've still something to iron out before I make first base with the Pi/Linux/Camilladsp arrangement. Any other suggestions welcome.
John
John
I imagine it might be an issue on your playback (Roon) side. I took your config (changing channels from 10 to 22) and tried it with squeezelite as player and it worked perfectly for me.
I assume you have clock source set to internal?
What OS / kernel? I am on Ubuntu Server 21.04 64 bit, 5.11.0-1016-raspi.
I assume you have Roon set to resample everything to 44.1 kHz to match your CamillaDSP config?
Michael
I assume you have clock source set to internal?
What OS / kernel? I am on Ubuntu Server 21.04 64 bit, 5.11.0-1016-raspi.
I assume you have Roon set to resample everything to 44.1 kHz to match your CamillaDSP config?
Michael
Last edited:
I guess you're right Mike, but I can't spot it yet. Maybe fresh eyes tomorrow (I'm in the UK) will spot it straight away.
Yes, clock on the UL5 is set to internal. And my OS/kernel is identical to yours too.
Two other questions:
- is there a simple way to put sudo modprobe snd-aloop in a setup file somewhere so it happens every time on booting?
- <Control>C to close camilladsp is the way to stop it I guess - but it takes some 2-3 minutes to close down. Am I doing it right, and is this delay expected?
Thanks again.
Yes, clock on the UL5 is set to internal. And my OS/kernel is identical to yours too.
Two other questions:
- is there a simple way to put sudo modprobe snd-aloop in a setup file somewhere so it happens every time on booting?
- <Control>C to close camilladsp is the way to stop it I guess - but it takes some 2-3 minutes to close down. Am I doing it right, and is this delay expected?
Thanks again.
Add a file called snd-aloop.conf to /etc/modules-load.d/ that contains:
snd-aloop
That should create the loopback on startup.
I currently run camilladsp as a service so I stop it using "sudo service camilladsp stop" which does take a few seconds but when I was running it from the command line it ctrl-c would stop it instantly.
If you can't get it to work with the loopback you might try using the Mk5 as a capture device and routing the SPDIF or TOSLINK input to the output (that is how I currently use mine).
Michael
snd-aloop
That should create the loopback on startup.
I currently run camilladsp as a service so I stop it using "sudo service camilladsp stop" which does take a few seconds but when I was running it from the command line it ctrl-c would stop it instantly.
If you can't get it to work with the loopback you might try using the Mk5 as a capture device and routing the SPDIF or TOSLINK input to the output (that is how I currently use mine).
Michael