ASR Open Source Streamer Project

[mkarikom]

For what purpose would you need Roon via WAN or a VPN?

Why VPN?
Because VPN is currently the only way to access a Roon server from outside of the LAN that the server is physically connected to.

Why WAN?
Before quarrantine it wasn't unusual for me to have weeks where the majority of my waking hours (weekdays anyway) were at the office, and the lack of official support for access to a home Roon server in a "remote" environment like this was a huge turn-off. Yes, a separate computing device connected to a home VPN would solve this issue, but perhaps not as elegantly as having the functionality build into the streaming box itself.

Disclaimer:
Again, I'm just mentioning this as possible design consideration. I certainly don't begrudge it's omission, or even claim that any but a small population of workaholics (or avid travellers?) would benefit from such a feature...

 

[Skeptischism]

@Balle Clorin @Music1969 yeah, the cost of entry for using that streamunlimited stuff is likely to be prohibitive and under NDA. it looks good though as far as almost turnkey supply of basically what we are looking at. MoOde, with Camilla DSP and optionally ROON/ROONBRIDGE etc, running on a rockpro64 could theoretically support samplerates in the MHz if you want (phofman has shown that linux effectively has no upper samplerate limit), then convert to native DSD after volume control in 64 float in camilla. these are red herrings for the most part IMO, but it does make for the possibility of interesting DAC designs and would certainly appeal to some users. I had been meaning to shoot them an email enquiry, so I did yesterday; we'll see what their requirements are for MOQ and what the cost of their SoC modules are.

 

[drfous]

Has anyone tried to run moOde on anything other than a Pi?

 

[Blake Klondike]

Hey you all. I was wondering if I can get the community to help define, implement and grow an open-source, budget streamer. There are commercial solutions out there but I think we can do better than those.

Here are some aspects I am thinking of:

1. Built on a low cost, readily available hardware platform like RPi. Ethernet and Wifi support of course.

2. End-point support for Roon and Airplay. You call can suggest others.

3. Ability to download parametric EQ or FIR filters for speaker and room EQ. Integration with other tools should be provided for automatic Room EQ.

4. Support for active speakers using software crossovers and multiple external DACs. Support for sub-woofer outputs using independent DAC or whatever is in RPi if it is any good. If not, some kind of low cost HAT DAC.

5. GUI in a web-browser for configuration of above.

6. Support of optional display for cool animations/VU meters. I like explore very low latency implementation of this to keep better sync with music.

7. Cloud/automatic firmware update service with proper security fixes and implementation.

8. Availability of a complete solution in a case ready to go (sans DACs of course).

9. No need for internal UI to browse music and such. All of that will be driven by the client app elsewhere. Indeed the device should run headless out of the box. Per #5, web UI should be there for configuration.

I like us to organize this properly with a project leader and master decision maker in accepting changes, revisions, proper testing process and of course developers to work on these bits. I have one capable member (@StefaanE) volunteering to lead the project and some other bits but may need more development resources. I can be the marketing/product planning person.

This will be an adjunct to project @Rick Sykora is running on open-source ASR speaker design. I look to him to be the high level keeper of all of these sub-projects but need a "butt on the line" for this subsystem.

I don't have a name for this project so feel free to suggest some.

Some parts of the above are easy to do but the rest may present some challenges. Let's put all of our energy and resources toward it as I think we badly need such a simple, reliable, yet highly functional product. I know I need one as I am tired of maintaining my Windows PC based server for this use.

To get things started, let's have a discussion on above feature list and define it. Plus see who all can volunteer to help with what part of it.

Thank you all.

This would be great! How would it work with Amazon Music and Foobar? Would it be platform-specific?

 

[Skeptischism]

@drfous Thats correct, They dont support it on anything else, but it is theoretically possible to build for other boards. I'm mostly interested in it because of its encompassing camillaDSP, but camillla could just be installed separately into whatever build you prefer, such as volumio. i'll be trying moOde on my rock64pro when it arrives. realistically about a month or so by the time I get around to it.

 

[Skeptischism]

