@HenrikEnquist , mind taking a look at the compressor-related section of my config file (attached here as a txt file)? This is for my JBL 708i speakers that I had mentioned earlier in this thread. This is the process flow (updated since my last post regarding this. Just look at the sidechain -> output part):
And these are the settings I need to replicate:
And these are the settings I need to replicate:
As I understand it, the compressor uses the side chain as a control signal that determines how the normal input should be compressed. I suppose you want the compression to act on both channels equally, so the balance isn't screwed up?
In that case, make the first mixer output 3 channels, where channel 2 is the sum of 0 and 1.
Add the low pass and peaking filters on channel 2.
Then in the compressor, set this:
Code:
monitor_channels: [2]
process_channels: [0, 1]Then after the compressor, add a mixer 3->2 channels that discards channel 2. And that should be it.
2x MOTU 16A would definitely be a good option, you can use the 2x ADAT output of the first 16A to output 16 channels (limited to 44.1/48 kHz) to the second 16A. Second 16A would be clocked by ADAT from the first. CamillaDSP would only see the first 16A but should be able to use all 32 output channels (16 analog, 16 ADAT).
Another option would be to create a virtual 32 channel ALSA device as described here -> https://github.com/HEnquist/camilladsp-config. However in general the MOTU AVB products do not work well on Linux so this wouldn't be my first choice. In this case you would still need to have one of the 16As clocked to the first, I would use the word clock I/O.
For a host device I would probably get a mac mini as it is small and relatively inexpensive and I prefer mac to windows. Mac also has an aggregate device functionality which should work like the ALSA virtual device described above. I have not tried it with CamillaDSP but imagine it should work.
Michael
Another option would be to create a virtual 32 channel ALSA device as described here -> https://github.com/HEnquist/camilladsp-config. However in general the MOTU AVB products do not work well on Linux so this wouldn't be my first choice. In this case you would still need to have one of the 16As clocked to the first, I would use the word clock I/O.
For a host device I would probably get a mac mini as it is small and relatively inexpensive and I prefer mac to windows. Mac also has an aggregate device functionality which should work like the ALSA virtual device described above. I have not tried it with CamillaDSP but imagine it should work.
Michael
Last edited:
I do not personally know of an interface with the channel count you are looking for that is linux compatible (but also not saying it doesn't exist!). I feel like when you get to that many channels the interfaces are no longer USB class compliant. Even something like the RME Digiface USB which would give 4 ADAT outputs (up to 32 channels at 44.1/48 kHz) is not class compliant.
24 channels is pretty easy as there are plenty of interfaces with 8 analog outputs and 2x ADAT outputs, although it would pretty much require 3 interfaces. RME Fireface 802, Fireface UFX+ and UFX II fall in this bucket.
The wildcard to me is how well the ALSA virtual device works. If it works well maybe you could string together four 8 channel interfaces and there are tons of these that work well with linux.
Michael
USB2/3 microframe period is 125us. Even if you could convince your USB driver to put time-corresponding audio samples for each audio device hooked to the same USB controller into the same microframe, they will be processed by each audio device at a different moment (the packets within the microframe are transmitted sequentially by the controller). IMO time synchronization with sub-microframe precision is impossible without the devices doing some synchronization among themselves externally, separately from the USB bus.
I thought we were talking about multiple USB interfaces with their clocks sync'd via word clock, ADAT, SPDIF, etc but combined in a single ALSA virtual device?
I just tried clocking my MOTU Ultralite Mk5 with SPDIF from another audio interface (Focusrite 18i20) while using an ALSA loopback capture device and it seems to work well. I don't hear any obvious clock sync issues, rate adjust seems to work and the buffer level is relatively stable. So it stands to reason if you could combine 3 MOTU Ultralite Mk5s in to an ALSA virtual device and clocked the first one from it's internal clock and used it's SPDIF output to clock the other 2 they would be all be clocked sync'd and receiving USB data at the same time?
I guess next step would be to make a virtual device combining the Focusrite and MOTU and then confirm that their outputs remain sync'd and everything is stable. I could see there being some fixed sample offsets between the two but that should be measurable and correctable as long as they are consistent.
Michael
I just tried clocking my MOTU Ultralite Mk5 with SPDIF from another audio interface (Focusrite 18i20) while using an ALSA loopback capture device and it seems to work well. I don't hear any obvious clock sync issues, rate adjust seems to work and the buffer level is relatively stable. So it stands to reason if you could combine 3 MOTU Ultralite Mk5s in to an ALSA virtual device and clocked the first one from it's internal clock and used it's SPDIF output to clock the other 2 they would be all be clocked sync'd and receiving USB data at the same time?
I guess next step would be to make a virtual device combining the Focusrite and MOTU and then confirm that their outputs remain sync'd and everything is stable. I could see there being some fixed sample offsets between the two but that should be measurable and correctable as long as they are consistent.
Michael
It's not about synchronizing sample clock etc., but about synchronizing playback of time-related samples. You would have to make sure the two devices receive samples for the same presentation time in the same microframe (which the USB driver would have to ensure), then you would have to synchronize the devices to start playback of the data received in a packet at the same time (something like "start playing data received in the previous frame now"). Both requirements are just next to impossible 
It's not about synchronizing sample clock etc., but about synchronizing playback of time-related samples. You would have to make sure the two devices receive samples for the same presentation time in the same microframe (which the USB driver would have to ensure), then you would have to synchronize the devices to start playback of the data received in a packet at the same time (something like "start playing data received in the previous frame now"). Both requirements are just next to impossible
Got it, that makes sense. Thanks for explaining this stuff, I really appreciate it.
So I guess the only real solution to use multiple interfaces to achieve higher channel count is to use ADAT I/O.
If I was @nerddude I'd probably just use a mac and get two MOTU 16As (connected via ADAT I/O) or an RME Fireface USB + 4x ADAT DACs. BTW we never talked about your source, how are you getting your 11 channels of audio in to CamillaDSP?
Michael
I think that the conclusion is that it is not possible to do mare than 32 channels (ADAT!) synced really.
For feeding Camilla many channels, there is the virtual interface Soundflower(64) - for mac at least..
I don't think it is about handling many channels in but rather you create a lot of channels in a mixer in order to do some fancy signal processing.
nerddude might have multichannel video sound as a goal which has its own challenges with protected digital streams...
//
For feeding Camilla many channels, there is the virtual interface Soundflower(64) - for mac at least..
I don't think it is about handling many channels in but rather you create a lot of channels in a mixer in order to do some fancy signal processing.
nerddude might have multichannel video sound as a goal which has its own challenges with protected digital streams...
//