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: http://forums.slimdevices.
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 Profi
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
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 capabi
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
does
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 o
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 mu
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: http://forums.slimdevices.com/member.php
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 ban
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 t
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
unco
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 dire
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 bu
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 stream
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. Cle
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
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
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, trans
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.
-
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: http://forums.slimdevices.com/
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'
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: http://forums.slimdevices.com/m
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: http:/
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
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
pla
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 Whi
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
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
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
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: http://forums.slimdevices.com/showthread.php?t
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 f
41 matches
Mail list logo