Jump to content
IGNORED

Network Playback, Buffers, Continuous Stream, etc...


Recommended Posts

2 hours ago, Miska said:

 

Some six months ago I needed to increase Roon - HQPlayer stream buffering because Roon was not buffering enough and you would too easily get drop-outs on slower internet connections.

 

And in many cases when you deal with streaming there are no "tracks" to download, because it could be endless stream like radio, or a live stream from an event.

 

Roon's endless stream method does have the advantage of providing a workaround for the non-gapless supporting Chromecast devices to appear to play gaplessly.

 

Standard UPnP/DLNA normally network streams the individual audio file tracks, though some specialised endless stream providing UPnP software does exist (eg the foo_out_upnp foobar2000 plugin component).

Hence the need for the UPnP renderer/endpoint itself to handle gapless playback support. This means at least the beginning of the following track would need to be streamed in parallel before the current one has finished streaming for gapless support to be handled in time, if the network streaming rate were to be restricted to just the audio playback rate.

We will win because our NHS is the beating heart of this country. It is the best of this country. It is unconquerable. It is powered by love.

-- Boris Johnson

 

We are far more united and have far more in common with each other than things that divide us.

-- Jo Cox

Link to post
Share on other sites
17 hours ago, The Computer Audiophile said:

There's not a single "this is how it works" statement to be made, but I think a good discussion could pull out some details that may educate people. 

 

I just want to add some color, from my posting history, about this statement. I've always spoken about what I consider the best approach for me and under what circumstances. I've never made any statements about any scenarios, software+endpoint hardware that I haven't thrown under the microscope. I know how to pick the hills I'm willing to die on ;-)

 

That is JRiver and Tidal will buffer up entire tracks as quick as wire speed allows. I've even made the point that using Roon as a front end for Tidal breaks this buffering model.

Link to post
Share on other sites
8 minutes ago, plissken said:

 

I just want to add some color, from my posting history, about this statement. I've always spoken about what I consider the best approach for me and under what circumstances. I've never made any statements about any scenarios, software+endpoint hardware that I haven't thrown under the microscope. I know how to pick the hills I'm willing to die on ;-)

 

That is JRiver and Tidal will buffer up entire tracks as quick as wire speed allows. I've even made the point that using Roon as a front end for Tidal breaks this buffering model.

I totally hear you on this. I think the topic is really interesting because many people think they know how this works, but they've only read post on forums, that suggest one way or another. I'm not pointing any fingers at you. In fact, i'd love your continued help and input. The fact that you have a method that works in the opposite way as what I've tested is great. I'm going to run tests on my similar setup this afternoon and post the results. 

 

My goal is to get more information in peoples' hands. I think this thread so far has started on the right path to do this. 

Founder of Audiophile Style

Announcing Polestar | Quick Community Reviews and Ratings

Link to post
Share on other sites
12 hours ago, The Computer Audiophile said:

For those with spikes during playback, does the entire track get sent, thus enabling the cable to be pulled (if you actually wanted)?

 

I was monitoring the network traffic as the last track finished up and there was a continuous small amount of inbound (RX) traffic until maybe 5 -10 seconds before the track ended then the traffic dropped to basically nothing.

 

So it appears that a chuck of the file is loaded (buffered) well before it starts playing (thus the spike) then a constant stream after that.

Eric


Ubuntu Studio Linux box (i7-9700, 8 cores, 16GB RAM, Intel X520-DA1 NIC, Roon, HQP) > fiber optic > MikroTik CRS305-1G-4S+ > fiber optic > opticalRendu (HQP NAA) > Holo Cyan (DSD version) > Nord One UP NC500MB mono blocks > Klipsch La Scala — digital volume control with HQP via Roon client, DSP with HQP convolution engine

Link to post
Share on other sites

Here is my test with JRiver running on CAPS Twenty, sending to JRiver running on CAPS Twenty.One. The behavior, without changing any "major" settings, is to send the whole audio file to the endpoint at the start of the track and then rest. I can't see the sending rate because Windows sets the scale automatically too low. 

 

