PDA

View Full Version : Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?



AndrewFG
2012-11-13, 14:18
I have been experimenting a bit with try to get Squeeze players to play remote hi-res stream files e.g. via "Tune-In Url".

I am not convinced that they really have the horsepower to download and play such streams. In my experience they are always running out of buffer and you get continuous rebuffering pauses. e.g a 192000Hz x 2channel x 24bit flac requires a sustained download capacity of around 7mega-bits-per-second, enough buffer to survive several seconds of lost comms, and therefore also enough burst download speed to catch up any periods of lost comms, and I don't think the players can actually do that.

The players seems to be able to handle such tracks served by LMS, but the don't seem to be able to handle such tracks fetched by HTT GET from remote servers. And BTW I don't think it is the remote server that is at fault, since I have also tried to simulate this using a local server on my home network which should have enough bandwidth.

Any similar experiences?

pippin
2012-11-13, 14:33
What on earth should that be good for?

AndrewFG
2012-11-13, 16:05
What on earth should that be good for?

Sorry Pippin but I don't understand your point.

pippin
2012-11-13, 16:31
You want to stream 7mbit/s over a pipe that isn't up to it and say the player is to blame?
In a format that is not only inappropriate for streaming over the Internet but in addition a mere waste of bandwidth?

Mnyb
2012-11-13, 18:25
Flac and Ethernet conected is your best bet and you have to use Triodes EDO to get it out of the player ( Touch ) on the digital out( analog out not possible ).

If younhave an unmodified Touch the server is downsampling 24/192 to 24/96 .

MrC
2012-11-13, 18:25
You want to stream 7mbit/s over a pipe that isn't up to it and say the player is to blame?
In a format that is not only inappropriate for streaming over the Internet but in addition a mere waste of bandwidth?

Think: Local LAN DLNA.

JJZolx
2012-11-13, 23:52
You don't say which players you've tried without success.

A high bitrate stream is going to be much more susceptible to buffer underruns due to fluctuations in the streaming rate (but you knew that already) . One thing I've noticed about 24-bit FLAC is that the compression ratios tend to be much worse than their 16-bit counterparts, so that will compound the problem. Take content streamed at 16/44.1 compressed 50% and compare it to the same at 24/96 compressed just 35% and you're talking about more than 4x the bit rate, so just 1/4 of the amount of playing time in the buffer.

You might try proxied streaming through the server, if you haven't already. That may help smooth out the bumps.

pippin
2012-11-13, 23:52
Think: Local LAN DLNA.

In the local LAN I understand it. You don't want to resample these ridiculous waste-of-space files so you want to directly stream them.
But here we are explicitly talking about REMOTE streaming. A stream that consumes more bandwidth than an HD video! It's just a waste of bandwidth, downsample it to something sensible, say 48 kHz and you will be fine.

AndrewFG
2012-11-14, 04:56
Think: Local LAN DLNA.

Thank you MrC !! -- You got there before me.

Yes indeed, the context is my Whitebear application which provides extended UPnP / DLNA functionality to the Squeezebox world.

There are quite a few UPnP / DLNA media Control Points coming out that have the capability to stream hi-res audio files to remote players. And I want to extend Whitebear to support them.

The two most common hi-res audio formats being offerred by media Control Points are FLAC and L24, although WAV and AIF are also sometimes seen. (Side comment: some offerred formats are not natively supported at hi-res by Squeeze players, so in those cases Whitebear acts as a proxy transcoder to deliver hi-res FLAC instead).

My own experience with my own players so far is that they actually can play hi-res FLAC, but that they cannot stream or buffer the incoming data stream fast enough to ensure smooth playback without rebufferng dropouts. At the moment, I don't know if this problem is specific to the actual players that I own, or specific to my actual LAN environment, or if it is a generic problem for Squeeze players. Nor do I know whether there any tweaks that one could make to improve things. Hence my question in this thread.

PS some comments to Pippin: I was surprised that your response was to bite my head off; firstly I am not criticising the Squeeze players; I was just asking a question; and (just so you know) I certainly do not intend to get into any kind of debate about whether anyone can hear the difference between hi-res audio and 44k/16/2.

