Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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. ScottMDJ's Profile: http://forums.slimdevices.com/member.php?userid=58401 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 ? bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 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. garym's Profile: http://forums.slimdevices.com/member.php?userid=17325 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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. ScottMDJ's Profile: http://forums.slimdevices.com/member.php?userid=58401 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 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. garym's Profile: http://forums.slimdevices.com/member.php?userid=17325 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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. ;) toby10's Profile: http://forums.slimdevices.com/member.php?userid=12553 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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. ScottMDJ's Profile: http://forums.slimdevices.com/member.php?userid=58401 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 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. toby10's Profile: http://forums.slimdevices.com/member.php?userid=12553 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 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) garym's Profile: http://forums.slimdevices.com/member.php?userid=17325 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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://forums.slimdevices.com/member.php?userid=58401 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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/member.php?userid=12553 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 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. ScottMDJ's Profile: http://forums.slimdevices.com/member.php?userid=58401 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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. ScottMDJ's Profile: http://forums.slimdevices.com/member.php?userid=58401 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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, 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. wt0's Profile: http://forums.slimdevices.com/member.php?userid=18760 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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; 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 ? Mnyb's Profile: http://forums.slimdevices.com/member.php?userid=4143 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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; 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. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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. 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 research: 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 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: A 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 AndrewFG's Profile: http://forums.slimdevices.com/member.php?userid=15838 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 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. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 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. JJZolx's Profile: http://forums.slimdevices.com/member.php?userid=10 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 from the protocol handler, however the idea of setting the track parameters is probably still valid. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote 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 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? AndrewFG's Profile: http://forums.slimdevices.com/member.php?userid=15838 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 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) Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 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. AndrewFG's Profile: http://forums.slimdevices.com/member.php?userid=15838 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 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 either 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) pippin wrote: > 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. 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, > 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 wold 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's Profile: http://forums.slimdevices.com/member.php?userid=15838 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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?userid=13777 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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. Brilliant. Good point. AndrewFG's Profile: http://forums.slimdevices.com/member.php?userid=15838 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 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 loses the connection). But unfortunately it is not *totally* unimportant, (it helps the player navigate to the right offset during a time seek operation). JJZolx wrote: > 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... AndrewFG's Profile: http://forums.slimdevices.com/member.php?userid=15838 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 . Mnyb's Profile: http://forums.slimdevices.com/member.php?userid=4143 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 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 pipe filled? JJZolx's Profile: http://forums.slimdevices.com/member.php?userid=10 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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. pippin's Profile: http://forums.slimdevices.com/member.php?userid=13777 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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. 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... AndrewFG's Profile: http://forums.slimdevices.com/member.php?userid=15838 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 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. AndrewFG's Profile: http://forums.slimdevices.com/member.php?userid=15838 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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. JJZolx's Profile: http://forums.slimdevices.com/member.php?userid=10 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 a waste of bandwidth, downsample it to something sensible, say 48 kHz and you will be fine. pippin's Profile: http://forums.slimdevices.com/member.php?userid=13777 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 . Mnyb's Profile: http://forums.slimdevices.com/member.php?userid=4143 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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. MrC's Profile: http://forums.slimdevices.com/member.php?userid=468 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 Profile: http://forums.slimdevices.com/member.php?userid=13777 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
[slim] Do any Squeezeplayers actually have the horsepower to play 192/24 remote streams?
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? AndrewFG's Profile: http://forums.slimdevices.com/member.php?userid=15838 View this thread: http://forums.slimdevices.com/showthread.php?t=97244 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss