ASR Open Source Streamer Project

[notabenem]

Hmm...multiple wireless endpoints in tight time sync. Can we do that?

Surely not through TCP, but I think it would be doable with UDP transport with some resilience - if needed at all. Frankly I have little to zero experience with audio streaming (and I would welcome in-depth guidance) but I do have a very specific idea from a technical standpoint (transport layer).
NTP is able to provide sub ms time-sync on a local network. Maybe we can do even better on our own, but my guess is 1ms of delay will not be audible between speakers. Will it? The bad thing is this will depend on the WIFI networks' performance. But I can't tell how much without having a PoC and having it measured. My guess is that none of the fancy stuff would be needed (like those showcased in RoC for example), but I may be wrong here.

Having said all this, I think we should start small, and add features later.

 

[somebodyelse]

OtterCast looks like it's doing its audio send/receive via pulseaudio remote streams and/or via snapcast. It's a shame they haven't included any digital inputs or outputs.

 

[StefaanE]

Surely not through TCP, but I think it would be doable with UDP transport with some resilience - if needed at all. Frankly I have little to zero experience with audio streaming (and I would welcome in-depth guidance) but I do have a very specific idea from a technical standpoint (transport layer).
NTP is able to provide sub ms time-sync on a local network. Maybe we can do even better on our own, but my guess is 1ms of delay will not be audible between speakers. Will it? The bad thing is this will depend on the WIFI networks' performance. But I can't tell how much without having a PoC and having it measured. My guess is that none of the fancy stuff would be needed (like those showcased in RoC for example), but I may be wrong here.

Having said all this, I think we should start small, and add features later.

NTP does it by measuring drift and compensating for delays. That's not transposable to audio streams, IMHO.

 

[Phorize]

Good question. Many of the FLOSS projects are OSINO (Open Source In Name Only), a bait and switch to sell the augmented version. I understand bills need to be paid, but it's not the kind of project I would contribute to for free. But everyone is of course free to contribute to their favourite project .


Future directions and suchlike. For the project to succeed, we need to define the smallest set of functions that meets the requirements, but keep in mind how we'd like the product to evolve. Once we have that list of functions and a vision of the future, it will become clearer wether or not there are projects out there that just need a little bit of help to get us what we want.

I suppose moode is more interesting on that front, die hard non commercial, same offer to all users. It’s why I use it!

 

[Phorize]

I suppose moode is more interesting on that front, die hard non commercial, same offer to all users. It’s why I use it!

We could fork moode?

 

[buz]

NTP does it by measuring drift and compensating for delays. That's not transposable to audio streams, IMHO.

I think it could provide a synced clock for playback of a buffer assuming the underlaying hardware has a reliable clock itself. Still probably would not quite be perfect. Definitely would incur a delay due to the buffering. Whether it would be audible, not sure.

As for forking moode or anything, if at all possible try to work with upstream before just forking.

 

[tinnitus]

Hi Folks,
that ist just what im doing with 3 units. My goal was a one button WAF System. And with a streamer-player (Yamaha wxc50) a Raspberry PI 3B+ with a Hifiberry DigiIO+ card for the spdif input. Running Camilladsp for digital XO and room correction with long FIR Filter (Acourate). The output to the 8 channel HDMI DAC (x6000K 7.1) and then to the power amp (IMG2000D) and to my raw-speakers. At the moment i need only 4 channes.
This "chain" could be started with th magic button on the blackbox, and after about 30 seconds music starts playing.

I hope this project brings this into one unit. ;-)

 

[somebodyelse]

NTP does it by measuring drift and compensating for delays. That's not transposable to audio streams, IMHO.

There's a reason the various pro audio network systems are all using variants of PTP I've posted to what might be considered the parent thread - Open Source PLatform Projects at ASR - so we can look at the details as a spinoff project rather than keep sidetracking this one.

 

[somebodyelse]

As for forking moode or anything, if at all possible try to work with upstream before just forking.

+100 - whether it's Moode or one of the other projects, try to work with upstream first!

 

[Ralph_Cramden]

