Probably best to try a J River forum as that is where the problem lies,
good luck. :)
toby10's Profile: http://forums.slimdevices.com/member.php?userid=12553
View this thread:
Stutter is generally caused either by CPU or Network. 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
?
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
Which player are you using? LMS (via WhiteBear) will downsample to
whatever the player is capable of.
toby10's Profile: http://forums.slimdevices.com/member.php?userid=12553
View this thread:
toby10 wrote:
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
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.
toby10's Profile:
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.
ScottMDJ's Profile:
ScottMDJ wrote:
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
ScottMDJ wrote:
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
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
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
toby10 wrote:
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
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
ScottMDJ wrote:
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
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.
pippin wrote:
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,
Triode wrote:
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.
AndrewFG wrote:
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;
AndrewFG wrote:
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;
JJZolx wrote:
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
Triode wrote:
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
AndrewFG wrote:
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
Triode wrote:
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
MrC wrote:
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
JJZolx wrote:
You don't say which players you've tried without success.
Transporter, Squeezeplay and Radio...
JJZolx wrote:
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.
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
AndrewFG wrote:
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
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 bit are all pure
stochastic noise in 24bit material hence it will not compress very much
.
JJZolx wrote:
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
Mnyb wrote:
Did you try a wired player (not wifi ) ?
Yes. Of course.
Mnyb wrote:
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.
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.
pippin's Profile:
pippin wrote:
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
pippin wrote:
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
AndrewFG wrote:
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
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
What on earth should that be good for?
pippin's Profile: http://forums.slimdevices.com/member.php?userid=13777
View this thread: http://forums.slimdevices.com/showthread.php?t=97244
pippin wrote:
What on earth should that be good for?
Sorry Pippin but I don't understand your point.
AndrewFG's Profile: http://forums.slimdevices.com/member.php?userid=15838
View this thread:
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?
pippin's
pippin wrote:
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.
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 wrote:
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
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
42 matches
Mail list logo
