I'm in the same boat. Do let me know if you find a solution.
It took me a lot of effort to get the correct album art for my 3000+ albums. I would like to use that.
Have you tried Max2Play? or Moode?
Hi guys, after quite some searching around this and other forums, blogs etc. I have come to what seems a bit of a dead end (at least for my available time and skills), wrt audio focused distros. I need multichannel i2s output from an SBC.
rpi does not support multichannel i2s, only over USB.
Volumio 2 is available for rock64 (but unfortunately not the more powerful rockpro64) and I have confirmation from their DEV for non rpi sbcs, they likely never will. it also does not support multichannel i2s output on the rock64 and again, their dev said there is 'no demand' so no support for it and said there likely never will be a build that supports it. I have my suspicions he simply doesnt want to admit hes still basing his work on someone elses build and does not possess the low level skills to achieve it. that was the case for other audio focused features that took a long time to be added.
moOde now includes camillaDSP, but the say they do not support any other sbc than rpi, so as a result, they are a dsp capable audio focused OS that doesnt support multichannel i2s on boards that actually have it ...
So basically unless you are an advanced linux user that is able to cobble together all of the pieces required fr a build, by yourself, you are stuck using USB->multichannel i2s and at that point, you may as well use a powerful computer IMO.
have I missed something here? do ANY of these 'audio focused' builds actually support the main game changing possibilities the embedded hardware enables? moOde including camilladsp in their build was an exciting announcement, but to then find out its only available on 2 channel hardware ... disappointing.
all of this leads back to xmos
rpi does not support multichannel i2s, only over USB.
Volumio 2 is available for rock64 (but unfortunately not the more powerful rockpro64) and I have confirmation from their DEV for non rpi sbcs, they likely never will. it also does not support multichannel i2s output on the rock64 and again, their dev said there is 'no demand' so no support for it and said there likely never will be a build that supports it. I have my suspicions he simply doesnt want to admit hes still basing his work on someone elses build and does not possess the low level skills to achieve it. that was the case for other audio focused features that took a long time to be added.
moOde now includes camillaDSP, but the say they do not support any other sbc than rpi, so as a result, they are a dsp capable audio focused OS that doesnt support multichannel i2s on boards that actually have it ...
So basically unless you are an advanced linux user that is able to cobble together all of the pieces required fr a build, by yourself, you are stuck using USB->multichannel i2s and at that point, you may as well use a powerful computer IMO.
have I missed something here? do ANY of these 'audio focused' builds actually support the main game changing possibilities the embedded hardware enables? moOde including camilladsp in their build was an exciting announcement, but to then find out its only available on 2 channel hardware ... disappointing.
all of this leads back to xmos
InspectorGadget: Creating a distribution which covers all possible cavets, potential alternatives and problems and serves a safe path for everyone without any manual tweaks is extremely complicated and laborious. Moode is full of scripts with exact package version IDs, any attempt for universality was avoided and I perfectly understand the reasons. Yet it is "just" a PHP frontend and collection of scripts, nothing which could not be modified for any other linux SBC. But that means having to maintain it separately since then and that is a HUGE work and commitment. Especially if the project is advertised as "no knowledge required" towards people who have no interest in learning linux.
For those willing and wanting to learn the existing Rockchip-based SBCs with multichannel I2S outputs/inputs present an attractive and rewarding target, IMO.
For those willing and wanting to learn the existing Rockchip-based SBCs with multichannel I2S outputs/inputs present an attractive and rewarding target, IMO.
Your right on phofman. I'd say for mere mortals, it is impossible. Just keeping an application running on the never ending list of Raspberry Pi hardware is an effort.
For example, RPi has recently improved their ALSA configuration. Great, but you need to go back and fix up the code to work again just to get back to square one. Also, things like MMAP which used to work 100%, doesn't work for some combinations now.
For example, RPi has recently improved their ALSA configuration. Great, but you need to go back and fix up the code to work again just to get back to square one. Also, things like MMAP which used to work 100%, doesn't work for some combinations now.
Oh I get that, it just surprised me that none of them support it and have no plans to, in spite of the obvious move towards dsp in both the consumer and diy spaces. Just about all of the current crop of top shelf speakers are active, digitally crossed speakers and I expect that trend will continue.
I have the rock on the way, but starting from scratch doesn't excite me, especially given I'm a relative noob in the area of nix and programming in general. I've got my hands and head full designing hardware, so likely I'll just keep my focus on xmos and USB.
I have the rock on the way, but starting from scratch doesn't excite me, especially given I'm a relative noob in the area of nix and programming in general. I've got my hands and head full designing hardware, so likely I'll just keep my focus on xmos and USB.
Nope... maybe the "current crop of top shelf speakers" you peruse but that is a tiny subset of all speakers.
I agree that the manufacturers move is to dsp and active pc based systems for reasons of economy and amongst some hobbyists but in the wider consumer market and especially the purist audiophile market this may be a very, very, tiny, small subset
??
Last edited:
Hi InspectorGadget,
You have to "follow the money". People can make a bit of money making hardware, so there is a proliferation of companies making hardware.
Most people expect software to be very cheap or free. This means software has to appeal to a large audience (to make a little money) or you might be lucky and find a software developer that is also interested in your particular project. You have to remember, to write the software you also usually need to buy the hardware.
I have dozens and dozens of RPi's, audio HAT's, USB devices and other hardware and still only cover a small portion of the combinations.
I think hardware projects are a little easier than software projects because a hardware project has a fixed ending, software projects just go on "forever".
regards
You have to "follow the money". People can make a bit of money making hardware, so there is a proliferation of companies making hardware.
Most people expect software to be very cheap or free. This means software has to appeal to a large audience (to make a little money) or you might be lucky and find a software developer that is also interested in your particular project. You have to remember, to write the software you also usually need to buy the hardware.
I have dozens and dozens of RPi's, audio HAT's, USB devices and other hardware and still only cover a small portion of the combinations.
I think hardware projects are a little easier than software projects because a hardware project has a fixed ending, software projects just go on "forever".
regards
@DRONE7, I can assure you, building 6 high quality mono amplifiers and 3 stereo balanced dacs is not a value proposition vs passive ... (in my case i'm building a 2 x 9038PRO with each dac outputting 3 x balanced outs and also a dac based on 3 x ROHM dacs and choosing what I prefer) one could just find an old HDMI receiver and repurpose it, but that's not how I do things. Oh how I wish it were.
(btw, I predicted your reply; fair enough, I should have chosen my words more carefully)
agreed, software support is an ongoing cost, but that is the case for the stereo versions too. there simply arent many multichannel i2s input dacs available to purchase. I could count them on one hand; while there are hundreds of stereo. So while yes, it would mean another hardware i2s profile for them to maintain, but nothing like what they are doing already.
I get it, but I also will likely end up economising on my time and just lay out the xmos and clocking board i've been putting off, sooner, rather than later. I love the idea of an end-point with embedded SBC, running camilladsp, but maybe we just arent there yet.
(btw, I predicted your reply; fair enough, I should have chosen my words more carefully
)agreed, software support is an ongoing cost, but that is the case for the stereo versions too. there simply arent many multichannel i2s input dacs available to purchase. I could count them on one hand; while there are hundreds of stereo. So while yes, it would mean another hardware i2s profile for them to maintain, but nothing like what they are doing already.
I get it, but I also will likely end up economising on my time and just lay out the xmos and clocking board i've been putting off, sooner, rather than later. I love the idea of an end-point with embedded SBC, running camilladsp, but maybe we just arent there yet.
Last edited:
That being said. I emailed these guys guys yesterday https://www.streamunlimited.com/wp-content/uploads/2020/03/Stream1832-V2.1.pdf
lets see if they are open to selling to diyers and low volume designers.
lets see if they are open to selling to diyers and low volume designers.
HW producers very often struggle with software development. If you look at drivers for the various DAC boards "upstreamed" to RPi kernel, it's copy/paste everything, with very few exceptions. And there is nothing to copy from multichannel I2S from rock64.
Instead of writing codec drivers for their chips and sending them to alsa ASoC upstream, they write the code specific for their board only and the directories are full of duplicate code, only methods renamed to fit their product names. ES9038Q2M codec, Si5351 clock - hifiberry-branded drivers, while the mainline kernel (real upstream, not the RPi clone) lacks the former and already has the latter one - of course named after the chips, not hifiberry-sth.... And hifiberry is one of the few exceptions for writing their code.
Maintaining a complete linux audio distribution for multiple SBCs involves much more than just different hardware i2s profiles. Look at this script mosbuild/mosbuild_worker.sh at master * moode-player/mosbuild * GitHub which builds moode for RPi. Most versions hard-coded in the commands. Will you have the same versions e.g. in armbian for rock64, when Raspbian is heavily tweaked? It really makes sense to focus on one platform only (unfortunately an ugly ARM + proprietary Videocore combo which offers only stereo I2S).
Sure, if the project was built from scratch by buildroot, it would likely be easier to port to other SBCs. But also MUCH more difficult for the maintainers, testers, etc. Maintaining the software part is way more difficult than building the HW.
On my way to a full digital system, to control my LX-Mini speakers, I made sevral attempts. I think that the Beaglebone Black has a distribution that can control multiple I2S, but it was a niche at that time. Nothing mainstream.
I tries to control 2 FX-Audio D802 using 2 USB ports of an OrangePi, but the synchronization between the 2 channels (different USB) was not sufficient to have the stereo imaging on the center => dead end.
I finally programmed a stm32F7 dev board (Nucleo board); bare metal for Asynchronous USB IN => DSP => 2 I2S output. Works like a charm since several years.
Last experiment wend to developping a TI TAS3251 board: I2S in + DSP+TPA3251 power stage in one chip.
All those solutions, at the end, have the music on the RPi as a streamer to USB, and then the rest of digital chain out.
That was in fine "my easiest way" to do it.
JMF
I tries to control 2 FX-Audio D802 using 2 USB ports of an OrangePi, but the synchronization between the 2 channels (different USB) was not sufficient to have the stereo imaging on the center => dead end.
I finally programmed a stm32F7 dev board (Nucleo board); bare metal for Asynchronous USB IN => DSP => 2 I2S output. Works like a charm since several years.
Last experiment wend to developping a TI TAS3251 board: I2S in + DSP+TPA3251 power stage in one chip.
All those solutions, at the end, have the music on the RPi as a streamer to USB, and then the rest of digital chain out.
That was in fine "my easiest way" to do it.
JMF
Do you have more information on this? Github project or anything else? I have an STM32H7 board that would be more than powerful enough to do something interesting...
Yes, available on Github:
GitHub - jmf13/F7USBAudio: USB Audio to DSP to SPDIF
Home * jmf13/Const_DSP_I2S_DAC Wiki * GitHub
I've not put my hands in the code since that period. And should be possible to improve. But works really fine !
JMF
GitHub - jmf13/F7USBAudio: USB Audio to DSP to SPDIF
Home * jmf13/Const_DSP_I2S_DAC Wiki * GitHub
I've not put my hands in the code since that period. And should be possible to improve. But works really fine !
JMF
That is great, thanks so much for sharing! I see you used STM32Cube, so it should be possible to port to the H7 family.
Not all the music I listen to is something I have as files. Up until youtube changed their API, I loved that I could playback audio from youtube videos on my Volumio setup. Have any of these apps figured out how I can playback youtube yet, or at least made it possible to use chromecasting to send the audio to them? Seems silly that this isn't a simple fix.