AndrewFG
2012-11-14, 05:18
You don't say which players you've tried without success.

Transporter, Squeezeplay and Radio...


One thing I've noticed about 24-bit FLAC is that the compression ratios tend to be much worse than their 16-bit counterparts, so that will compound the problem.

Yes. I think there is a reason for this due to the nature of the UPnP HTTP streaming protocols.

When a UPnP media Control Point starts pushing a hi-res stream, it first starts a transcoding process to convert (say) the original source format (say WAV or AIF) to FLAC on the fly, and at the say time it must start pushing the first few bytes of the stream to the player. In other words, it starts pushing the stream before it knows the final length of the stream.

Now the nature of HTTP streaming is that the server must send an HTTP ContentLength header in its first response. But since it does not yet know the final length of the transcoded stream it must therefore offer a guessed value. In the case of FLAC, the easiest guess is ContentLength := Duration x Sample Rate x BytesPerSample x Channels x Compression Ratio. However when transcoding FLAC the Compression Ratio is variable depending on the content. Therefore very often such applications set the FLAC transcoder so it applies zero compression. That way, you can send ContentLength := Duration x Sample Rate x BytesPerSample x Channels x 1.0 at the start of the stream push process...

PS oddly enough, another advantage of zero compression FLACs is that it requires less CPU power in the players to decode and play it. (But obviously the other side of the coin is, as we see here, that it requires more network throughput in the players to fetch the stream in the first place. A classic trade- off...

pippin
2012-11-14, 05:20
Not trying to bite your head off, I'm trying to understand what you want to do.
I'm still confused about whether you are talking about LAN (this works, you probably know that, so I assumed that's not what you were asking about), about using a certain streaming service, then I would wonder who does such a ridiculous thing as wasting tons of expensive bandwidth for streaming with these bandwidth.

Or are you talking about an environment where some private user should stream this stuff over the internet to a remote location and then I stand by my first comment: there is now way this is going to work, Squeezebox or not. Including protocol and stuff you'd probably need a stable 10Mbit of bandwidth for upload, download and all the routing in between and that's simply not how most ISPs work these days. Buffering only helps if you are willing to wait a few minutes before you start the actual playback or if the shortage in bandwidth is only for a very limited time (1s or so) AND you have EXCESS bandwidth for the rest of the time, so you'd even need MORE bandwidth to make it feasible.
But hey, you know all this, you write it yourself.

