• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

ASR Open Source Streamer Project

Marc v E

Major Contributor
Joined
Mar 9, 2021
Messages
1,106
Likes
1,607
Location
The Netherlands (Holland)
I've been following this thread with great interest. As I work in IT I'd like to share my experience that it works best to have a minimal viable product that can easily be delivered. The rest of the features can be build upon that.

It seems to me the core requirement is a dsp streamer.

If that is the case, the best we can offer as a forum is providing quality control in software hardware integration and slowly adding features to software. Making sure it measures well with some hardware of our choice.

Moode camilla dsp & raspberry being an obvious choice. That way we keep it cheap, as simple as can be and adding our expertise to an open source project. With proper measurement equipment and software suited for music lovers instead of just engineers.
 

phofman

Addicted to Fun and Learning
Joined
Apr 13, 2021
Messages
503
Likes
326
I am not convinced that RPi is the obvious choice for a low-cost multichannel streamer with CamillaDSP-based DSP.

Moode is based on raspbian/debian. IMO with some boring but rather straightforward effort the key moode bash scripts could be modified for armbian, mostly changing the hard-coded package version strings and removing/changing the RPi-specific customizations (which could be added later on). Armbian uses recent kernel and is available for rock64 https://www.armbian.com/rock64/ . The problem is keeping the changes rebaseable on top of stock moode. Lots of the hard-coded version strings inside moode scripts could be extracted to separate config files, as already partly in https://github.com/moode-player/mosbuild/blob/master/mosbuild.properties . If moode authors were willing to co-operate (at least accepting patches and keeping the exact versions in the config scripts in new changes) this could perhaps be a viable way.
 
Last edited:

notabenem

Active Member
Joined
Mar 1, 2021
Messages
183
Likes
118
I am not convinced that RPi is the obvious choice for a low-cost multichannel streamer with CamillaDSP-based DSP.

My impression is we kind of reached a similar conclusion a couple of posts back for a solution that would include the multichannel DAC through the I2S. Later on however, some obvious issues (like ROCK64 being rarely supported by other products*) shifted the direction towards a detachable (i.e. USB connected) DAC to be able to use what is already out there - hence the RPi based core.

Or did you mean your statement in general, regardless of the coupling of the DAC?

* There is not a major distribution of KODI that would produce a reliable build on top of Rock64. KODI pages itself do not recommend using it as there are better, more compatible, more working alternatives. Volumio considers dropping support for it. Moode does not support it. OSMC does not support it. The answers I got were mostly about lack of user base - a chicken and egg problem - and that no one wants to invest hundreds of hours to iron out minor quirks in the kernel and drivers to make it a top-notch alternative for any of the SW above. I personally consider the capabilities of the ROCK64 SOC the best for this project, but I also do think that ppl would rather invest in a SOC that is multipurpose (works well with a lot of other solutions) and that is not tightly coupled to the DAC (hence the USB DAC). The RPI ticks these boxes, imo.
 
Last edited:

notabenem

Active Member
Joined
Mar 1, 2021
Messages
183
Likes
118
...
So, xmos/usb it is.

seems like all, or at least most, of these distros are basing their builds on other peoples work, so don't actually have the low-level skills to add features themselves.

So, I guess i'll have a bash at setting the rock up as a 2 channel input, multichannel output bare bones, running camilladsp on it and try and set that up in gadget mode and run that from a pi, which in turn is able to run whatever audio focused distro is wanted, or forget the distraction and get on with xmos, running camilla on my mac.

I guess this means we can also put the https://wiki.radxa.com/RockpiS back on the list as an inexpensive board with the necessary pinouts for 8 channel, subject to it working ok in gadget mode.
 

phofman

Addicted to Fun and Learning
Joined
Apr 13, 2021
Messages
503
Likes
326
IMO the RockPiS USB-audio+ethernet gadget + CamillaDSP configured via a browser running on the USB host is way more an interesting project than XMOS. Of course it requires some linux skills, on the other hand everything is open source and available.
RockPiS has the same OTG controller DWC2 as RPi https://wiki.radxa.com/RockpiS/dev/usbnet . Synopsys developers are actively co-operating and bugs get ironed-out. The audio gadget is receiving key missing features https://www.diyaudio.com/forums/pc-based/342070-linux-usb-audio-gadget-rpi4-otg-3.html#post6644362 . This is why being able to use the latest linux kernel is crucial.
 

