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

[Miska]

27 minutes ago, asdf1000 said:

I believe the Roon Core itself does this when pulling from Tidal or Qobuz... even if between Roon Core and Endpoint is 'continuous'.

 

No, it streams the file from the streaming service...

 

In addition, many streaming services limit the available transfer bandwidth to about 2x of what is needed from the file's bitrate point of view. This is for two reasons; one is to balance the bandwidth usage between users on different network speeds and second is to avoid fast unauthorized leeching of content from the service.

 

[Miska]

13 minutes ago, asdf1000 said:

Yes what I meant is it streams it as fast as possible - there's a big burst with each track being pulled from Tidal/Qobuz by the Roon Core.

 

And then a more 'steady' stream to the Roon endpoints.

 

This is an old post by Roon's CTO but I don't think anything has changed.

 

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.

 

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

 

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

 

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

 

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

 

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