As of my experience (and I've tried this quite a bit) you will have a hard time getting a stable stream for 44.1/16/flac over normal, end-user internet connections, it fails more often than it succeeds for me and you are asking for more than four times the bandwidth.

It's not going to work.

And I told you what I would recommend to do which is to at least downsample the stream.

EDIT: One more data point: SqueezePlay uses 3MB of buffer, not sure whether that's raw or decoded, so that's about 1.5-3s worth of buffer, not a lot.
Using more in a Squeezebox player will need special consideration, it can cause trouble with some online services, transcoding and syncing so I don't think many of the software players use more. We use 8 MB in iPeng but my experience is that the larger buffer doesn't help a lot for network issues, although all the tests we've done (for remote streaming) were with 44.1/16/flac as a maximum and on a local network there are few situations where buffering actually helps at all.

JJZolx
2012-11-14, 05:37
Yes. I think there is a reason for this due to the nature of the UPnP HTTP streaming protocols.

When a UPnP media Control Point starts pushing a hi-res stream, it first starts a transcoding process to convert (say) the original source format (say WAV or AIF) to FLAC on the fly, and at the say time it must start pushing the first few bytes of the stream to the player. In other words, it starts pushing the stream before it knows the final length of the stream.

Now the nature of HTTP streaming is that the server must send an HTTP ContentLength header in its first response. But since it does not yet know the final length of the transcoded stream it must therefore offer a guessed value. In the case of FLAC, the easiest guess is ContentLength := Duration x Sample Rate x BytesPerSample x Channels x Compression Ratio. However when transcoding FLAC the Compression Ratio is variable depending on the content. Therefore very often such applications set the FLAC transcoder so it applies zero compression. That way, you can send ContentLength := Duration x Sample Rate x BytesPerSample x Channels x 1.0 at the start of the stream push process...

I may not understand the protocols that well, but I don't see what this could have to do with your problem. Obviously the content-length won't be correct, and since I've seen typical 16/44.1 material that can have compression rates anywhere from 20% to 70%, the number can be wildly off. Obviously, it must be unimportant or nothing would work at all.

Doesn't LMS itself use HTTP to stream, and didn't you say that the players have no problems playing the same material streamed by LMS? Have you examined whether or not it's your server that's unable to keep the SB buffers filled?

Mnyb
2012-11-14, 05:46
Did you try a wired player (not wifi ) ?

16vs 24bit flac ,the difference can be natural as the s/n ratio of most recordings are not that great ,then the lowest bits are all pure stochastic noise in 24bit material hence it will not compress very much .

AndrewFG
2012-11-14, 10:28
I may not understand the protocols that well, but I don't see what this could have to do with your problem. Obviously the content-length won't be correct, and since I've seen typical 16/44.1 material that can have compression rates anywhere from 20% to 70%, the number can be wildly off. Obviously, it must be unimportant or nothing would work at all.

Well the number is indeed slightly unimportant (most player's just keep downloading until the server closes the connection). But unfortunately it is not totally unimportant, (it helps the player navigate to the right offset during a time seek operation).


Doesn't LMS itself use HTTP to stream, and didn't you say that the players have no problems playing the same material streamed by LMS? Have you examined whether or not it's your server that's unable to keep the SB buffers filled?

Indeed. Believe me, I am exploring all possible explanations. But just to be clear, it is not "my" server, it could be any one of several third party UPnP Control Point applications who act as the server, whereby my Whitebear application is simply helping to set up the connections...

AndrewFG
2012-11-14, 10:33
Did you try a wired player (not wifi ) ?

Yes. Of course.


16vs 24bit flac ,the difference can be natural as the s/n ratio of most recordings are not that great ,then the lowest bit are all pure stochastic noise in 24bit material hence it will not compress very much.

Brilliant. Good point.

pippin
2012-11-14, 10:34
In a squeezebox system the player would not use the size for a seek operation but the server would tell the player which offset to use, maybe that's the difference.

AndrewFG
2012-11-14, 11:11
I'm still confused about whether you are talking about LAN (this works, you probably know that, so I assumed that's not what you were asking about), about using a certain streaming service, then I would wonder who does such a ridiculous thing as wasting tons of expensive bandwidth for streaming with these bandwidth.

I obviously need to make myself clearer. In my OP I think I used the words "remote stream". I meant this is the same sense that the Logitech developers use: either the player is playing a "local" stream sourced from LMS or it is playing a "remote" stream sourced from another third party server.

In this sense a "remote" stream could either be from a third party server running on the same PC where LMS is running, or from a third party server running on another computer within the LAN, or indeed from a third party server running entirely somewhere else in the cloud. And principally I don't see any difference between these, (apart from the bandwidth issue)


And I told you what I would recommend to do which is to at least downsample the stream.

Yes. Downsampling is the obvious solution if there is no other way to get it to work. But I think it is my applications's duty to avoid removing data from other peoples' streams, wherever I can possibly avoid so doing.


EDIT: One more data point: SqueezePlay uses 3MB of buffer, not sure whether that's raw or decoded, so that's about 1.5-3s worth of buffer, not a lot. Using more in a Squeezebox player will need special consideration, it can cause trouble with some online services, transcoding and syncing so I don't think many of the software players use more. We use 8 MB in iPeng but my experience is that the larger buffer doesn't help a lot for network issues, although all the tests we've done (for remote streaming) were with 44.1/16/flac as a maximum and on a local network there are few situations where buffering actually helps at all.

Thank you for the very interesting insights.

I guess part of SqueezePlay's 3MB buffer must be reserved for receiving the incoming flac, and part has to be reserved for the decoded pcm; so probably the window is even less than 1.5-3 seconds.

This line of thought opens up a new insight (thank you Pippin): I could imagine that if the "remote" server would feed raw pcm to the player rather than flac, then the player could a) devote 100% of its buffer to the pcm (thus giving a longer window), and b) it's CPU would spend less effort on decoding the flac, and therefore (possibly) more effort to the network tasks of downloading the stream itself.

