The Ultralite is a bit unusual. It presents itself as two usb devices. One audio device, and one network interface. The network interface is used for configuration by the Motu windows & macOS software
. This new network interface likely confuses the network config on some systems. Ubuntu seems to handle this fine, while RPiOS has trouble.
Well, do you need a multi channel DAC at all with bi amping that's the question.
You can do (analogue) filters before the preamp with simple R-C, then split it into LF+HF with opamps.
I figured if you are going to use Raspberry pi then I absolutely couldn't see the point in using USB audio devices at all. (apart from the MOTU must be a multichannel USB DAC?)
This may sound a bit OT, but it's relevant.
There exists far better DAC using a HAT on GPIO, bearing in mind that they can only be 2 channel devices (ie. stereo on Rpi.).
The Ian Canada implementation of the dual mono sabre DAC using output transformers strikes me as one of the best you can get and sort of looks like this....
This involves going down a totally hybrid route....
In this case I opted not to go for tri-amping, but
tri-wiring using a unique and rarely imagined idea that appeared in Broskie's
tubecad webzine, for resolving some smart crossover issues. So much for theory it's
HERE
And also helpfully pointed out the following:-
"the old
Quad model 57 held two low-frequency ESL panels bracketing a high-frequency ESL panel (as did several other speakers").
Above in fact is a
combination of active and
passive filtering.
This doesn't cause the "holes/character/phase changes" in the audio spectrum caused by active filtering and bi or triamping, for the simple reason "there are giant differences in power requirements for bass vs hf", so that gets a 1st order low pass filter, the rest of the roll off provided by the driver itself.
It wasn't needed in the much admired Quad 57, but they had other disadvantages, which meant compensating a lack of bass, unless stacking yet more quad panels, which of course then presents the amp with a near short circuit at 10-15khz and an impedance curve looking like a roller coaster...
(A solid state amp would compensate for a near dead short by just producing loads more power, which would be the complete reverse of what is needed)
Throwing a stone in the pond again, DSP, bi/triamping v classic crossover etc are not the great magic solution that everyone makes them out to be, esp on ASR.
If you want to use ESL, with non ESL, LF drivers, then it starts becoming real fun**.
ie.some more
reading.
There is also a lot of debate about current feedback amplifiers, showing that solid state amps don't compensate for phase lag, as they have no V-I feedback mechanism.
I solved some this by increasing the sensitivity of the bass drivers system with enormous speaker drivers and giant cabinets....as above (There's many ways to skin a chicken).
Using a single (Admittedly impossibly rare) amp per channel, originally designed for PA, means using simple low and high pass filtering with capacitors and chokes, ie. one secondary of multiple ones on the output transformer for each band of frequencies.
This means the output transformer+different windings end up being part of an active/passive filter system, - fed by the Raspberry pi HAT stereo only on a CM4 with CamillaDSP.
Using the old tried and tested impedance matching (used to be used for 70v and 140V systems in the USA, and 100V line systems in the EU), we can accurately match the power requirements of each section of the audio spectrum to the impedance required to get it, without changing the overall colour/behaviour of the system and the way it reacts to inductance changes).
+
Being as I understood fairly early on the implementation of DHCP, and a number of other things in the Linux 64 IP stack had problems, the smart thing emerged as using the CM4 as an IOT and internet router as well as an audio file server and audio playback system. (you upload files locally on ftp using the vsftpd server).
FYI, I just tested and booted NVME on the CM4 Tofu board.
To my mind, nothing can get close.
e-MMC, already a quantum leap faster than SD cards, which struggle 20-30Mb/s on a vanilla Rpi4 does around 85Mb on benchmark on CM4.
NVME via m.2 (pci-e) is doing 400+ !
It makes a 2ghz overclocked CM4 go like lightning, so I would never ever dream of going back to Rpi4.
, explain me the different samplerates in Camilla DSP? The samplerate on the top is for processing and output. Is the capture_samplerate in the resampling box the same as the Capture samplerate in the status box on the left side? And is the capture_samplerate the samplerate CamillaDSP expects on the input?