@plissken Do you know how to manually change the Windows network activity monitor scale? When using JRiver it is way to small, with the maximum being either 1 Mbps or 11 Mbps.

 

JRiver Buffer 1.jpg

 

JRiver buffer 2.jpg

Founder of Audiophile Style

Announcing Polestar | Quick Community Reviews and Ratings

Link to post
Share on other sites
3 hours ago, Cebolla said:

Roon's endless stream method does have the advantage of providing a workaround for the non-gapless supporting Chromecast devices to appear to play gaplessly.

 

Standard UPnP/DLNA normally network streams the individual audio file tracks, though some specialised endless stream

 

How I see is that it is the way Chromecast is supposed to be used. It is designed to be streaming endpoint.

 

And it is not UPnP renderer anyway...

 

NAA (and RAAT) works in a similar way, it doesn't ever see track boundaries unless output rate needs to be changed.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to post
Share on other sites
1 hour ago, The Computer Audiophile said:

Here is my test with JRiver running on CAPS Twenty, sending to JRiver running on CAPS Twenty.One. The behavior, without changing any "major" settings, is to send the whole audio file to the endpoint at the start of the track and then rest. I can't see the sending rate because Windows sets the scale automatically too low. 

 

If you need to send half an hour track at DSD256 or let's say 1.5 MHz 32-bit rate, especially 5.1 channel. I doubt it would send the entire track at once. The peak is pre-buffering spike. You can see similar with NAA too.

 

Many endpoints, such as active speakers, networked DACs or streamers and such likely wont have several gigabytes worth of memory to buffer such large tracks.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to post
Share on other sites
3 hours ago, ericuco said:

 

I was monitoring the network traffic as the last track finished up and there was a continuous small amount of inbound (RX) traffic until maybe 5 -10 seconds before the track ended then the traffic dropped to basically nothing.

 

So it appears that a chuck of the file is loaded (buffered) well before it starts playing (thus the spike) then a constant stream after that.

 

That would make perfect sense: If you have established a 10 second buffer you fill that and then rate out to keep it filled. I would rather less handling be done.

 

We have powerful, low TPD, high throughput network options. I would like more devs to take advantage of these setups.

Link to post
Share on other sites
2 hours ago, The Computer Audiophile said:

Do you know how to manually change the Windows network activity monitor scale? When using JRiver it is way to small, with the maximum being either 1 Mbps or 11 Mbps.

I don't look at the graph, I look at the S/R to the left.

Link to post
Share on other sites
5 minutes ago, The Computer Audiophile said:

Here's Roon on CAPS Twenty sending to Roon Bridge on CAPS Twenty.One. Very different from JRiver to JRiver. 

 

roon to bridge.jpg

My experience with Roon is it doesn't set aside very deep buffers.

 

With devices like sub $100 Pi 4 with 8GB RAM and 1GBe I would like to see some flexibility in setup preferences.

Link to post
Share on other sites
1 hour ago, Miska said:

 

How I see is that it is the way Chromecast is supposed to be used. It is designed to be streaming endpoint.

 

Well, I wouldn't expect you to say otherwise, given that you chose the NAA to work similarly 😃. Unfortunately, none of the popular online music services that currently support Google Cast think the same as you do and prefer that their customers stream to their Chromecast devices with 'gaps'.

 

Of course Google designed the Chromecast devices to be both individual audio file network players as well as endless stream endpoints, the only problem is that they 'forgot' about the gapless playback support requirement with the device operating as an individual audio file track player.

 

 

1 hour ago, Miska said:

And it is not UPnP renderer anyway...

 

Indeed, Google Cast streaming technology is incompatible with UPnP/DLNA streaming - though helper software exists to bridge the two (eg BubbleUPnP Server, BubbleUPnP Android controller app, mconnect Player controller app, etc).

We will win because our NHS is the beating heart of this country. It is the best of this country. It is unconquerable. It is powered by love.

-- Boris Johnson

 

We are far more united and have far more in common with each other than things that divide us.

-- Jo Cox