The elephant in the room is the proprietary streaming services, Qobuz, Tidal, Spotify, Amazon, Google/Youtube, Apple, etc that many will expect to work on a streamer. None of these services play nice with open source software and, at best are available only via binary blobs and added licensing fees / contracts. Spotify is the only service that mostly works on open source distros due to Raspotify. But even this is not, I believe 'officially condoned' by Spotify and may cease to work at anytime.

I'm running Qobuz, Pandora, Spotify and Youtube, among other services, on LMS. Don't know whether they'll be yanked anytime soon. Hope not.

 

[Phorize]

+100 - whether it's Moode or one of the other projects, try to work with upstream first!

I guess I was lampooning floss

 

[notabenem]

NTP does it by measuring drift and compensating for delays. That's not transposable to audio streams, IMHO.

We can make a best-guess of the time-difference between sender and the receiver using round-trip times (the most sensitive part, but let's say we accept 1-2ms of error as OK) at the start and the sample rate.
Once we established the baseline we need to ensure that this error/delay is kept constant and not drift:
We timestamp every packet when sent and add a seq no to them. When we realize that the time stamp on source grows slower/faster than our time at the speaker, we either drop the next sample (and thus speed up) or re-play the last sample attenuated (and thus slow down a bit and avoid overheating). Depending on the sample rate we can do speed adjustments in 1/sample_rate increments (which is ~2/100 of a ms). If this sounds too simple to be good, then it probably is

 

[buz]

I guess I was lampooning floss

Fair enough

 

[somebodyelse]

I guess I was lampooning floss

It's a worthy target The truth behind it isn't so much a nugget as a boulder!

 

[abdo123]

Hi Folks,
that ist just what im doing with 3 units. My goal was a one button WAF System. And with a streamer-player (Yamaha wxc50) a Raspberry PI 3B+ with a Hifiberry DigiIO+ card for the spdif input. Running Camilladsp for digital XO and room correction with long FIR Filter (Acourate). The output to the 8 channel HDMI DAC (x6000K 7.1) and then to the power amp (IMG2000D) and to my raw-speakers. At the moment i need only 4 channes.
This "chain" could be started with th magic button on the blackbox, and after about 30 seconds music starts playing.

I hope this project brings this into one unit. ;-)

Wait a second, HDMI DACs exist? outside of the AVR bubble?

 

[jae]

Many people have mentioned that this project idea is akin to or already satisfied by other "good enough" solutions like moode/volumio/... etc. While those are great projects, there is still a distinct advantage of working on another solution from the ground up, especially if it is community based. Some of these platforms have an ancient or unfriendly code base, are closed source, are oftentimes only maintained and developed by a small team or even just one person, and newly requested features can sometimes take months, years, or are never implemented. A few of these options require money/subscriptions to unlock all the features.

ASR is growing insanely quickly and we have the benefit of having all sorts of members that are objective and passionate about audio, users that range from product manufacturers, to industry researchers, influences, and reviewers, or the even some of the designers/engineers of the products we use and swear by, and everything in between. If there's going to be a better solution that doesn't involve lots of $ behind it, it's probably not going to come from anywhere else other than place like here. It also could incentivise DIYers or designers who want to design well-performing hardware around it (a multitude of people are already using RPi as a streaming solution), or that want to make a specific module/addon for it to work with some product. I don't doubt that with enough interest it would be possible to make something at least on par with moode/volumio within a number of months to a year, especially as most of the heavy lifting is already done as far as software implementation goes.

 

[tinnitus]

Wait a second, HDMI DACs exist? outside of the AVR bubble?

Yes, there is this x6000k 7.1 from suptronics, and the essence Evolve II-4K HDMI DAC.
And from Just add Power there is an hdmi to Dante Transmitter 767DSS.

 

[buz]

The x6000k does not seem to be for sale anymore but 300ish USD for the Essence would be quite alright if the quality is any good. Still wonder if an AVR might do the job instead of going for 4-6 channels of hypex .

 

[StefaanE]

Yes, there is this x6000k 7.1 from suptronics, and the essence Evolve II-4K HDMI DAC.
And from Just add Power there is an hdmi to Dante Transmitter 767DSS.

Lots of things to look into. Thanks for the references -- do you have URLs perchance?

 

[dc655321]

but let's say we accept 1-2ms of error as OK

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