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

[plissken]

8 hours ago, One and a half said:

In this setting, the Memory Playback is on off or decoded to Memory. I can't see where it's possible to allocate 12.5% of RAM for this purpose, where is?

The 1GB is not a direct setting. It's in the JRiver Dev notes about the max amount of RAM they will request from Windows for buffer.

[Cebolla]

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.

[plissken]

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.

[The Computer Audiophile]

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. 

[ericuco]

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.

[The Computer Audiophile]

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.

 

 

[Miska]

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.

 

[Miska]

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.

 

[Miska]

2 hours ago, ericuco said:

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 is the typical way to operate...

 

[plissken]

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.

[plissken]

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.

[The Computer Audiophile]

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

 

[plissken]

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. 

 

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.

[Cebolla]

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).

[Miska]

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.

 

[Cebolla]

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.

[Miska]

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.

 

[asdf1000]

9 hours ago, plissken said:

I've even made the point that using Roon as a front end for Tidal breaks this buffering model.

[asdf1000]

1 hour ago, Miska said:

Chromecast is now just for video purposes.

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 

[plissken]

8 minutes ago, asdf1000 said:

 

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.

 

 

[Miska]

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.

 

[The Computer Audiophile]

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. 

[asdf1000]

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 😁

[Miska]

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.

 

[The Computer Audiophile]

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.