{ the "only" problem with the above approach is that there is no way to get a Squeeze player to accept a raw pcm feed from a "remote" server: the [player_mac_address] playlist add url:http://xyz command won't do it, since one must also inform the player about the bitrate, channel count and depth of the incoming pcm stream. The Squeeze player's raw pcm format does not exactly correspond to any standard audio mime-type, so one would not be able to pass such info in a standard ContentType header; and in any case (therefore) the LMS code base does not have a protocol handler for extracting such ContentType header for such a "remote" raw pcm feed... }

AndrewFG
2012-11-14, 11:21
In a squeezebox system the player would not use the size for a seek operation but the server would tell the player which offset to use, maybe that's the difference.

That is correct.

In the case of a squeezebox system, if the "remote" server does not furnish a ContentLength then LMS cannot determine the track duration, so if the user would click to seek half way along the time duration slider, then LMS has no way to determine what that would mean in terms of a byte offset, and therefore in such cases the seek option is suppressed in the player's or web UI.

Triode
2012-11-14, 13:51
I guess part of SqueezePlay's 3MB buffer must be reserved for receiving the incoming flac, and part has to be reserved for the decoded pcm; so probably the window is even less than 1.5-3 seconds.

Its 3M of compressed stream and then a further 10 seconds at 44.1/16 of uncompress samples post codec, then the hardware buffering. The latter is clearly less when you run at high rates.

I would have expected at least touch to be able to sustain a high bitrate stream as long as there's no packet loss causing TCP congestion. I don't see a problem with cpu load to decompress at the lower compression ratios of flac.

I do think that a "remote" and "local" stream look the same to the player though - there's no difference in the code path taken on the client for a flac stream served from LMS and one served from a web server sat next to it!

For pcm streams which are received without any transcoding, the critical thing is for LMS to tell the player what the bitrate/sample depth is in advance. This means custom protocol handler or LMS connecting to the remote stream to parse the audio stream and then telling the player to connect a second time to actually play it.

Can you explain the scenario a bit more - I'd expect this to work, such that high bandwidth direct stream can be decoded as long as the hardware is able (Touch needs mods to do 192k for instance and its cpu bound if you do high compression flacs)

AndrewFG
2012-11-15, 03:41
For pcm streams which are received without any transcoding, the critical thing is for LMS to tell the player what the bitrate/sample depth is in advance. This means custom protocol handler or LMS connecting to the remote stream to parse the audio stream and then telling the player to connect a second time to actually play it.

Are you able to give me any tips about how I could do this? i.e. what existing HTTP protocol handler methods (or others) would I need to override?

Triode
2012-11-15, 11:44
Are you able to give me any tips about how I could do this? i.e. what existing HTTP protocol handler methods (or others) would I need to override?

My spotify plugin will remote stream pcm (at 44.1), my signal generator plugin will stream raw pcm at up to 96k but that's direct from the protocol handler, however the idea of setting the track parameters is probably still valid.

JJZolx
2012-11-15, 12:00
My spotify plugin will remote stream pcm (at 44.1), my signal generator plugin will stream raw pcm at up to 96k but that's direct from the protocol handler, however the idea of setting the track parameters is probably still valid.

But will this influence the frequency of buffer underruns or lessen CPU load during decoding? Have we been talking about being completely unable to play a hi-res stream, or about dropouts? I assumed it was only the latter.

Triode
2012-11-16, 03:43
But will this influence the frequency of buffer underruns or lessen CPU load during decoding? Have we been talking about being completely unable to play a hi-res stream, or about dropouts? I assumed it was only the latter.

Touch is the only player which can play 192k streams and needs 7.8 if its wav. If the requirement is to stream from another source on the local lan then I don't see why this will be any different from streaming from the LMS - the client code in squeezeplay is the same. Clearly the server will need to be tuned with large max size send buffers etc but I don't see why another server app could not source the stream.

AndrewFG
2012-11-17, 07:03
Touch is the only player which can play 192k streams and needs 7.8 if its wav. If the requirement is to stream from another source on the local lan then I don't see why this will be any different from streaming from the LMS - the client code in squeezeplay is the same. Clearly the server will need to be tuned with large max size send buffers etc but I don't see why another server app could not source the stream.

I have been doing some testing:

Local 96k or 192k Flac Files Served by LMS

- Radio, Squeezeplay: LMS down samples using "flac.exe | sox.exe $resample"; audio intelligible; no buffer stalls
- I suppose ditto for Duet, Squeezebox
- Transporter: LMS just sends the file; audio is intelligible; no buffer stalls;
- I suppose ditto for Touch

Remote 96k or 192k Flac Streams Served by a 3rd Party Server

- Radio, Squeezeplay: Audio intelligible; but there are frequent buffer stalls
- Using direct streaming or indirect (proxy via LMS) makes no difference
- Transporter: At 96k the audio is intelligible; no buffer stalls; but at 192k the output is white noise

I don't have a Touch so cannot test it.

Conclusions:

1) Apparently the newer players have DACs that can handle hi-res audio, but they don't have the buffer capacity for it