Skeptischism

Active Member
Joined
Sep 6, 2019
Messages
229
Likes
124
Designing something that relies heavily on core linux skills for anyone to use it, may be of interest to the hardcore user, absolutely, but my reading of their forum and the forums for volumio etal, has not given confidence in any real help from the hardware developer of (and software development for) the rockpi and that certainly does not appeal to the majority of users. none of the audio focused distros seem interested in multichannel i2s, when its already available by USB and that satisfies the majority of their users. It wont stop me playing with it; my new job requires me to do a lot more linux shell work, so I expect i'll gain more confidence in that area, but its too much of a roadblock for any kind of product development (I certainly wont be waiting around while I gain the skillset to write anything elegant), unless somebody wants to put their hand up? as ive said all along, its not in my skillset currently, i'm much more hardware-centric.
 

notabenem

Active Member
Joined
Mar 1, 2021
Messages
183
Likes
118
Just took a glance to the linked discussion on DIY. I think with @phofman 's help (and seeing that we're close - I am SK, BA) we could actually move this a bit forward. The question is, what are the most important open points to solve:
1. multichannel DAC itself (from a suitable i2S PINOUT onwards). I think we can safely leave this to @Skeptischism
2. USB Audio Gadget mode support. phofman?
3. Audio driver (have never done this, but if noone volunteers, I may give it a try by purchasing a RPiS board + 2 cheapest async DACs)
4. Case (with or without a display)?
5. Power adapter
6. ???
7. Profit?

This indeed will not be anything more than a USB multichannel DAC. Just with the theoretical potential of running as standalone streamer (?) with camillaDSP(??) subject to the boards performance being sufficient. If not, we have 2 options:
a) leave it as a USB-DAC. This will need to be interesting either financially or through its open-source nature with acceptable price surplus against other commercial multichannel offerings in the same quality region.
b) move to a more powerful board (Rock64 or RockPro64). This can always be done later, i guess.

In terms of pure HW costs for any DIY fan, my guess is that the DAC part will be the more expensive part of the solution.
 
Last edited:

notabenem

Active Member
Joined
Mar 1, 2021
Messages
183
Likes
118
The Rockchip ASoCs (e.g. rock64) do 8ch out/in at 192kHz. E.g. this small inexpensive board https://wiki.radxa.com/RockpiS has all 4 I2S data out and data in lines on its pinheaders since v. 12 https://wiki.radxa.com/RockpiS/hardware/gpio#Hardware_V12 . Some of the linux distributions listed on https://wiki.radxa.com/RockpiS/downloads seem to have the latest kernel 5.11. I have not tried yet but rock64/rockpro64 boards look very interesting for multichannel embedded devices.

Where exactly have you seen 5.11 kernel? I can only see 4.4. on the official images (according to the changelog). Armbian does not support yet the RK3308. It says "currently broken" https://www.armbian.com/rockpi-s/
 

Phorize

Major Contributor
Forum Donor
Joined
Apr 26, 2019
Messages
1,550
Likes
2,085
Location
U.K

notabenem

Active Member
Joined
Mar 1, 2021
Messages
183
Likes
118
Those seem to be for RK3399 (thus for Rock64, RockPro64, Rock Pi 4), not for the RK3308. RK3399 seem to be the 'better' chip from the kernel point. Maybe the firmware.none.img.gz would boot it, but I would not hold my breath.
 

Skeptischism

