From the quick play I had it's basically the Camilla GUI with some moode shortcuts
They are always done. The result is that when you try to load a file with a broken filter, it will give an error won't try to use it. Previously there were a few errors that could sneak through and give either unpredictable filtering results, or make camilladsp exit with a panic.
The gui will show the errors in the little status box.
Haha it is a little bit more the a few shortcuts ;-)
moOde integrates the following into a seamless experience with the already existing parts of moOde:
- camilladsp
- camillagui (jwahle improved the camillagui big time to let it better integrate with moOde for both online as offline camilladsp mode).
- camillagui-backend
- pycamilladsp
- alsa_cdsp
Alsa_cdsp is used to support samplerate switches.
You can find some screenshots of the moOde specific configuration page on Using Camilladsp with moOde 7 – Part 2 – Bitlab's Bytes.
No idea how to do a video, but here are some pretty screenshots of my setup.
Notes:
* I haven't had the chance to generate proper convolution filters for each driver in my Linkwitz LX minis and sub, so I'm just using a dummy filter of [1,0,0,0] and that works fine.
There are also a couple of issues in the current version embedded in moOde that I work around - obviously two moving pieces under active development so zero complaints from me!!:
* the name of the convolution file needs a full path (eg /usr/share/camilladsp/coeffs/file.raw). The GUI file picker shows the right names to choose from, but something isn't passed correctly in the background
* the names of filters can't seem to be changed more often than not - I need to go manually edit the text file (eg here: /usr/share/camilladsp/configs/lx4.yml - also easy as the config file is in clear text).
Overall really happy with it so far - huge thanks to TimCurtis, HenrikEnquist, Bitlab and the many many others who've contributed to all the pieces!
Last edited:
@Gingerbeer, i have a lxmini too and i have been trying to get a headless based crossover dsp...over the last few weeks i was able to get camilladsp to work over pulse, still cant get alsa working. Thanks for sharing the screen shot, guessing with moOde ...it becomes easier due to GUI. Now i just have to get find or get a raspberry Pi as moOde will only work with it. My current SBC is Rock64 which doesn't get too much love in terms of support/ drivers 
@Gingerbeer, i have a lxmini too and i have been trying to get a headless based crossover dsp...over the last few weeks i was able to get camilladsp to work over pulse, still cant get alsa working. Thanks for sharing the screen shot, guessing with moOde ...it becomes easier due to GUI. Now i just have to get find or get a raspberry Pi as moOde will only work with it. My current SBC is Rock64 which doesn't get too much love in terms of support/ drivers
How ironic. Ive been eyeing off the combination of moOde and rock64 ue to the multichannel i2s on the rockchips, but the singular support for rpi rules that out. ive been venting my frustration all over the interwebs ... lol!! its a match made in heaven, that or the rockpro would be all you need for a powerful streamer + >8 channel DSP, volume control and upsampler/digital filter. all this can technically be made to work if you are up to the challenge of writing all the code yourself, for everything, but not in a ready made package like this. It really looks great and I dont doubt it sounds amazing. no way it couldnt; Its all there and more.
The 8-channel i2s of the Rock64 is quite interesting. But are there any 8-channel dacs you can buy that works with it? I haven't found a single one. Of course you can diy something, but the number of people in the world that are both able and willing to do that is probably very small!
Without plug-and-play multichannel dacs, the 8-channel i2s really isn't very useful, with or without moOde..
Without plug-and-play multichannel dacs, the 8-channel i2s really isn't very useful, with or without moOde..
All commercial offerings are for the stereo-only RPi, because most of the ready-made audio distributions are designed for RPi. CamillaDSP is changing the game now, people are asking about multichannel I2S output. IMO your project could be the reason the classical audio distributions would consider porting to multichannel boards with decent kernel support (i.e. in mainline, not just some ancient android kernel). Once the software is there, all the chinese embedded-DACs manufacturers (who almost as a rule struggle with software or avoid it completely, IME) will jump in instantly, it's their business.
Is it really standard 8 channel i2s? if so that's just lrck, bck and 4 data lines instead of one (for stereo i2s). That can easily drive 4 stereo dacs instead of one 8 channel dac. And there are lots of stereo dacs with i2s input to choose from... just my 2ct.
Yes looks that way. It should be possible to use 4 normal dac hats and hook them up so they share LRCK and BCK, and each get their own data line. Not really difficult, but not plug-and-play.
Most PI distributions don't have problems with multi channel audio it self, only there isn't support on the SOC (+driver) it self.
The Pi CM4 module + a carrier board contains a PCIe port. There are already people who try to get general GfX cards working on it. Why not try the same with PCIe audio cards. Pinkfaun even has an PCIe to i2s bridge, only not sure if there is linux driver for the used chip CM8888. I thought that for the CM8788 is better linux support (but also not sure about that).
Also I wonder how large the potential market for multichannel is compared to the current mature dual channel market of the Pi?
The Pi CM4 module + a carrier board contains a PCIe port. There are already people who try to get general GfX cards working on it. Why not try the same with PCIe audio cards. Pinkfaun even has an PCIe to i2s bridge, only not sure if there is linux driver for the used chip CM8888. I thought that for the CM8788 is better linux support (but also not sure about that).
Also I wonder how large the potential market for multichannel is compared to the current mature dual channel market of the Pi?
there are a couple, but nothing of amazing quality. DIYINHK makes an 8 channel 9018 and 9016, but indeed there arent many, thus i'm designing a nice one. well actually i'm designing 2 different ones.
One is an 8 channel (based on 2 x 9038pro, so could be built out to 16, but i'm only using 6 in my current build, 2 ways plus dual subs) and a 4 (or perhaps 6) channel based on 2 or 3 x ROHM. Both with the dacs, IV and important power supplies on the one PCB, not an assortment of legos for everything and every possible tweak. My view is this makes the performance of everything worse in an attempt to please everyone. there arent many, because there arent many sources I guess and active digital XO and DSP has only really started to gain traction recently. I expect the number to grow, but it will always be a smaller market than 2 channel with passive XO. i've been waiting for the power of SBCs to become realistically good enough and from rpi 4, they are IMO and your software is the last piece of the puzzle.
yes, I did ponder the possibility of using the PCIe lanes, but thats a much larger project. the rockpro already has this exposed onboard as well as an M2 slot. its altogether more powerful hardware and would be amazing if it could be made to work IMO. if you were going to do something with PCIe, it would be tempting to try and add another coprocessor for DSP acceleration with neon. although, with the price of the rpi4 compute module, perhaps just building a cluster of RPI CM4 on a base-board would be more cost effective?
hey while i'm here Henrik, do you know of anyone using the amanero 4 channel i2s mode in linux with camilla? I dug mine out last night and have managed to get the 4 channel FW on there (I thought the board was dead after I thought I bricked it during an update) i'll test it out myself soon on my mac and camilla, but just wondered if you knew anyone using that FW, as it doesnt seem to have been picked up by many users in general; perhaps due to the low channel count.
Last edited:
yep, it would appear so. there are even clock dividers, master clock input etc. its not ideal having the board drive 4 duplicate gates on different dacs (ther than sdata 1-4) without a buffer, so perhaps that needs to be taken care of on a daughterboard, but it would probably be OK.
Last edited:
The HDMI-I2S connector pinout in Audio Dandy - How to enjoy High Resolution Audio is only stereo. Maybe other pins are used for the other channels, I did not find any other documentation.
CM8888 is an Intel HDA controller, supported for many years linux/patch_cmedia.c at 7fb9d006d3ff3baf2e205e0c85c4e4fd0a64fcd0 * raspberrypi/linux * GitHub . Maybe that particular device can have a different vendorID/deviceID , it would have to be added to that patch file.
RPi distributions (logically) do not compile modules for PCI devices, their support would have to be enabled in .config and kernel recompiled. E.g. Asus has great multichannel PCI-e cards.
Not as far as I know. But I think it's class compliant so it should work just fine.