2) One oddity is that Transporter can play a 192k Flac served by LMS but it outputs white noise on a 192k Flac from a 3rd party server

Triode
2012-11-17, 07:17
I have been doing some testing:

Local 96k or 192k Flac Files Served by LMS

- Radio, Squeezeplay: LMS down samples using "flac.exe | sox.exe $resample"; audio intelligible; no buffer stalls
- I suppose ditto for Duet, Squeezebox
- Transporter: LMS just sends the file; audio is intelligible; no buffer stalls;
- I suppose ditto for Touch

Remote 96k or 192k Flac Streams Served by a 3rd Party Server

- Radio, Squeezeplay: Audio intelligible; but there are frequent buffer stalls
- Using direct streaming or indirect (proxy via LMS) makes no difference
- Transporter: At 96k the audio is intelligible; no buffer stalls; but at 192k the output is white noise

I don't have a Touch so cannot test it.

Conclusions:

1) Apparently the newer players have DACs that can handle hi-res audio, but they don't have the buffer capacity for it

2) One oddity is that Transporter can play a 192k Flac served by LMS but it outputs white noise on a 192k Flac from a 3rd party server

Be careful - the standard Touch kernel only supports 96k sample rates with the built in devices - you will need the EDO kernel for 192k and then only on spdif/usb, the built in analog won't work. I very much doubt you will really get above 96k though with the other devices as there's no kernel driver support for them. The alsa layer can do resampling, but I suspect this will result in lots of cpu load and no real benefit.

You should could test against squeezeplay or squeezelite on linux for 192k support - I would expect this to work with your server as long as the send buffer is large enough in your server - the clients will wake approx once every 100ms if starved of data, so you want to make sure your server can maintain a streaming rate.

Edit - I should add that none of the Logitech devices are spec'd to work at 192k. The only one which has some support of it is Touch with my third party EDO kernel and then only for some output devices. So if you are targetting real devices then I would avoid 192k. All other devices support this by using the server to downsample.

Mnyb
2012-11-17, 12:15
I have been doing some testing:

Local 96k or 192k Flac Files Served by LMS

- Radio, Squeezeplay: LMS down samples using "flac.exe | sox.exe $resample"; audio intelligible; no buffer stalls
- I suppose ditto for Duet, Squeezebox
- Transporter: LMS just sends the file; audio is intelligible; no buffer stalls;
- I suppose ditto for Touch

I don't have a Touch so cannot test it.


2) One oddity is that Transporter can play a 192k Flac served by LMS but it outputs white noise on a 192k Flac from a 3rd party server

Note LMS transcodes 192 to 96 for both Touch and Transporter no Squeezebox do 192k natively per default .

So transporter is playing 192k by transcoding to 96k in LMS .

The Touch can be tricked to do that by Triodes suite of small apps and hacks ,but for a general purpose solution for your whitebear I think you should try to invoke the standard transcodings for each player .