Active Member
Joined
Sep 6, 2019
Messages
229
Likes
124
by the way, i'll post a teaser pic in the next couple of days of where i'm at with the new 8 channel board. It's starting to shape up. No XMOS schematic as yet, still working on the analogue stages and elements of the onboard power supplies. I've been very busy all week at a new position, so only just opened the layout again tonight. Squeezing a high performance 8 channel balanced dac, 2 clocks (NDK) and most power supplies i(all local regulation) into a properly useful, compact form factor (100 x 100mm, with a separate prereg board underneath to supply raw voltages) has been a fun project. the way it is being designed, it could totally be leveraged into an Rockpi, should a software solution for mulichannel i2s be forthcoming and the RPI and xmos could be removed and used in another project. I will not be talking a great deal of detail about parts selection, until the real board is built and tested. I would rather not wake up to find the idea copied somewhere before i've built it and the particular design is not up for discussion. the parts selection and layout are unlike most we see in audio frequency designs (although they are well specified for audio), although i'm not inventing the wheel. I expect FR to be flat out to ~90->100khz (and only then because thats where i'm putting the LPF, the parts are capable of low distortion up into the many MHz range, so careful layout is required)

I think we need to talk a bit more about (or at least confirm details for) control and what people are expecting of the board for control of the dac parameters. being it will be interfaced with a very capable digital volume control in the form of camilla, it may not need much, but real-world tactile control for master volume should be an option, even if its simply interfacing back to moOde/camilla via isolated GPIO. the xmos can pass i2c over USB if required. these control elements will influence the cost in time and money significantly for the project from my end (and thus the end cost) if an additional complex MCU is required. there isnt a whole lot that can be done with control at the ESS chip that cant be done in camilla and xmos. the upsampling and oversampling and use of digital filters is more powerful than what is onboard the ESS IMO, you dont really want to turn the THD reduction off or anything like that and more useful distortion generators are available as plugins on linux if thats your bag :p. Volume control and channel allocation is more usefully controlled in camilla too IMO. Perhaps a basic hardware volume control knob and setting the supply sequencing and input type, lock status, frame-rate and mute settings (and their reflected status) etc is all that's required? people could also add their own arduino based controller like dimdims could be adapted if desired. the XMOS can do a lot, but we dont really need a great deal from it IMO. With Henrik's permission, we could even design a custom wrapper for the GUI. i'm not too shabby as a graphic designer in both vector and pixelated/raster image, so could come up with something cool that is consistent with the design aesthetic.

myself, since a nice web control app already exists, I see no need for a big display. I will be sticking to a nice–if a little bit expensive–kinda retro-cool VFD display https://noritake-vfd.com/cu22042-y1a.aspx. I think full colour displays look tacky on dacs and most people will use their phone or tablet. i'll leave that decision up to you guys, as its not really my end.

thoughts? I kind of need a couple details fleshed out before I can work towards finalizing the schematic, BOM and therefore have a more useful idea of cost, so I could arrive at a more informed ballpark figure, for those intent in nudging that out of me before i'm finished :). Final cost will still depend on how many I/we make in the initial batch. Of course after my tests on the prototype, I would hope to send it off to Amir for testing before making any changes if required and sending 1.0 PCBs off to print. I have a basic reflow oven and hot air setup, so small scale production is doable here. anything more, we'd take it from there. i'm using SMD plastic film caps for some analogue bypass and filter positions, so you have to be careful with the reflow profile. Worst case just those could be soldered by hand, or with a small hotair pen. I will have a very small number of parts on the underside, which is what they want, for obvious reasons reflow soldering is difficult (but not impossible) to do on 2 sides of a board :) i'll probably reflow the top side and then just use a hot air pen on the underside.. i'm using nearly exclusively lead-less parts (no legs of any kind) with the DAC and XMOS being the only parts that have any so far.

Does it interest people to implement a higher current buffer on the output of 2 channels, so that it could be used as a high spec balanced headphone amp on those 2 channels? it wont have high output voltage, but with a buffer would handle most headphones admirably (better than many dedicated headphone amps). I'm designing for around 4.5 ish vrms, so its already a reasonably healthy output at line level, without any voltage gain. perhaps that could be an optional facility for extra $$ over the standard board? I will cost out a design with it on all 8 channels, but it isnt required IMO and it would increase the cost and physical size (as a percentage of a small board) quite a bit and require an additional slightly higher voltage +]- rail for L/R. they could perhaps be the top 2 channels, so the outputs would be available as well as–rather than instead of–the channels used for speakers (for anyone only needing 3 way or under crossovers vs 4 way/8 channel operation)

I do love that i'm designing this for people of like mind, who wont object to my exclusively SMD design. I will not be providing much (if any) means for people to modify their board. i'm already using best in class parts for most positions (within reason and budget) and it wont be an easy task to mod such a compact (probaby 6 layer at this point) layout. Some parts are as small as 0402, I ruled out 0201 as that is just too small for my soldering abilities o_O. Of course, those contributing to the project significantly should be able to have access to the hardware, perhaps after the prototype has been sent to Amir, it could be forwarded onto @phofman and @notabenem to play with (since you live close) and i'll work towards the final revision based on my findings and feedback. then perhaps it could be raffled off for the forum, or you could draw straws for it?

At my new job, I apparently have indirect access to a CNC, i'll be leveraging it for cutting some speaker baffles with integrated waveguides, so we'll see what the capabilities of the machine are. If it can cut T6 6061 alloy, maybe I can work on a case as well, or at least elements of it. we could use an off the shelf case and machine some features into it, or just a nice front and back panel (which could alternatively be ordered by the user at front panel express. If someone on the forum has some contacts for better pricing and quality than they can provide, or access to it directly, that would be awesome. On that note, what connectors are people going to use to connect to their amps? XLR? just those connectors would be bigger than the dac board. i'll probably use mini XLR, lemo, or a mixed signal DSUB wiring harness like used on PCI soundcards (could include a power-good signal for sequencing power).
 
Last edited:

notabenem

Active Member
Joined
Mar 1, 2021
Messages
183
Likes
118
@Skeptischism thanks for this detailed post. Couple of remarks, for my own clarification and some ideas:
  1. Monitoring (VU meter, display, etc) & Control (Volume): best to do in HW, imho (lowest latency, least complication in the USB interface,etc). Unfortunately the Rock*64 do not have Analong INs, and it's probably too much for the XMOS (given the closed source nature), so will likely need a small Arduino as a companion to keep the design as open as possible. Frankly, I'd do the 1st version without any of these, and design some pinouts on the base for the DIY tinkerers (volume control, monitor pins to measure channel voltage output in the analogue domain??? or get that info out of the ESS in digital format if possible)
  2. Headphone amp: Personally, I'd love to have a quality headphone amp. However. This would also mean that we need a volume knob. If the headphone amp could be an 'addon' board, designed separately (if that makes any sense at all) with the necessary pinouts on the base, would be great, imho. Or one can always reserve channels X and Y to his headphone amplifier and do the necessary channel map/merge/virtual surround processing in SW with CamillaDSP. Whether that means a HW headphone plug, I don't know.
  3. Connectors: TRS for space saving. Have absolutely no idea if these have significant disadvantages to XLRs.
  4. Openness of design: this is where it gets a bit unclear for me. What will be the outputs of the HW design stage? Ready-made boards with (soldered or not) elements? A downloadable CAD design? Or a whole built, integrated, tested, and packaged box?
 
Last edited:

somebodyelse

Major Contributor
Joined
Dec 5, 2018
Messages
3,759
Likes
3,067
I'd suggest a header compatible with the TASCAM analog DB25 for the outputs. That would make it fairly easy for people to use their connector of choice. Following the FreeDSP guidelines may broaden the appeal beyond an ASR streamer / active crossover.

I'm ambivalent on the high current buffer for headphones. Perhaps make it optional to populate? The OPA1622EVM would be an easy to add alternative sufficient for many headphones.

I'd keep the board to the minimum - display, volume etc. can be handled via the Pi, XMOS or other MCU. I can see why people who don't already play with such things might want it all in one, but if there's a well documented reference build it should keep it easy enough for them.
 

buz

Senior Member
Forum Donor
Joined
Dec 17, 2020
Messages
320
Likes
324
I'd keep the board to the minimum - display, volume etc. can be handled via the Pi, XMOS or other MCU. I can see why people who don't already play with such things might want it all in one, but if there's a well documented reference build it should keep it easy enough for them.

Agreed. Mission creep is bad for solutions like this.
 

Skeptischism

Active Member
Joined
Sep 6, 2019
Messages
229
Likes
124
1. yeah, I'd suggest the VU meter if done analogue, would be better done at the amp side. they are kind of pointless on the dac, since you only really care about clipping; otherwise they are only relative and an output on the dac, even if its not clipping the dac, could easily clip the input of a badly chosen amp. These are very wide bandwidth parts i'm using and doing something like that in analogue would present quite a few complications and I have very little interest in doing that, plus 8 channels of analogue VU meters would be large and likely expensive. there is 2 x ADCs in the 9028, used for channel balance trim and the THD correction, but i'm not sure how useful the information that could be pulled from them would be of any use for levels. you wouldnt need an ADC on the rockpi for volume control, a fairly easy and cheap ADC to convert analogue voltage to i2C to send where ever could handle that. I believe you can even buy rotary encoders that can output something useful.so it can be done digitally in the dac, the xmos, or camilla. the dac volume control runs at 40bit; I believe both camilla/MoOde and xmos are 64bit; but dont quote me on that, its a vague memory that zI will have to confirm.

2. any board like this should have a volume control. digital is fine. I have used a similar amp stage with an es9018 dac, with all volume in digital domain, for years. it really doesnt get any better IMO. channel match is perfect (ad that was even before ESS added the gain calibration in 9028pro) and its cheap any way you do it. I wouldnt worry about loading camilla or moode too much with any of this. the bench tests henrik did the other day on RPI, show that there is a whole lot more power than any of us need. you kinda have to have some sort of control of these pins at some point, from somewhere; otherwise the dac starts up in defaults, which arent very helpful. IIRC, he had a 4 way crossover at 192khz running on an rpi3 and it was only using 12% cpu or something. i'll find the post and link it tomorrow.

3. not a chance i'm using TRS for balanced audio, they are huge, badly specified for CMRR, expensive for reasonable quality ones, when you need 8 of them. that is a contradiction in terms if we are talking miniTRS, high quality mini sockets and plugs just dont exist at any price. Even the switchcraft ones are kinda average IMO. The plating wears off quickly, contact strength is lame, the list goes on. Legit no good reason to use them for high spec audio IMO. For best balanced performance, phases should be closely coupled together and impedance as close to symmetrical as possible. literally none of that can be achieved with TRS. Sorry, i'm quite opinionated on that topic :)


4. the output of the design stage would be getting boards made and soldered. no blank PCBs will be available, about 0.01% of DIYers would be capable of soldering this board and I have no desire to put my hand up for the required support and hand-holding that would be required; as well as being required to publish the entire schematic, which i'm not willing to do publicly, given the overlap with my product development. It would be very expensive to stuff the board as a one off, buying the parts yourself; as well as virtually nothing in it for me. its a lose lose lose situation.

No, It will be a fully soldered and tested board, no case; well not as a direct outcome of this conversation, although its possible I may design one that people could bundle with the board. in that area I wouldnt require anything for my troubles, unless I was actually producing the chassis, which is unlikely. everyone will have different needs. If I designed a nice one and you guys arranged through someone to get them made, perhaps you could flick me one.


having the headphone amp as an add on board ... not really what I had in mind. others can add one to their chosen outputs if they want, my solution was adding buffers to the IV, making it a composite design, rather than adding a complete other circuit. as I said, i'm working with wide bandwidth parts and the buffers are no exception to that. I wouldnt like to have that on a separate board, it would ruin the layout (you will see what I mean) adding all sorts of parasitics and having the connectors in the feedback loop would make for a comparatively huge loop and the connectors capacitive, on a sensitive, wide bandwidth node. its a recipe for oscillation IMO and against my all analogue on one board, not lego ethos.

the outputs (sans buffer) will drive any balanced headphone amp people want to use, as long as they dont use long capacitive cables and the amp load doesnt have an input impedance lower than 1-1.5kΩ. Any lower than this, the distortion starts to rise, thus not ideal for driving headphones without a buffer, since headphones tick literally all of those boxes.

Totally happy with DB25. well not completely, it's a fugly connector, but well suited and reasonably priced, with surface mounted versions available (to avoid puncturing the otherwise solid ground plane) In fact it, or something like it is what I had in mind and discussed with a friend earlier this week.

yes, display, control etc was never going to be on the dac board itself. glad everyone is happy with that. it will need some sort of control or MCU somewhere to work though, as I mentioned.
 
Last edited:

Music1969

Major Contributor
Joined
Feb 19, 2018
Messages
4,676
Likes
2,849
Moode camilla dsp & raspberry being an obvious choice. That way we keep it cheap, as simple as can be and adding our expertise to an open source project. With proper measurement equipment and software suited for music lovers instead of just engineers.

Since this is already freely available (load moode audio onto SD card and put it in RPi4) then what would this streamer project add to the moode solution, that moode doesn't already provide ?
 

Marc v E

Major Contributor
Joined
Mar 9, 2021
Messages
1,106
Likes
1,607
Location
The Netherlands (Holland)
Since this is already freely available (load moode audio onto SD card and put it in RPi4) then what would this streamer project add to the moode solution, that moode doesn't already provide ?
:D I'm just glad it worked out and somebody started making something. That's the most difficult thing. The rest will follow.
 
Top Bottom