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 [email protected] http://lists.slimdevices.com/mailman/listinfo/discuss
