ASR Open Source Streamer Project

[StefaanE]

Point #4 is the primary reason for my great interest in this project. I have a RPi and a couple of old DACS already, so I can build a great 2 way active with the spare parts I already have. Then in the future it can go 3 or 4 way and just plug in another USB DAC and more amplification.

Two channel DACs are mature, commonplace and great performance is already available at a low price.

Integrating room correction and active cross overs are the opposite - expensive and limited good options available - if this can be done on the RPi then it becomes exponentially more accessible. CamillaDSP already supports Rpi, other Linux, OSX and Windows and as software can always be upgraded.

Plus there are people with active speakers who do need neither DACs nor amplification...

 

[bogart]

Plus there are people with active speakers who do need neither DACs nor amplification...

Great point in addition to @gingerbeer comments as well. So, this modularity and extensibility makes sense. By supporting (but not requiring) external DACs, it lowers cost of entry and permits the use of existing active speakers. Very clear now. Thanks for indulging my line of questioning... this particular requirement to support multiple simultaneous and differently fed (post-DSP) DACs struck me as a major diversion than what I’ve seen in the current platforms.

However, if CamillaDSP natively supports it my concern is moot anyway.

 

[m_g_s_g]

@amirm, do we have a facility to store a common spreadsheet-like document where we could structure the information?

Github?

 

[voodooless]

Then in the future it can go 3 or 4 way and just plug in another USB DAC and more amplification.

That sounds nice in theory, but in practice it does not work very well. These USB DAC’s are not synced, so will inevitably drift apart and cause glitches in sound. You’ll need to async resample for every DAC at the end of the processing chain to sync them up again. This is not a trivial thing to do.

However, if CamillaDSP natively supports it my concern is moot anyway.

It really doesn't care what you use, as long as the OS supports it.

 

[m_g_s_g]

That's two orders of magnitude off of "ok", for interaural detection minimums.

I assume that this applies to left/right channels. I understand that the phase correction that many subwoofers have introduce a delay. My JBL subwoofer even comes with a wireless transmitter that also introduces an additional delay.

Does somebody know the answer to this questions:

• Are humans equally sensible to non-directional bass signal delay?
• Given that we maintain the correct phase with the LR channels, would a bigger delay be acceptable?
• What about the surround channels, is the interaural detection threshold less stringent there?
• Does somebody know what would that threshold be?

 

[dc655321]

I assume that this applies to left/right channels. I understand that the phase correction that many subwoofers have introduce a delay. My JBL subwoofer even comes with a wireless transmitter that also introduces an additional delay.

Does somebody know the answer to this questions:

• Are humans equally sensible to non-directional bass signal delay?
• Given that we maintain the correct phase with the LR channels, would a bigger delay be acceptable?
• What about the surround channels, is the interaural detection threshold less stringent there?
• Does somebody know what would that threshold be?

I don't have answers for you, and this is not the right thread for such a detour.
But, a recent thread here may be helpful, as may some background on Sound Localization.

 

[thunderchicken]

Overall, the RPi4 running volumio is almost exactly what is described in the first post.