Link to post
Share on other sites
21 minutes ago, Cebolla said:

Of course Google designed the Chromecast devices to be both individual audio file network players as well as endless stream endpoints, the only problem is that they 'forgot' about the gapless playback support requirement with the device operating as an individual audio file track player.

 

I think the reason why they "forgot" is that it was designed to be just streaming endpoint. Already Google Cast naming indicates towards the same, for casting content from other devices to the endpoint, like Miracast too which we implemented some years ago at my past day job.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to post
Share on other sites

In which case Google Cast support for the endless stream unfriendly WAV container still suggests poor judgement, if the use of Chromecast devices as an individual audio file track players was never even a minor consideration.

We will win because our NHS is the beating heart of this country. It is the best of this country. It is unconquerable. It is powered by love.

-- Boris Johnson

 

We are far more united and have far more in common with each other than things that divide us.

-- Jo Cox

Link to post
Share on other sites
53 minutes ago, Cebolla said:

In which case Google Cast support for the endless stream unfriendly WAV container still suggests poor judgement, if the use of Chromecast devices as an individual audio file track players was never even a minor consideration.

 

The whole audio-only playback thing is pretty much gone since they discontinued Chromecast Audio. It was probably just a low effort sidekick. Chromecast is now just for video purposes. Gapless switching from movie to another is less of an issue anyway. And other cases are screen casting or game streaming which are endless streams.

 

UPnP AV is pretty messy too without clear design vision. DLNA tried to fix that a little, but it's a bit of a patch work with commercial interests by defining things that require licensing fees as mandatory.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to post
Share on other sites
8 minutes ago, asdf1000 said:

image.png.1a5297f61658fb38b512cc9c28fdcd9c.png

 

All I know is if I started playback in Tidal I could pull the network after about 10 seconds and I was good for the duration. If I logged into my ROON account and hit Tidal it wouldn't. But that was awhile ago and things may have changed.

 

 

Link to post
Share on other sites
34 minutes ago, asdf1000 said:

Chromecast Built-in for audio only lives in newly released products.

 

Look at new KEF LS50W 2.0

 

And new range of Harman wireless audio products 

 

They probably made some contract about use of the tech before Google shot down it's Chromecast Audio.

 

Let's see if it is still around after 5 - 10 years.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to post
Share on other sites
11 minutes ago, Miska said:

 

They probably made some contract about use of the tech before Google shot down it's Chromecast Audio.

 

Let's see if it is still around after 5 - 10 years.

 

Google owns a 41% stake in StreamUnlimited, the company supplying the cards used by the companies offering Google Cast support. 

Founder of Audiophile Style

Announcing Polestar | Quick Community Reviews and Ratings

Link to post
Share on other sites
48 minutes ago, Miska said:

Let's see if it is still around after 5 - 10 years.

 

I feel like we could play the "let's see if they are still around in 10 years" game for every popular name/brand/company in this hobby and there would be uncertainty for all.

 

So better not play that game and enjoy what we have now 😁

Link to post
Share on other sites
52 minutes ago, The Computer Audiophile said:

Google owns a 41% stake in StreamUnlimited, the company supplying the cards used by the companies offering Google Cast support. 

 

If they are so interested on this stuff, they could as well fix the protocol for gapless playback then? They could probably do it without too much trouble?

 

Or maybe it is very little of interest for them, with main interest being in video playback? And game streaming from the cloud, for which they are selling package of game controller and Chromecast Ultra.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to post
Share on other sites
35 minutes ago, Miska said:

 

If they are so interested on this stuff, they could as well fix the protocol for gapless playback then? They could probably do it without too much trouble?

 

Or maybe it is very little of interest for them, with main interest being in video playback? And game streaming from the cloud, for which they are selling package of game controller and Chromecast Ultra.

 

I don’t think there is any interest in gapless from Google, or HiFi for that matter. StreamUnlimited has IP that’s cheaper and quicker to purchase than create itself, so Google just wrote a check. 

Founder of Audiophile Style

Announcing Polestar | Quick Community Reviews and Ratings

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×
×
  • Create New...