Turns out the rockpro64 isnt supported by volumio, only the rock64 and they dont have plans to support it in the future... also they dont support multichannel i2s output on any device and have no plans to do so (the dev for boards other than rpi told me as much), so the rock64 is out too. so moOde only supports pi, which doesnt support multichannel i2s, so including camilladsp in their build is pretty halfarsed dsp if you dont and dont plan to support multichannel.

so if someone wants to cobble together their own build on rockchip, seems like its doable, but none of the audio focused distros make use of the power of the board, so you may as well just buy rpi and be able to run all of them, or run usb out, at which point you may as well use a proper, powerful computer for the task.

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.

 

[notabenem]

I see this more like an opportunity, but I have no idea if tying the solution to a very specific board (Rock64/Rock64Pro) is a wise idea from a business perspective seeing that everyone else is trying to stick to the mass-market RPi.

 

[Skeptischism]

well, its essentially the only board (or chipset) that has multichannel i2s. its not so much tying to therock64, its tying to a set of capabilities that are absolutely required.

if you see it as an opportunity, have at it, code away and its your opportunity.

 

[notabenem]

if you see it as an opportunity, have at it, code away and its your opportunity.

Except that I am not the HW guy. More like SW.

 

[Skeptischism]

are we not talking about SW?

 

[Skeptischism]

rock64 and rockpro64, hell, even that little $12 rockchip board all handle 8 channel i2s according to HW description. the roadblock is SW

 

[notabenem]

are we not talking about SW?

We do. But it's much easier, if one has a matching DAC attached. You think I could get 2-3 of the cheapest I2S boards and try with them?

rock64 and rockpro64, hell, even that little $12 rockchip board all handle 8 channel i2s according to HW description. the roadblock is SW

Unless the 8ch is not really field tested and stable (or usable at all).

 

[Skeptischism]

you could. not sure the MCLK output pin will drive 4 chips without a buffer, so you may be better served to choose an async dac. would def drive 2 dacs and that would be enough to test if ny other pin than the standard 2 channel works. if that works it would be a safe bet all of them do.

 

[notabenem]

...you may be better served to choose an async dac.

How do I recognize one? Is there a particular model you would recommend?

 

[somebodyelse]

Turns out the rockpro64 isnt supported by volumio, only the rock64 and they dont have plans to support it in the future... also they dont support multichannel i2s output on any device and have no plans to do so (the dev for boards other than rpi told me as much), so the rock64 is out too. so moOde only supports pi, which doesnt support multichannel i2s, so including camilladsp in their build is pretty halfarsed dsp if you dont and dont plan to support multichannel.

Is this "we won't do the work to add new board / multichannel i2s but would include it if someone else did it" or "it's not something we're interested in even if someone else did the work to add it"?

 

[gingerbeer]

...so moOde only supports pi, which doesnt support multichannel i2s, so including camilladsp in their build is pretty halfarsed dsp if you dont and dont plan to support multichannel.

<snip>
So, xmos/usb it is.

<snip>

...or forget the distraction and get on with xmos, running camilla on my mac.

I’ve got moOde running:
- moOde on an RPi3B
- camilladsp setup to do active crossover, EQ and convolution. (Crossover, eq and channel maps all setup from within MoOde’s GUI)
- 8 channel output to a minidsp UDIO-8 plugged into the USB port
(it has an Xmos 208 inside. Linux sees it as a USBStreamer. Trick was to make Camilla send it 8 channels of output, even though i’m only needing 6)
- separate DACs connected via aes/ebu, so that they use the clock from the minidsp (for the tweeter and woofer channels).
- active plate amp in the subwoofer, also fed aes/ebu.

the minidsp when reviewed here had quite a lot of jitter but to my ears it all seems to maintain synchronisation across the channels even when playing for an extended time (hours), so I think the DAC clocks are remaining synchronised to the single centralised clock of the UDIO8 that is in the aes/ebu signal. If there is a scientific way to test this it would be good piece of mind.

 

[Skeptischism]

