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
