This really isn't easy to answer. The convolution runs in a single thread, so to get maximum performance you want fast cores. A 4-core i5 will be much better than an 8-core Atom for example. An Intel i3, i5 or i7 is a good choice since they have AVX. All AMD Ryzen cpus also have AVX. Pentiums and Celerons don't. The upcoming SSE support in RustFFT will make the difference much smaller, but AVX still wins.
The main thing that increases cpu load is sample rate. Doubling the sample rate increases the cpu load by a factor 4. As long as you don't try very long filters at very high sample rate, you should have no trouble with 24 channels.
Thanks! The 2i2 is stereo only, right? I don't think it makes sense to list stereo devices, there are just too many of them.
The ExaSound looks nice, until you realize that it requires proprietary drivers and has no linux support. How long will they support it? No thanks!
Regarding the X-Fi 5.1 in the list - a local guy and me are trying to troubleshoot a similar device - X-Fi SB USB stereo. In Windows the card gets switched to USB2 highspeed (480M) and its full capacity is available. In linux the card stays at fulspeed 12M, advertising only its USB1.1 profile which offers only slow samplerates. When rebooting from windows to linux without removing/resetting the card, it stays at 480Mbps, advertises its USB2 profile and 96/24 duplex is available in linux. If anyone has X-Fi 5.1, is interested in linux support, and is willing to experiment a bit, please let me know. We would need USB packets dump from wireshark in windows and in linux, on the same hardware. The actual packet capture is not complicated. Thanks.
I am trying to run the camilladsp on RPi4 and AV receiver. Good news is the HDMI channels mapping is correct and there is no need of vcgencmd hdmi_channel_map .. as for RPi3. Also HDMI offers 8 channels and up to 192kHz sample rate.
I copied configuration from desktop to raspbian 64 bit, changed output to S16LE, but have problems with capture. What does it mean?
Apr 14 15:03:15.452 TRCE Not enough frames available: 0, need: 4116, waiting..., module: camillalib::alsadevice
full log: camilladsp rpi4 - Pastebin.com
config: camilladsp rpi4 config - Pastebin.com
CamillaDSP 0.5.0-beta5 AArch64 from Releases.
I copied configuration from desktop to raspbian 64 bit, changed output to S16LE, but have problems with capture. What does it mean?
Apr 14 15:03:15.452 TRCE Not enough frames available: 0, need: 4116, waiting..., module: camillalib::alsadevice
full log: camilladsp rpi4 - Pastebin.com
config: camilladsp rpi4 config - Pastebin.com
CamillaDSP 0.5.0-beta5 AArch64 from Releases.
Those bastards! They accepted our pull request for that change _forever_ ago. I'd just assumed it was there
Rebuilt the kernel and now I'm good to go again
Thanks for pointing it out!
I think the limit on buffer length in ALSA is pretty low unless you update the kernel. I was getting similar messages in Jack before updating my kernel
ok maybe i'm just a little slow, but i'm trying to figure out how to have a filter on the two _input_ channels before applying filters on the mixed channels. What I'd like to do is apply a biquad on channels 0 & 1 -> split the channels into 6 -> apply FIR filters to each of those 6 channels -> output
Does that make sense? Is it doable?
Does that make sense? Is it doable?
It is updated system.
I can see something gets to the alsa loop
cat /proc/asound/card0/pcm0p/sub0/*
and when is Camilla running (before it stops), it also reads something, but I do not know if it is ok or not.
cat /proc/asound/card0/pcm0c/sub0/*
Code:
Linux dsp 5.10.17-v8+ #1403 SMP PREEMPT Mon Feb 22 11:37:54 GMT 2021 aarch64 GNU/LinuxI can see something gets to the alsa loop
cat /proc/asound/card0/pcm0p/sub0/*
Code:
access: RW_INTERLEAVED
format: FLOAT_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 2205
buffer_size: 11025
card: 0
device: 0
subdevice: 0
stream: PLAYBACK
id: Loopback PCM
name: Loopback PCM
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 8
subdevices_avail: 7
state: RUNNING
owner_pid : 941
trigger_time: 99.722746642
tstamp : 0.000000000
delay : 11025
avail : 0
avail_max : 3540
-----
hw_ptr : 763271
appl_ptr : 774296
tstamp_mode: NONE
period_step: 1
avail_min: 2205
start_threshold: 1
stop_threshold: 11025
silence_threshold: 0
silence_size: 0
boundary: 6206523236469964800and when is Camilla running (before it stops), it also reads something, but I do not know if it is ok or not.
cat /proc/asound/card0/pcm0c/sub0/*
Code:
access: RW_INTERLEAVED
format: FLOAT_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 2048
buffer_size: 16384
card: 0
device: 0
subdevice: 0
stream: CAPTURE
id: Loopback PCM
name: Loopback PCM
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 8
subdevices_avail: 7
state: RUNNING
owner_pid : 1006
trigger_time: 199.740792763
tstamp : 0.000000000
delay : 1620
avail : 1620
avail_max : 4952
-----
hw_ptr : 79824
appl_ptr : 78204
tstamp_mode: NONE
period_step: 1
avail_min: 2048
start_threshold: 0
stop_threshold: 16384
silence_threshold: 0
silence_size: 0
boundary: 4611686018427387904This message is normal and not an error, it just means that when camilladsp wants to read from the device, there aren't enough samples available yet. The old version started reading anyway, and then the read command blocks until there are enough samples. This caused trouble with some quirky devices, so the new version waits a little to make sure there are enough samples before reading.
I think the problem might be that the pi4 can't keep up.
You are doing resampling, and then convolution of 6 channels with 16k taps at 192 kHz. Can you check the cpu load with "top" when running? If it doesn't run long enough for that, try disabling some filters to ease the load.
Yes, this is no problem. Just add Filter steps in the pipeline, before the Mixer.
Ok, seems like a pretty safe bet that the X-Fi 5.1 is the same. Then the limitation is just in Linux, and not Windows. I'll update the list.
I changed to 44,1kHz and made video VID_20210414_200400.mp4 | on-line video | Ulož.to
tail of syslog and htop. Temperature on video is wrong, it is not CPU, but GPU. But it is 60C according to cat /sys/class/thermal/thermal_zone0/temp
Both raspbian 32 and 64bit behave the same.
Config:
devices:
capture:
channels: 2
device: "hw:Loopback,1"
format: FLOAT32LE
type: Alsa
capture_samplerate: 44100
chunksize: 16834
enable_rate_adjust: true
enable_resampling: true
playback:
channels: 8
device: hw:1,0
format: S16LE
type: Alsa
resampler_type: Synchronous
samplerate: 44100
...
Ok, with this lower load it should not have any trouble. Could you try the same configs with the previous beta?
"RME Digiface USB 8 (*1) no OK Digital output only. 1) 8 channels in AES/spdif mode, up to 34 in ADAT mode"
Analog out: 8 .... Digital output only.
Seems problematic
What does *1 indicate?
And "1) 8" ..
Digiface has one analog out and that is for Headphone. It does 8in ans 8out s/pdif (there is a coax version and a toslink version). One can configure these to adat making for 8 channels instead of 2 per socket.
Windows is supported.
//
Well I got everything working, including the web server. I have to say, that's very cool.
I have a couple of issues/questions, though.
I'm using my 2nd gen Scarlett 18i20 as an input for a turntable and trying to do RIAA correction digitally (because why not )
The issue i'm having is that the coefficients in the MiniDSP excel sheet https://www.minidsp.com/images/fbfiles/files/All_digital_coefs_v1-20101026.zip are giving errors in Camilladsp - that the biquad isn't stable.
Any idea why that might be the case? I swapped the a's and b's around and that seems to work.
The second issue is that the filter viz makes it hard to know if those filters are working correctly, because the bit we care most about 20hz - 20khz seems a bit squashed
Not the end of the world but a little hard to work with if you're using the web interface.
Final issue is that I'm getting a bunch of errors/warnings in camillagui that it's having trouble with a parameter and that's causing some issue
I'm wondering if this is because camillagui is not in the same directory as camilladsp?
Anyhoo, great work, this is a really thorough DSP implementation that can do all this neat stuff on a raspberry pi!
I have a couple of issues/questions, though.
I'm using my 2nd gen Scarlett 18i20 as an input for a turntable and trying to do RIAA correction digitally (because why not
) The issue i'm having is that the coefficients in the MiniDSP excel sheet https://www.minidsp.com/images/fbfiles/files/All_digital_coefs_v1-20101026.zip are giving errors in Camilladsp - that the biquad isn't stable.
Any idea why that might be the case? I swapped the a's and b's around and that seems to work.
Code:
from mini dsp
a0 1
a1 1.732765500000000
a2 -0.734553443600000
b0 1.000000000000000
b1 -0.755552100000000
b2 -0.164625711300000
this works, but is it _right_?
a0 1
b1 1.732765500000000
b2 -0.734553443600000
b0 1.000000000000000
a1 -0.755552100000000
a2 -0.164625711300000The second issue is that the filter viz makes it hard to know if those filters are working correctly, because the bit we care most about 20hz - 20khz seems a bit squashed
Not the end of the world but a little hard to work with if you're using the web interface.
Final issue is that I'm getting a bunch of errors/warnings in camillagui that it's having trouble with a parameter and that's causing some issue
Code:
Running
capturesignalrms
Error handling request
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/aiohttp/web_protocol.py", line 406, in start
resp = await task
File "/usr/lib/python3/dist-packages/aiohttp/web_app.py", line 435, in _handle
resp = await handler(request)
File "/home/pi/downloads/camillagui/views.py", line 68, in get_list_param
result = cdsp.get_capture_signal_rms()
File "/home/pi/.local/lib/python3.7/site-packages/camilladsp/camilladsp.py", line 159, in get_capture_signal_rms
sigrms = self._query("GetCaptureSignalRms")
File "/home/pi/.local/lib/python3.7/site-packages/camilladsp/camilladsp.py", line 62, in _query
return self._handle_reply(command, rawrepl)
File "/home/pi/.local/lib/python3.7/site-packages/camilladsp/camilladsp.py", line 82, in _handle_reply
raise IOError("Invalid response received: {}".format(rawreply))
OSError: Invalid response received: {"Invalid":{"error":"unknown variant `GetCaptureSignalRms`, expected one of `SetConfigName`, `SetConfig`, `SetConfigJson`, `Reload`, `GetConfig`, `ReadConfig`, `ReadConfigFile`, `ValidateConfig`, `GetConfigJson`, `GetConfigName`, `GetSignalRange`, `GetCaptureRate`, `GetUpdateInterval`, `SetUpdateInterval`, `GetVersion`, `GetState`, `GetRateAdjust`, `GetClippedSamples`, `GetBufferLevel`, `Exit`, `Stop`, `None` at line 1 column 21"}}
playbacksignalrmsI'm wondering if this is because camillagui is not in the same directory as camilladsp?
Anyhoo, great work, this is a really thorough DSP implementation that can do all this neat stuff on a raspberry pi!