- Hardware ist an RPi 4 with 4 Gb RAM and an Argon One Case for passive cooling.
- This is connected to a Topping D10s via USB. This DAC feeds only the headphone amplifier with analog signals, the digital signal is passed on to some active speakers with Hypex Fusion amps via S/PDIF.
- Speaker DSPs do software crossover, EQ , gain of the chassis and running time correction
- Inside Volumio two plugins are used:
- A software simulation of crossfeeds for headphone listening (some tracks really require this)
- some BruteFIR presets do headphone EQ or room EQ for speakers
- As sources local files on the NAS, internet radio and streaming of spotify are available. Tidal and Qobuz are available as extras, but not for free
- If the spotify integration is not liked (it's quite responsive and not so bad in my opinion) also Spotify connect works
- User interface is the volumio app on any Android tablet

What is missing at this setup?

My current setup is the RPi 3 running Volumio into a DX3 and active speakers. It's usually not worth the hassle and I wind up using bluetooth or optical in from an old AppleTV. I find Volumio's interface frustrating and it's not stable enough to just use. It'll get stuck on a particular song or won't play a full album or just cut out after 10 minutes. I usually have to reboot the RPi manually and close Volumio on my ipad. Then there's the issue of having to pull the external drive off to manually update its library. The whole thing is clunky. Originally, I used it as an airplay device, then as a DIY NAS headless player, but I have to reset it to get it to show up on the ipad or as an airplay endpoint, and now that the DX3 is in the loop and I dug the ATV out, I haven't needed Volumio at all.

What I want is something that has switchable EQ profiles for headphone listening and that just works. I have neither of those things right now.

 

[bluefuzz]

What I want is something that has switchable EQ profiles for headphone listening and that just works. I have neither of those things right now.

Use Moode. Generally more stable and more responsive than Volumio. Latest version has 12 band PEQ and coming version will have more advanced DSP (CamillaDSP).

 

[frangle]

A couple of detailed points:

1. Digital Output keep-alive
It seems that quite a few people (including myself) using active speakers with in-built DACs have problems with occasional clicks that happen when the speaker's DAC switches from 0 level to inactive (no stream). It would be great to have the ability in the streamer to keep a digital output stream open to prevent this.

2. UPNP not like MoOde
I'm not sure what the scope is for the software (e.g. renderer only), but as a MoOde user with a preference for UPNP because I have a large collection with extensive tagging, it is clear that the MoOde browser / player approach is at odds with the UPNP model. The browse tree is not something you can import into a library as MoOde tries to do, but is something provided live by the UPNP server. There are many suggestions to follow MoOde, but if UPNP is to be part of this, I suggest looking elsewhere for how to do this properly. This is only a problem when using the MoOde browser, though I also find the discovery of the MoOde renderer (maybe its just MPD) is less reliable than other renderers on my network.

 

[m_g_s_g]

Requirement #6. Optional display.

6. Support of optional display for cool animations/VU meters.

I took a look at that for a HA (Home Automation) need some time ago, and for that reason can quickly share my thoughts here. Options:
1. Raspberry Pi DSI LCD panel. The easiest way would be to use one of the dirty cheap 3.5” 320*480 display clones (or the bigger 7” one). You program them just like you would do for an external HDMI display. 3 broad options here:
1.1. No X Windows server dependency. You could directly write to the linux framebuffer, but productivity libraries do exist (SDL, OpenVG, OpenGL, raylib). Not all of them can benefit from native GPU hardware acceleration. raylib does (https://www.raylib.com/), and seems to come up a lot. It's OpenGL ES based.
1.2. Install a minimal desktop and use any of the many graphics APIs that work on top of X.
1.3. Install a minimal desktop, install chromium and run it in kiosk mode. You can then just use DHTML if latency permits.
2. I2C OLED display module
3. External screen. Many options here. For instance, HifiBerryOS has an integration with LaMetric time.

Data for the VU meters would have to be extracted from ALSA, Pulseaudio, jack..., but I assume that any of them have hooks for that (I have a Rainmeter vumeter widget running in my desktop that gets that data from Windows APIs). Once extracted, I personally would publish that data to an MQTT server for other home automation devices to know (Philips Hue/Nanoleaf lighting effects?).

I like explore very low latency implementation of this to keep better sync with music.

1.1. and 2. have definitely the smallest latency.
I ended up using 1.3. with long polling because of the ease of using very nice graphics (d3.js rocks!).

 

[Morpheus]

REQUIREMENT #6 OPTIONAL DISPLAY

But, what I'm really missing from this Raspberry/DIY scene are nice boxes with nice (capacitive) screens

P.S. I own Flirc case, with Flirc IR control over Logitech harmony - and my wife still finds it complicated because "there are no buttons to press!", therefore my rant [/QUOTE]

A good sized screen for basic control is a must for me, but I would definetely want to go further than just UV meters as Amir suggested, although those would be nice too ....Some of the streamers Audiophonics have are a good base point for me as far as hardware interaction goes, as well as Logitechs approach to hardware/interaction wise.
A nice size angled screen in a nice case for basic functionality is what is needed to bridge the gap between us audionerds and our significant others, they want something as easy to use as the old cd on, amp on, volume adjust, and music! routine, otherwise they`ll stick to their personal phones and Spotify or iTunes and not bother.. That's the difference between being usable for everyone and being the audio center, or one more toy getting relegated to our personal audio corner.
We can still do all of the geeky stuff we love, but I prefer it to be natural and analogic-like in simplicity of use on first brush, to get as many on board.
Don´t forget that this is being born inside ASR, but if accessible and easy to operate can become widespread in the audio community as the high performance no nonsense go-to solution if one is even slightly into DIY if we make it easy for people less interested in the hobby.

 

[Morpheus]

+1 on digital out
I use OpenDRCDI for processing (wouldn´t mind more taps for sure , and better SINAD/ DR after corrections applied) and HYPEX FUSIONs 3 way modules, coax driven, and value for money is great..

 

[dwkdnvr]

Interesting discussion for the most part, and one that illustrates the difficulties that this type of project always seems to run into - too many ideas/possibilities and lack of formal agreement on scope/requirements. Some are looking for a simple 2-channel streamer, some looking for multi-input switching capability, some looking for multiple outputs for active crossovers, others for multiple outputs for multi-sub integration etc. Nailing down the specific feature set has to be step 1.

I went through all of this a couple years back when deciding on an active crossover setup for our living room. I've used Linux for active xovers experiments dating back to Y2k (running BruteFIR on a Pentium III), do software professionally, have multiple PI and x86 boxes lying around and my solution was to buy a MiniDSP SHD . IMHO there are 4 key aspects that drive the complexity - external inputs, sample rate handling, remote control and Room Correction. Deciding on the approach to these 4 really sets the direction and scope of the solution.

External inputs: is this strictly a streamer for stored digital content, or do you need to interface with other devices? - a TV, integrate into an HT system with HT bypass, analog input for a turntable etc. Analog or digital inputs? Analog inputs aren't too bad since the device can remain the clock master. Digital inputs either mean SRC on the inputs, or changing the clock source which can be problematic. Most multi-input audio interfaces don't include SRC on digital inputs (Okto doesn't, Motu doesn't aside from the 8D from what I can tell, Focusrite doesn't).

Sample rate handling: DSP is inherently sensitive to sample rate. If you change the sample rate, all DSP processing has to be updated appropriately. This is surprisingly tricky to do on-the-fly, and it's why MiniDSP always applies SRC to all inputs in order to run at a fixed internal sample rate. An RPi based solution generally won't have hardware SRC available, and so this becomes a software problem. See what the SuperPlayer project is doing as an example of the problem - they have to hack the player to send a sample-rate change event so that the DSP engine can reconfigure itself - for IIR filters this means re-computing the coefficients; for FIR filters it means having 'equivalent' filters available for each rate, or else running the filter itself through SRC. Particularly problematic for external digital inputs which can change sample rates on the fly, but a consideration even for straight streaming with various hi-res formats in the library.

Remote Control: seemingly a minor point, but for anyone intending this to be a 'family room' device, it has to be family-friendly. Harmony integration at a minimum would seem to be required. Also implied here is 'reliability' - if the system goes AWOL when I'm out of town and the wife can't watch TV - well, however much I saved through DIY wasn't worth it.

Room Correction. DIY / open source solutions are available, but not point-and-shoot. DRC-Fir can give results ranging from 'spectacularly good' to 'unlistenable' and has about 500 knobs to twiddle. Rephase is extremely manual, and really more of a 'speaker correction' than 'room correction' tool. REW and it's auto-eq is probably the best from what I can tell, and can export biquads which are about as universal as you get. Almost certainly best handled with a separate PC to do the measurement/manipulation rather than trying to build it into the device. Pretty good bet that nothing open source will be as 'easy' as Dirac.

I didn't include output channels as a driver, but it does come into play. If the understanding is 'more than 2', then it puts you into the realm of needing an audio interface of some sort, or else just using HDMI. Interface support under Linux is better than it has been in the past, but still full of traps. The Okto is the obvious choice if you don't need analog inputs; the Motu M4 is an attractive budget choice, although my reading is that there are some fixes in kernel 5.8 that address problems and most ARM distros I checked still seem to be at 5.4.x. Other motu interfaces 'should work' in theory, but direct experience seems to be rare. HDMI should be automatically supported, but may require .asouncrd work and as we've seen in Amir's testing receivers with top-flight performance are rare although they may be 'good enough'.

So, the above is really my laundry list of the things that make doing this sort of thing more difficult than it may first appear, and what ultimately drove me to just buy a MiniDSP SHD. Reading through the thread, it really does seem that an SHD Studio with 2 or 4 more output channels and having Volumio replaced by a better streamer (Moode or RopieeeXL or PiCorePlayer) is more or less what is being asked for. (at half the price, of course, and ideally not needing the additional MiniDSP software)

It does seem like 'the community' is already moving towards something that largely covers these requirements with CamillaDSP - both Moode and PiCorePlayer (in the form of SuperPlayer) seem to be close to having reasonable integration. I would definitely suggest thoroughly auditing these efforts as I suspect they're way ahead of where a from-the-ground-up effort would get to in any reasonable time frame. If you start from one of these though, I guess the crux of the question is where/how the ASR community can provide a value add over the basic platform. My thoughts:
- validated configurations (specific sound card setups that work, maybe Roon Bridge configuration, external vs internal volume control)
- extending the platform to handle external inputs (plus something like 'HT Bypass mode' which is a requested feature on the SHD; basically switch to analog in and set to fixed volume)
- working on making Room Correction easier/more seamless; probably already happening but routines to upload REW coefficients, convert etc
- Remote control - either via standard LIRC configs or even an ESP32 integration - so that a Harmony could be easily set up.
- multi-sub setup and config. IMHO there is a real gap here. everyone 'knows' that multiple distributed subs is 'best', but actually achieving it is still fully manual from what I can tell. tools for semi-automating this might be interesting.

 

[irate1]

I don't know if anything here would be of value for this project, but I'm sure other ASRers would know if it might.

https://freedsp.github.io/

 

[MatthewS]

The feature set that was posited in the OP and discussed in the thread is so broad that a working product seems unlikely in any reasonable timeframe.

I would recommend distilling down to a Minimum Viable Product (MVP) and getting that built and expanding from there.

I would suggest taking inspiration from Chromecast Audio and add support for Airplay2. This will require hardware certified by Apple and Google but will immediately enable support for Roon and Volumio as well as most streaming services. This also reduces the amount of software necessary to have a viable product.

Chromecast Audio tear down: https://www.ifixit.com/Teardown/Chromecast+2015+Teardown/50189#s108843

BOM: http://referencedesigner.com/blog/parts-used-in-chromecast-2015-or-chromecast-2/2819/

I’m happy to help with the project.

 

[somebodyelse]

I don't know if anything here would be of value for this project, but I'm sure other ASRers would know if it might.

https://freedsp.github.io/

Thanks - I mentioned them in passing but didn't link. The Auverdion Aurora is in there, and it would be nice to see it tested. IIRC there are separate 8 channel ADC and DAC boards, and the Insanity DSP board from the same designer, with a lot of the design in common with the Aurora. The footprints are designed to make hand soldering possible for the brave DIYer - assuming you can get hold of the AKM chips now. There's also a mostly-finished DSP board for the Pi that's a bit more versatile then the HifiBerry offering, but the required redesign around one of the regulators hadn't been completed last I looked.

The pros and cons of SigmaDSP and those DSP chips have been covered elsewhere in the thread.

 

[voodooless]

I don’t think hand soldering is an option for most. Due to AKM shortage the company is currently not shipping any Aurora’s. They might consider redesign if the situation persists.

 

[thunderchicken]

The feature set that was posited in the OP and discussed in the thread is so broad that a working product seems unlikely in any reasonable timeframe.

I would recommend distilling down to a Minimum Viable Product (MVP) and getting that built and expanding from there.

I would suggest taking inspiration from Chromecast Audio and add support for Airplay2. This will require hardware certified by Apple and Google but will immediately enable support for Roon and Volumio as well as most streaming services. This also reduces the amount of software necessary to have a viable product.

Chromecast Audio tear down: https://www.ifixit.com/Teardown/Chromecast+2015+Teardown/50189#s108843

BOM: http://referencedesigner.com/blog/parts-used-in-chromecast-2015-or-chromecast-2/2819/

I’m happy to help with the project.

I think the issue is that those MVPs already exist in several forms. The goal is to take one and expand on it- hence the discussion about Volumio. A pi hat or GPIO cable to an output module and a standardized set of panels for front/back of existing enclosure is relatively easy to do with today's offerings.

We certainly have access to great minds on the subject and there are a ton of experienced DIYers on this forum. In my head, I see this as something that could be cobbled together out of four linked V1 KTBs, a Pi Zero, and DSP software in an open source 3D printed enclosure.... that's 8 channels out with impressive SINAD for a couple hundred bucks. I mean... miniDSP's streamer is pretty close to that.

Obviously a Rpi4 with a dedicated DAC hat and custom enclosure with 4 XLR outs is closer to what's going to happen and at a much lower price point. Basically just using the pi as a monster FPGA for DSP and balanced out. I'm way interested in that.

 

[gingerbeer]

...I see this as something that could be cobbled together out of four linked V1 KTBs, a Pi Zero, and DSP software in an open source 3D printed enclosure.... .

Google failed me - what is a V1 KTB?

 

[m_g_s_g]

Khadas Tone Board. Search locally in ASR... EDIT: