I guess splitting the channels up on individual devices like that makes sense in some cases. Unfortunately it's really inconvenient for apps like camilladsp that only supports outputting to a single device. If you manage to combine them back into a single device using something like jack then it should be ok, there should not be any drift.I hit a roadblock; the Motu drivers created multiple audio devices one per two output channels. So for the total 10 output channels I have 5 devices. How would I configure these in the CamillaDSP playback section?
... An option would be connecting your card to RPi4 with linux/camillaDSP/USB audio+network gadget configuration, running the DSP on the RPi and presenting the combo to windows as a composite X-channel USB audio + network device for configuration ...
Well, the Jack / Jack2 was yet another rabbit hole The only documentation I could find regarding aggregating devices was this: https://jackaudio.org/faq/multiple_devices.html. And the only part potentially applicable to Windows (Use the JACK2 audio adapter) states "More information is needed on this option". Even the windows installer failed (had to manually register JackRouter.dll) so it is evident that this software is not focused on Windows and it mainly intended for pro av experts.Henris: Splitting the multiple channels to separate stereo devices is done by the Motu driver, IMO. In linux the device reports as a single multichannel device https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-6759897
Unfortunately the stock MS UAC2 driver will not handle your card correctly as it uses implicit feedback which the driver does not support.
An option would be connecting your card to RPi4 with linux/camillaDSP/USB audio+network gadget configuration, running the DSP on the RPi and presenting the combo to windows as a composite X-channel USB audio + network device for configuration. This option will be available, eventually.
022-01-02 21:06:39.303870 DEBUG [src/alsadevice.rs:402] Playback: supported channels, min: 22, max: 22, list:  2022-01-02 21:06:39.303883 DEBUG [src/alsadevice.rs:403] Playback: setting channels to 22 2022-01-02 21:06:39.303890 DEBUG [src/alsadevice.rs:407] Playback: supported samplerates: Discrete() 2022-01-02 21:06:39.303896 DEBUG [src/alsadevice.rs:408] Playback: setting rate to 96000 2022-01-02 21:06:39.303918 DEBUG [src/alsadevice.rs:402] 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] 2022-01-02 21:06:39.303928 DEBUG [src/alsadevice.rs:403] Capture: setting channels to 2 2022-01-02 21:06:39.303937 DEBUG [src/alsadevice.rs:407] Capture: supported samplerates: Range(8000, 192000) 2022-01-02 21:06:39.303941 DEBUG [src/alsadevice.rs:408] Capture: setting rate to 96000 2022-01-02 21:06:39.303947 DEBUG [src/alsadevice.rs:412] Capture: supported sample formats: [S16LE, S24LE, S24LE3, S32LE, FLOAT32LE] 2022-01-02 21:06:39.303950 DEBUG [src/alsadevice.rs:413] Capture: setting format to S32LE 2022-01-02 21:06:39.304018 ERROR [src/bin.rs:344] Playback error: ALSA function 'snd_pcm_hw_params_set_rate' failed with error 'EINVAL: Invalid argument'
It will take a while for the patches to settle down, there are still some unresolved issues being discussed with other gadget developers now to make the technology practically usable. The gadget is running well on my RPi4 but having patches accepted upstream takes more than just their proper function. The added features must satisfy use cases of other kernel developers, a concensus must be reached and responses are not always immediate (if any)Perhaps a new thread would be good? There one could read a how-to for a common part and then we could have specifics per USB sound card... in the end this thread could describe a number of different configurations if owners of different boards could chime in and test/get help to succeed...
For HTPC I would be a bit cautious about the latency introduced by the buffers capture -> camilladsp -> playback, configured for a reliable operation. But hopefully the latency could be more or less constant, allowing its compensation by delaying video in the player/AVR.I want to achieve Source -> AVR -> Preouts -> NUC PC with CamillaDSP -> PowerAmps.
# Combining FIR filters with CamillaDSP capture: channels: 1 format: FLOAT64LE type: File # Target PS Correction FIR - # matching 256K Tap FLOAT64LE FIR filename: /path_to/PS_FIR.pcm playback: channels: 1 format: FLOAT64LE type: File filename: /path_to/MERGED_PSXO_FIR.pcm filters: XO_FIR: type: Conv parameters: filename: /path_to/XO_FIR.wav # matching 256K Tap FLOAT64LE FIR type: Wav channel: 0 pipeline: - type: Filter channel: 0 names: - XO_FIR
This is just how convolution works. Mathematically it's equivalent to convolve a signal first with one IR and then another, as to first convolve the two IRs and then convolve the signal with that result.I have been trying a couple of ways to "merge" a correction FIR with an XO FIR to generate a single merged FIR filter. The 2 ways that I have tried produces an output FIR twice the length of the individual input FIRs.