Can the stream be proxied trough LMS so it's normal logic can work as designed ? Would this enable a Triode EDO enhanced Touch to actually get 192k as LMS will know of this capability .
Sounds like you into getting a Touch on Ebay to load EDO on if you want to pursue and test this ?

Wonder if squeezelite on a suitable linux computer will give you a true 192k squeezebox to try with ?

wt0
2012-11-26, 23:40
EDIT: One more data point: SqueezePlay uses 3MB of buffer, not sure whether that's raw or decoded, so that's about 1.5-3s worth of buffer, not a lot.
Using more in a Squeezebox player will need special consideration, it can cause trouble with some online services, transcoding and syncing so I don't think many of the software players use more. We use 8 MB in iPeng but my experience is that the larger buffer doesn't help a lot for network issues, although all the tests we've done (for remote streaming) were with 44.1/16/flac as a maximum and on a local network there are few situations where buffering actually helps at all.

The status messages that the players send back to the servers actually reports info (size and fullness) for two separate buffers, one for input/network data and one for output audio. For the SB Boom, both buffers are about 3Mb each. If you capture the packets between the Boom and server you can see that the fullness of the two buffers change independently, so the two numbers do not represent the same buffer. Now I don't know exactly how SqueezePlay works, but it is logical that it would emulate a hardware player and have two buffers also.

ScottMDJ
2012-12-08, 12:07
Sorry to bump this thread but can I assume from this that Whitebear will soon be getting support for 24/96 files? Perhaps I set things up wrongly but HD files always downsample for me. If an upgrade is in the future that would be very good news indeed.

toby10
2012-12-09, 05:35
Which player are you using? LMS (via WhiteBear) will downsample to whatever the player is capable of.

ScottMDJ
2012-12-09, 09:50
Which player are you using? LMS (via WhiteBear) will downsample to whatever the player is capable of.

I'm using LMS Squeezebox. I can get larger files (up to 24/192 and SACD ISOs) to play if I select "Convert unsupported formats" but the conversion goes right past 24/96 (LSM's limit) to CD quality. With the setting of "Never convert" I can play most files of 24/96, but anything higher and I get some serious stutters. That happens with some 24/96files too, and in this setting, SACD ISOs aren't recognized at all. Setting delays, play from memory, etc. hasn't improved the situation.

If I'm doing something wrong I'd greatly appreciate any advice. I should mention that I never deleted the LSM DLNA plug-in since I can't find it. Again, if my situation is a result of doing something wrong, I'd love to hear about it.

toby10
2012-12-09, 11:23
Still don't know what SqueezeBox player model you are using. LMS is limited to 24/96, the Touch hardware player can pass 24/192 to an external DAC under certain conditions.

ScottMDJ
2012-12-09, 11:48
Is this what you mean?

Player Model: Squeezebox Touch
Firmware: 7.7.2-r9663

I'd be very grateful for any help getting higher resolution files to play on JRiver through Whitebear to the SB Touch.

garym
2012-12-09, 13:33
Is this what you mean?

Player Model: Squeezebox Touch
Firmware: 7.7.2-r9663

I'd be very grateful for any help getting higher resolution files to play on JRiver through Whitebear to the SB Touch.

Can't speak to the JRiver or Whitebear, but the touch can play 24/96 files natively, but 24/192 files ONLY if Triodes applet "EDO" is installed on the Touch (and the TOUCH is playing to an external DAC that will work with 24/192)

toby10
2012-12-09, 14:34
Is this what you mean?

Player Model: Squeezebox Touch
Firmware: 7.7.2-r9663

I'd be very grateful for any help getting higher resolution files to play on JRiver through Whitebear to the SB Touch.

Yes, Touch is the player model, there are nine different hardware players plus various software players.
Touch cannot play 24/192, it can only play up to 24/96. It can pass 24/192 under certain conditions and only if outputing (digital or USB) to a DAC capable of 24/192.

ScottMDJ
2012-12-09, 15:17
Thanks for the feedback. I have the original DacMagic which accepts only 24/96, so EDO doesn't work for me. It does make me wish I had a better Dac so I could try it out!

I have no problem playing files over 24/96 on the Touch. My problem is I'm trying to use JRiver as a front end, through Whitebear, to the Touch. Of course, LMS on its own downsamples larger files to 24/96. My problem going through Whitebear is those 176, 192, and 196 sample rates have stuttering playback. If I use the "convert" option, the files are downsampled too much. I'm sorry if I'm hijacking this thread but I'd love to discover I'm doing something wrong.

toby10
2012-12-09, 16:28
I guess I'm not understanding what the problem is. Your player and external DAC are not capable of playing your 24/192 files natively.
And when these are files are played they are successfully down sampled to 24/96 and play fine. Correct?

I highly doubt you would hear any discernible difference between 192 and 96, down-sampled or not. Seems you are over complicating a problem that doesn't exist on hardware not capable of playing 192, all to hear likely no difference when properly played at 96. If I'm understanding you issue. ;)

garym
2012-12-09, 16:49
I guess I'm not understanding what the problem is. Your player and external DAC are not capable of playing your 24/192 files natively.
And when these are files are played they are successfully down sampled to 24/96 and play fine. Correct?

I highly doubt you would hear any discernible difference between 192 and 96, down-sampled or not. Seems you are over complicating a problem that doesn't exist on hardware not capable of playing 192, all to hear likely no difference when properly played at 96. If I'm understanding you issue. ;)

agree about the 192 vs 96 (no human being can hear any difference there unless the difference is caused by different underlying master recordings, i.e., unrelated to the 44.1 vs 96 vs 192)

But unrelated to this, his problem seems to be that when there is downconverting there seems to be a lot of buffering and stuttering if I have this right. This makes me think that the server doing the downconversion may not be powerful enough when used with Jriver and whitebear. I don't use either of these so I'm no help with that. I suspect the OP might be better posting in the whitebear thread where the author of that may be of some help.

ScottMDJ
2012-12-09, 16:53
The squeezebox on its own successfully down converts higher sample rates to 24/96, and I have no problems. The JRiver-Whitebear-squeezebox combination, on the other hand, has considerable problems with the larger files: they stutter to the point of being unplayable. As I said, I can tell JRiver to convert the file but it then converts everything all the way down to 48hz. I can't figure out how to get it to convert the large files only to 96, and yes, I've tried the DSP studio settings.

I'm skeptical that the highest sample rates will make a difference, but I'd want the files to be at least playable. BTW, I'd like to use JRiver for the tagging and SACD ISO playback, but the combination isn't working for me.

garym
2012-12-09, 17:31
The squeezebox on its own successfully down converts higher sample rates to 24/96, and I have no problems. The JRiver-Whitebear-squeezebox combination, on the other hand, has considerable problems with the larger files: they stutter to the point of being unplayable. As I said, I can tell JRiver to convert the file but it then converts everything all the way down to 48hz. I can't figure out how to get it to convert the large files only to 96, and yes, I've tried the DSP studio settings.

I'm skeptical that the highest sample rates will make a difference, but I'd want the files to be at least playable. BTW, I'd like to use JRiver for the tagging and SACD ISO playback, but the combination isn't working for me.

agree that playing them ought to at least be seamless. But sorry, no help on the jriver combo, although the problem is obviously something in that and not the TOUCH itself.

toby10
2012-12-10, 03:19
Probably best to try a J River forum as that is where the problem lies, good luck. :)

bpa
2012-12-10, 03:45
Stutter can be caused either by CPU or Network overload. Assuming CPU load on the server has been checked and found to be low.
Could it be a network problem ? Perhaps when LMS downsamples direct to Touch it plays as Flac but when using JRiver/Whitebear it is sent as PCM ?

ScottMDJ
2012-12-10, 12:21
Thanks to everyone who took the time to try to help. My initial query was in this thread since AndrewFG started it off describing his experiments in higher resolutions. I suppose I'll have to wait for newer versions of Whitebear. It's a great app, just not yet ready for the highest resolution files. In any case, perhaps this thread can stand as a reference for people who have had the same issue. I have no doubt the smart people working on the issue will get it all sorted out eventually. Thanks again.