FWIW, I installed the VST plugin to JRMC, measured without ( baseline = red bottom plot ) and with each of the 8 preset configurations.
From the measurements, they add 2nd order harmonic distortion in varying amounts up to an additional 25dB depending on the profile selected as seen in the plot below.
They also play with the EQ profiles, volume and slightly shift phase by up to 60 degrees.
Last edited:
Ok! At some point I want to add dynamic filters, which would take care of the EQ:ing at high volume. But things like tube emulation is not something I want to add.
That's what I guessed, but of course there could be more than simply L+R etc inside those boxes on the diagram.
You can use mixers for doing this kind of thing. Here is a simple example:
Code:
filters:
lowpass:
type: Biquad
parameters:
type: Lowpass
q: 0.5
freq: 1000
highpass:
type: Biquad
parameters:
type: Highpass
q: 0.5
freq: 1000
mixers:
to_sumdiff:
channels:
in: 2
out: 2
mapping:
- dest: 0
sources:
- channel: 0
gain: 0
inverted: false
- channel: 1
gain: 0
inverted: false
- dest: 1
sources:
- channel: 0
gain: 0
inverted: false
- channel: 1
gain: 0
inverted: true
to_leftright:
channels:
in: 2
out: 2
mapping:
- dest: 0
sources:
- channel: 0
gain: -6.0206
inverted: false
- channel: 1
gain: -6.0206
inverted: false
- dest: 1
sources:
- channel: 0
gain: -6.0206
inverted: false
- channel: 1
gain: -6.0206
inverted: true
pipeline:
- type: Mixer
name: to_sumdiff
- type: Filter
channel: 0
names:
- lowpass
- type: Filter
channel: 1
names:
- highpass
- type: Mixer
name: to_leftrightNote that you can never do exactly what you are asking, because there isn's enough information.
If we consider each channel as a sum of a common signal C, and a signal unique to that channel, X_u:
Code:
R = C + R_u
L = C + L_uThe processing in those blocks is a decoding from left and right into Mid and Side signals which are then equalized and gain changed separately in order to offset the effects of the darkening of the phantom centre image when early reflections in the listening room have been reduced. Then re-encoded to left and right before playback. It is very effective in that role, I use it myself and use metaplugin to enable the different routing needed which Jriver cannot easily do on it's own.
Is anyone getting 24/96 out of recent raspberry pi builds?
Hi all,
This is not exactly a camilladsp issue, but I'm having a devil of a time trying to get 24 bit audio out of my pi through HDMI. Older hacked kernels seem to have hard-coded audio parameters, which could be re-coded to something useful like max_bits = 32 or something. Now, it seems that the hw_params are read from the HDMI device itself, but I cannot get mine to read 24 bits.
returns
Is anyone else using the rpi getting 24 bits out (specifically over HDMI)?
Hi all,
This is not exactly a camilladsp issue, but I'm having a devil of a time trying to get 24 bit audio out of my pi through HDMI. Older hacked kernels seem to have hard-coded audio parameters, which could be re-coded to something useful like max_bits = 32 or something. Now, it seems that the hw_params are read from the HDMI device itself, but I cannot get mine to read 24 bits.
Code:
aplay -D hw:b1 --dump-hw-params 256kMeasSweep_20_to_20000_96k_PCM24_LR_refR.wavreturns
Code:
Playing WAVE '256kMeasSweep_20_to_20000_96k_PCM24_LR_refR.wav' : Signed 24 bit Little Endian in 3bytes, Rate 96000 Hz, Stereo
HW Params of device "hw:b2":
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: U8 S16_LE
SUBFORMAT: STD
SAMPLE_BITS: [8 16]
FRAME_BITS: [8 128]
CHANNELS: [1 8]
RATE: [8000 192000]
PERIOD_TIME: [10000 16384000]
PERIOD_SIZE: [80 131072]
PERIOD_BYTES: [1024 524288]
PERIODS: [1 128]
BUFFER_TIME: (416 16384000]
BUFFER_SIZE: [80 131072]
BUFFER_BYTES: [1024 131072]
TICK_TIME: ALL
--------------------
aplay: set_params:1339: Sample format non available
Available formats:
- U8
- S16_LEIs anyone else using the rpi getting 24 bits out (specifically over HDMI)?
I do not think the 24bit support was ever included in the official RPi kernel linux/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c at rpi-5.10.y * raspberrypi/linux * GitHub
Let me know if you ever want to add dynamic filters. I think I could help out. I'm actually planning on forking my own version of EqualizerAPO to implement a custom modded dynamic EQ for my liking. Doing it in Rust could be fun!
Thanks much.
I have tried this with JRMC's toolkit of functions, but could never get it to work. Their subtraction is an invert and sum which just ends up cancelling things out, leaves things inverted, or restores things back. Can cancel the common, but not derive just the common. I was hoping the CamillaDSP library had some extra functions.
BTW, I have 6 channels up and running and will have 8 soon as I make up some more cables.
May I ask the collective brain trust here a question regarding multi channel USB cards. And also stability. I have windows machines. And a simple understanding of LINUX. If I was going to setup a multichannel system using USB soundcards what would you guys recommend? Windows is easier. But I am not certain that it is as stable as LINUX. I am developing A CBT that takes a minimum of 10 channels per side. More if you incorporate low frequency channels.
Sorry to throw in such a question amongst such good info on the software.
Sorry to throw in such a question amongst such good info on the software.
MOTU has a range of USB interfaces that have 12 up to 24 analogue outputs already included. There are other types from RME etc. that have ADAT inputs and outputs that can be used with convertor hardware to extend the analogue I/O. Otherwise there is AVB and Dante ethernet based for very high channel counts but still need convertor add-ons.
They will all work with Windows but Linux compatibility is not assured. If the device is USB class compliant it will work without a driver but I don't know how many of these types of interfaces are truly class compliant.
They will all work with Windows but Linux compatibility is not assured. If the device is USB class compliant it will work without a driver but I don't know how many of these types of interfaces are truly class compliant.
AFIK you should keep your hands off of MOTU devices if linux compatibility is desired, but not 100% sure. I have heard good things abour recent RME devices regarding compatibility. I can tell however from personal experience that all the Focusrite devices are 100% USB/UAC compliant and there's even a half decent mixer software with GUI for them.
It's a very relevant question. It's quite easy to get up to 8 channels, but above that it starts to get tricky.
I think I should add a list of tested interfaces with more than 2 channels in the readme. Could I get some recommendations? I need the model, number of channels, tested operating system, and any problems/limitations found.
Hi guys, a question for the brains trust if I may?
there is a streamer project over on ASR that is likely looking to include MoOde and as a result Camilla DSP as an option on rpi 4 (possibly compute module on the IO board, or even custom PCB)
I've been unable to find a definitive answer in my searches about how much bandwidth and how many i2s channels are supported over GPIO. I have seen 4 channels mentioned, I have seen old devices claiming 8 channels @ 48kHz on rpi3 (but apparently that solution was buggy and would forget the channel assignments after restart sometimes), I have seen 10Mb and 15Mb.
I realise it's doable via USB, but it would be preferable if it were possible over GPIO. the lack of any multi-channel i2s drivers for any device being available in Moode is a worrying telltale sign. is it better to wrap in SPI, or perhaps interleaved TDM on GPIO? any help and clarification would be much appreciated. thanks in advance
there is a streamer project over on ASR that is likely looking to include MoOde and as a result Camilla DSP as an option on rpi 4 (possibly compute module on the IO board, or even custom PCB)
I've been unable to find a definitive answer in my searches about how much bandwidth and how many i2s channels are supported over GPIO. I have seen 4 channels mentioned, I have seen old devices claiming 8 channels @ 48kHz on rpi3 (but apparently that solution was buggy and would forget the channel assignments after restart sometimes), I have seen 10Mb and 15Mb.
I realise it's doable via USB, but it would be preferable if it were possible over GPIO. the lack of any multi-channel i2s drivers for any device being available in Moode is a worrying telltale sign. is it better to wrap in SPI, or perhaps interleaved TDM on GPIO? any help and clarification would be much appreciated. thanks in advance
I do not see how the 2ch I2S on RPi could transfer more than 2 channels, without any custom-programmed FPGA.
GPIO is not I2S, the SoC has a dedicated I2S peripheral with proper DMA, output buffer clocked by an external pin (slave mode), etc. I do not think I2S could be simulated by RPi's GPIOs, especially for higher bitrates, the timing is pretty strict. It needs a dedicated HW (or pre-programmed logic array). Maybe even the programmable GPIO circuit of the new RPi 2040 could handle it, but unlikely that many channels.
IMO no need to be constrained to RPi for such a specific requirement, the rock64 boards offer 8ch I2S out of the box. I have no experience with them though but have not seen any negative complaints yet.
GPIO is not I2S, the SoC has a dedicated I2S peripheral with proper DMA, output buffer clocked by an external pin (slave mode), etc. I do not think I2S could be simulated by RPi's GPIOs, especially for higher bitrates, the timing is pretty strict. It needs a dedicated HW (or pre-programmed logic array). Maybe even the programmable GPIO circuit of the new RPi 2040 could handle it, but unlikely that many channels.
IMO no need to be constrained to RPi for such a specific requirement, the rock64 boards offer 8ch I2S out of the box. I have no experience with them though but have not seen any negative complaints yet.
I recognise RME from the Nearfield scanner recommendation. And also remember MOTU being panned. Thanks for your reply.
True USB compliance is the rub. Especially when you are getting into many channels. I do not truly know the require bitrate as the channels increase but I am relatively sure in stating it increases by a factor of two for each channel addition. It's bitrate multiplied by sampling frequency if I am remembering correctly.
Secondary question. Is how much horsepower is actually needed to do the calculations on basically 24 channels? will a NUC or a simple industrial point of sale type of I3 or I5 box suffice?
Can you post a link to that Linux/Focusrite software? I have a 8i6 and some things function in Linux, but it is missing the "control app" to configure it which I thought was only available in Windows according to their docs. Forcusrite states they are USB2 compliant, but document that they offer no support for Linux.
I have an OKTO Research DAC8 Pro. I have tested 6 simultaneous channels (in PureUSB mode) so far in Linux with CamillaDSP using XMOS flash version 1.43. There are some issues with some of their Linux flashes (some don't work at all and there are some reported pops/clicks when switching between 44.1 and 48kHz variants). The DAC8 Pro is also limited to a max of 192kHz (note: ExaSound e38 supports rates to 8 x 384kHz).
It depends on the complexity of your filters, resamplers, # taps, # channels, sample rates and other software running on your PC. I have an IvyBridge i7/8-channel DAC combo and plan to upgrade the PC.
USB2 might be a stretch for 24 channels at higher sample rates.
Last edited:
Here it is: GitHub - x42/scarlett-mixer: Quickly hacked scarlett-mixer GUI for Linux/ALSA
Actually all the focusrite cards I had connected up to now all expose their mixer controls via ALSA. But you might get quite overwhelmed when alsamixer shows ~360 controls like for a scarlett 18i20
I started on a list of devices: camilladsp/tested_devices.md at develop * HEnquist/camilladsp * GitHub
Some more? What Focusrite interfaces have been tested for example? Anything working with paxor should be fine.
Some more? What Focusrite interfaces have been tested for example? Anything working with paxor should be fine.