@somebodyelse the rockchip guy wasnt very encouraging. reading the forum didnt make me happy either. Support is patchy and I saw several threads where he was borderline rude in response to regular and reasonable support questions. as for moOde, i'm not sure, youde have to ask Tim. he seems fairly approachable, so its possible he would consider it if it didnt make too much work for him. Perhaps i'll shoot him an email, that was just what he stated on his forum, but it's possible he could be swayed if someone else did the build, especially now that he will be getting a fair few users and requests after the inclusion of camilladsp.

@gingerbeer Oh i'm aware multichannel is possible from moOde over USB/XMOS on rpi. nice to hear its as clean as doing it all from within moOde's GUI though. Congrats. what dacs are you using again? the clocks on your separate dacs cannot be synchronised; there is no means to do so over AES/EBU. depending on the implementation it likely isnt even using the recovered clock. I think its just not noticeable/audible, but thats a win, so take it.

I think its probably a better use of my time to get on with designing the xmos input board. Much as I would love to be able to run i2s directly from an embedded SBC, having the ability for users to run moOde, with camilladsp is very attractive. i'm not giving up yet; I can do both at once after all, but I will be making the xmos a priority. I dont like being backed into a corner though, so this is annoying.

 

[mdsimon2]

I’ve got moOde running:
- moOde on an RPi3B
- camilladsp setup to do active crossover, EQ and convolution. (Crossover, eq and channel maps all setup from within MoOde’s GUI)
- 8 channel output to a minidsp UDIO-8 plugged into the USB port
(it has an Xmos 208 inside. Linux sees it as a USBStreamer. Trick was to make Camilla send it 8 channels of output, even though i’m only needing 6)
- separate DACs connected via aes/ebu, so that they use the clock from the minidsp (for the tweeter and woofer channels).
- active plate amp in the subwoofer, also fed aes/ebu.

the minidsp when reviewed here had quite a lot of jitter but to my ears it all seems to maintain synchronisation across the channels even when playing for an extended time (hours), so I think the DAC clocks are remaining synchronised to the single centralised clock of the UDIO8 that is in the aes/ebu signal. If there is a scientific way to test this it would be good piece of mind.

Although clocks between individual DACs will never be perfectly synchronized in my experience because each DAC will lock to the source clock the corresponding outputs will in perfect synchronization. Jitter and synchronization are two different issues. Synchronization is easy to test if you have a two channel audio interface / sound card.

1) In REW set output channel and timing reference channel to different channels. Set audio interface inputs such that they correspond to those output channels. Play a test tone (I typically use 1 kHz) and use REW's scope functionality to make sure they are aligned. Some examples of what this looks like with a 0.01 ms delay between the channels and no delay are shown below.

2) With the channels setup exactly as described in (1) run a frequency response test using loop back as timing reference. As this measurement involves looking at phase response and it is likely you have a time of flight delay in your system this approach works best in a relative sense. For example using channel 1 as a timing reference and then running frequency response tests for all other channels keeping channel 1 as a timing reference. The phase responses should look identical. If you observe any significant differences this indicates there are delay differences between the channels. Some examples of what this looks like are shown below.

I would expect that all 8 channels of the U-DIO8 are in perfect synchronization but after making some of these measurements and doing a bit of research it looks like multichannel XMOS often have issues with delaying particular channels by 1 to 2 samples. This is certainly the case when using the AES inputs of the Okto dac8 pro.

I am not really sure the jitter of the U-DIO8 was ever really an issue as Amir stated in later testing that the U-DIO8 performed just as well (slightly better actually) than the Topping D10 (which had lower jitter) when paired with a Matrix DAC. However to help alleviate this concern it probably makes sense to use ESS DACs with internal ASRC to stomp out that jitter.

Michael

 

[Skeptischism]

oh yeah, the AES outputs will be, or at least should be in sync, but thats a different thing to the seperate dac clocks being in sync (which they definitely will not be). in practice for this application (vs recording) it shouldnt really matter; as you report.

 

[Skeptischism]

How do I recognize one? Is there a particular model you would recommend?

most ess implementations will be. any board that uses a single crystal and accepts 44.1 and 48khz will be async. usually they will be 50MHz or 100Mhz etc. vs dual 22.xx/24.xxMHz or 45.xx/49.xxMHz