Bugzilla – Bug 3695
Use lower bitrate limit as default for streaming clients
Last modified: 2011-12-04 03:20:28 UTC
I just added a comment to bug 726 regarding default preferences for new players. I realize that new preference settings often meet with resistance, so I'm filing this request to address the most important issue. It's easy to have many new remote software players coming online. The default audio setting is to use no bitrate limiting for new players. If you have your library in flac, this means that the streamed format will remain flac, which not many home internet connections can handle. When a new player connects, it forces you to connect, then edit the streaming rate, then restart the stream in order for it to be usable. I'd like to have this behavior changed to use a "reasonably low" bitrate for any new *software* player that SlimServer sees. I'd say 128 kbps or possibly 96 kbps would be a reasonable streaming rate that could be handled well by outgoing home connections. As mentioned in bug 726, this behavior wouldn't be desirable for new *hardware* players, since users would be forced to change the setting when adding a new Squeezebox to their network, otherwise would be streaming lossless formats as mp3.
Two types of software players: Softsqueeze - default bitrate is no limit http streaming clients - winamp, iTunes, WMP etc that make use of stream.mp3, default bitrate is 320 since these are only given support for an mp3 formatted stream. One way to easily handle http clients is to set limit to 128 regardless of location. It isn't the primary goal of slismerver anyway, and if users want to use software players of varying (sometimes dubious) audio quality, then audio quality on the connection shouldn't be as important as proving that slimserver can actually stream the music. If they want audio quality, they can get the hardware :)
See also bug 249
Dean, could we get a ruling on this one? I'm assuming it would be pretty easy to implement using 128kpbs instead of 320kpbs by default for new clients connecting to stream.mp3. Forget SoftSqueeze clients - they can stay unlimited. It might be nice to have a pref (in prefs file only - no user interface in settings) to set the default bitrate, but it's not completely necessary. The key thing is to use a 'safe' bitrate so that new streaming clients are less likely to get dropouts.
ping dean
the reason I picked 320 for the silent part is that there is often a long lag between when you hit play and the buffer in the player runs out and you actually hear the audio. I think it would be fine to change to 128 (or whatever) after some testing with the popular streaming clients (itunes, winamp, xmms, etc...) and making sure that it's not too confusing/broken. as far as the default transcoding rate, 128k is fine by me, but note that for MP3 files, there will be no transcoding by default, which seems right to me (and often necessary if LAME isn't installed.)
(In reply to comment #5) > note that for MP3 files, there will be no transcoding by default, > which seems right to me (and often necessary if LAME isn't installed.) That's good to remember. I'm wondering, though, can the following be accomplished, given the current server and player settings: Say someone has a predominantly mp3 collection. They wish to stream to remote clients using a low bit rate, due to upstream connection speed issues, but for local network players they don't want any transcoding of their mp3 library.
bitrate limiting controls that. If the mp3 is detected at higher than the player's set limit, then it will be transcoded. What Dean was saying referes to the limit of 320. At that point, any mp3 will be played at it's native rate. They do not get transcoded up, or to their exting rate. only down when required.
Hey guys, can we take another look at this now that 6.5 has been released? If 6.5.1 is close, perhaps for 6.5.2 or whatever is next. Thanks.
removing target so QA can re-validate this issue per comment #8
Targeting Enhancement bugs
I just got schooled in bug #27 (https://bugs-archive.lyrion.org/show_bug.cgi?id=27). Is a default required when you can already specify the bitrate in the URL, i.e. (http://slimserver:9000/stream.mp3?bitrate=32)?
Dean doesn't work here any more :)
Unassigned bugs cannot have a priority.
Closing. This becomes less important as connection speeds continue to increase.