Problems streaming to Icecast from Slimserver

[relen]

I am attempting to use a streaming server provider to set up a stream relay to take a stream from my Slimserver and distribute it (eg in Second Life), thus making it available to general listeners.

Icecast makes the most sense as it can relay a stream of the form http://hostname:9000/stream.mp3. The icecast server accesses the stream and appears as a player in the web interface, from which I can send it a stream generated from a playlist.

I have been working with two different providers (Stream Solutions and SLServer) and both have run into the same issue, which is that listening to the icecast URL, the stream drops out after about 30-60 secs. Clicking Play on a player tuned to the icecast stream provides another 30-60 second segment.

Our first thought was that there were bandwidth issues. The Icecast server appeared to be complaining that the SS was not keeping up.

However I confirmed that my broadband uplink will support at least two concurrent 128kbps streams, listening to similar streams direct in two players in different countries simultaneously. I can also listen uninterrupted to one 320kbps stream plus a second 64kbps stream simultaneously.

Most of my library is in FLAC so SS is presumably using LAME to transcode the stream in realtime. However there is no change in the problem if I play an MP3 source file instead.

Changing the data rate limit in the player settings page has no effect, even going as low as 64kbps although the audio quality deteriorates.

Metadata is relayed correctly.

Listening to the icecast URL with a player provides the following interesting observation: when the stream drops out, pressing play again the stream restarts at once, however the audio heard appears to be at least a minute or two later than one would expect. For example, if I start listening to a 2-minute track, the stream drops out after a minute, but if I immmediately press Play again, the stream restarts near the end of the track, ie a minute has gone missing somewhere.

I am wondering if something is effectively "running too fast", eg perhaps the icecast server is underrunning its buffer because it is actually clocking the data out at twice the speed it should ... however I do not know the ins and out of shoutcast and in addition all the audio sounds at the correct speed etc.

My suspicion is that there is a config mismatch between Slimserver and icecast. Anyone any ideas?

I also need to know how to change the "Welcome to Slimserver" message in the stream ID.

Thanks in advance!

--Richard E

[slutz]

Hi,

I have no idea about Icecast but the welcome messages are in file strings.txt starting at line 1463 (for version 6.5.2).

-slutz

[caolas]

I tried to relay through icecast too, without success. It was a while ago but I seem to remember giving up after reading a post somewhere that explained that slimserver doesn't really stream in the normal sense. It offers some kind of gradual download of each track, the speed of which is regulated by how it communicates with the player. (Sorry - I don't recall the details.)

What I found with icecast was that after setting up a player, an icecast relay and starting the Slimserver 'stream', there would be a few seconds of massively speeded up sound, and then silence - so it seemed as if the download speed wasn't regulated properly, and icecast was relaying the track just as fast as Slimserver could deliver it, which was many times normal playback speed.

I've had more success with VLC, however. See this other thread: http://forums.slimdevices.com/showthread.php?p=205409. VLC doesn't relay metadata though.

Caolas

[relen]

Interesting - I'll check the thread. Meanwhile I was also wondering if ices would help - http://www.icecast.org/docs/ices-2.0.0/

[relen]

Mystery bitrates in stream.mp3

Here is one reason that Icecast may be having trouble dealing with an mp3 stream from Slimserver: the bitrate.

I imagine the bitrate LIMIT set in the player settings to be the maximum data rate that an mp3 file would be streamed at: a file with a higher bitrate will be geared down to the limit by LAME while a file with a lower bitrate will be passed unaffected. This means that the mp3 stream being relayed could have different data rates according to the track being played. I doubt that Icecast likes that idea much.

Secondly, I ASSUMED that a non-mp3 file would be transcoded by LAME at the data rate specified in the limit. Is this the case? I am not entirely sure.

Comments? Observations? All welcome.
--Richard E

[Mark Lanctot]

Secondly, I ASSUMED that a non-mp3 file would be transcoded by LAME at the data rate specified in the limit. Is this the case? I am not entirely sure.

Yes, but you must have the appropriate codecs and it must be specified in SlimServer Server Settings - File Types.

[relen]

Successful streaming from SlimServer to Icecast and other devices

Thanks to Caolas for putting me on a useful track with this. I am now successfully streaming from my SlimServer to a remote Icecast server configured as a stream relay.

However, there are some aspects which make this approach rather problematical and a different, though Un*x-only, solution is provided in a separate article, using MuSE. For details, see this post: http://forums.slimdevices.com/showpo...59&postcount=8

Here's the basic config:

I'm using VLC to play the mp3 stream from SlimServer and then use VLC's streaming capability to send a stream to the remote Icecast device. This provides a stream of a known data rate (with a caveat - see below) to the remote relay and thus solves the problem of weird timing data being misinterpreted by the remote device.

VLC appears as a player in the SS web interface and I'm sending a 320kbps stream to it.

To make the stream as easy as possible to handle at the other end I am streaming from VLC using HTTP. This requires setting the Preferences in VLC to enable this output module. Prefs->(check Advanced Options)->Stream Output->Access Output->Access Output Module "HTTP Stream Output".

Then open File->Open Network Stream. Check the Advanced Options Stream/Save box at the bottom and enter the URL of your SlimServer stream - "http://yourhostip:9000/stream.mp3". I am running VLS on the server machine (Linux FC6) but VLC can actually be on any machine that can access the stream. I found that despite VLC running on the same machine as the server I could not use "localhost" and had to enter the IP address.

Now click Settings in Advanced Options (next to Stream/Save). Check Play Locally if you want to be able to listen to VLC's output directly to check it's what it should be. Also check the HTTP box and choose a port number. I'm using 8090 (be sure that you have a hole in your firewall to let this port # through).

If you leave the Address box blank, you can receive the VLC stream on any destination machine. This is not a good idea as about 5 listeners will occupy all your bandwidth. So put the address of the relay server in here as soon as you have it working. However you can use the same system to stream a single program to players all over your OWN network without it going outside using this capability, so if that's what you want to do, feel free.

Under Encpasulation Method, check "Raw". I'm streaming primarily into Second Life: other encapsulation methods work with other players (VLC on another machine will take almost anything you give it) but for me the Icecast relay only worked with Raw checked.

Under transcoding options, check Audio Codec and set the format to mp3. Again no doubt other streams will work but I wanted to start simple. My relay gives me up to 128kbps so I have the Bitrate set to 128 and 2 channels.

OK the Stream Output dialog and OK the Open... box under it.

Now, assuming that you are actually playing something from SlimServer to the VLC address, you should see the timer in the bottom left of the VLC window incrementing and the track name in the right-hand section. If you checked Play Locally earlier you can listen to the sound card of this machine and check that you can hear what VLC is streaming.

You should have a stream coming from http://yourexternalip:8090 at this point, where "yourexternalip" is the IP address that your VLC machine appears to be on to the outside world - for example you may be using port forwarding to make port 8090 (for example) visible to the world at large: in this case "yourexternalip" will be the external address of your router and you can check that in a number of ways. On another machine you should be able to run up a player and put that URL into it and hear the outgoing stream from VLC.

At the relay server end your provider or whomever needs to plug this stream data into the Icecast server settings, configured as a stream relay. Given the Icecast stream output address, you should be able to plug this into a player and listen to it on your machine. More importantly, in my case, you should be able to set the media access URL of your land in Second Life to this address and all visitors to your club or whatever will be able to hear the stream.

I am currently using this system for DJing in SL (first session at the London Trance Club in Mephit last night) and I was driving SS by building a playlist on the fly, prefading tracks to add to the playlist by running an additional software player. There are drawbacks with this approach, notably lack of crossfade capability.

Caveats.

You have to watch a couple of things. The big one is that you do not want the outgoing stream to change its bitrate. It unfortunately WILL change its bitrate if you play something that has a lower bitrate than the bitrate limit set for that player in SS. This is not usually a problem for me as almost all my server files are in FLAC. However I have a few files that were downloaded mp3s at lower rates. If you play one of these and they are lower than the limit, VLC will output them all right, but the Icecast server will be completely confused and the track will come out of remote players at some rather faster than normal speed. You can resync the stream but then everyone would have to press stop/play and this will of course not happen so they'll get dead air.

What I really need, to be able to solve that, is to be able to generate a stream from SS that isn't LIMITED to a max bitrate but is SET to a bitrate irrespective of the source file being played. Anyone with an idea how to do this please let me know. One would have thought that LAME was entirely capable of doing such a "gearbox" operation, if only we can tell it to do so.

A big problem, however, is what happens when you try to password protect the server - which you probably want to do, otherwise at the very least people can access the source stream directly and suck your bandwidth (they can also, should they work it out, mess with what your players are playing). If you password protect the server, the thing that happens almost immediately (eg if you restart the stream) is that VLC stops relaying the incoming stream. Not only that, you can't get it back - even after you unprotect the server, restart server and VLC, or even restart the server machine. Having run round in circles for several hours checking and rechecking all the settings in VLC to no avail (have the stream info window open so you can see what the streaming output thinks it's doing), I discovered that I simply couldn't use my original port number any more. Virtually anything else would do, but not the one I had used originally. Having restored the system, trying to password protect the server again resulted in the same thing happening: I lost the use of a port for streaming. This is obviously ridiculous and I wish I knew what was going on. Any suggestions welcome.

The workaround is to limit the IP addresses via which the server can be accessed to the streaming relay and whatever location you access the server from to control the content and the addresses or address block of your home players.

Less seriously....

Another point is that I notice that the Icecast output is about 3dB down on the stream leaving VLC. Anyone any observations about this?

In addition I want to be able to insert some realtime audio DSP in the path (eg compression and level change). Ideas?

I hope this information is useful to anyone else trying the same thing.

[relen]

Streaming SlimServer to Icecast - the MuSE approach

Having documented attempts to use VLC as a method of streaming SlimServer output to an Icecast streaming server and encountering some severe difficulties concerning password-protecting the Slimserver without terminally breaking the stream, I looked for another method of achieving the same goal, namely to make content played out of a Slimserver accessible to a large number of people by relaying it via an external server such as that offered by streaming server providers. My main intent was to make the Slimserver stream accessible to residents of Second Life, for example to perform DJ sessions at clubs in-world, but of course the stream can be listened to with any player that can decode an Icecast stream.

The challenge is that while Slimserver can generate an mp3 stream that can be played on a regular software player (typically http://slimserver-ip:9000/stream.mp3), the stream has some unusual characteristics that make it impossible to relay it direct with an Icecast server: it drops out after 30-60 seconds.

The solution is to play the stream with something and then stream from that. The clunky solution would be to run a player and then capture the soundcard output to stream to the remote server, with something like Simplecast. A nicer solution would be to use an application that does the playing and grabbing for you.

MuSE (Multiple Streaming Engine) from http://muse.dyne.org/ does this. And instead of using the Icecast server in relay mode (where the Icecast server receives the stream and relays it), as with the VLC solution documented elsewhere, MuSE pushes a stream conventionally to Icecast. This can be important as some streaming server providers do not give you the ability to control the stream relaying mode and configuration: this means that if you want to stream from different places with different IP addresses, you can’t access the settings and have to ask for the provider to change them for you - annoying and inconvenient.

Note
====

There are some caveats:

First, MuSe is only available for Mac and Linux systems at present.

Second, as with the VLC technique, don't play a file on Slimserver which has a data rate that is less than the maximum bitrate defined in the Player Settings for the player being used by MuSE. In this case it will play the file in garbled form at high speed and may crash. The solution required for this is for the mp3 stream supplied to a player by Slimserver to be able to have a defined bitrate, rather than a defined MAXIMUM bitrate - perhaps the Slimserver developer community can look into this.

And finally, it turns out that you still can't password protect Slimserver. Password protecting the server stops MuSE from receiving the stream, and the normal "userassword@http://...." format doesn't seem to work. The workaround is to restrict server access using the IP address ranges.

Basic MuSE configuration
========================

Start by opening a terminal window and launching the app by typing "muse". This gives you a lot of status information which you will find useful.

There are two sides of MuSE to set up, and the tutorial at http://muse.dyne.org/?open=tutorial is helpful for this - though little of the rest of the docs are, if you can find them. You need to configure the streaming settings and you need to configure MuSE to play the Slimserver mp3 stream.

Configure the streaming settings by:
a. Setting the parameters for the output stream such as quality, number of channels, digital word length (aka ‘bitrate’, which is ambiguous in this context) and sample rate.
b. Entering the Icecast server details given by your provider. These will include the host/server IP or hostname; port; mountpoint and some stream info to be displayed remotely.

Defining the output stream
==========================

Access the stream output dialog by pressing the plug-socket button in the MuSE interface, top left to bring up the Add Server dialog. I have not yet got the Ogg/Vorbis streaming setup to work with Icecast so I will assume instead that we’ll use LAME to generate an MP3 stream - click the ‘Lame Streaming (MP3)’ tab.

The upper half of the dialog defines the parameters of the stream to be fed to the remote server. Many streaming server providers will give you up to 128kb/s so there is no need to configure the streaming data for faster than that. Indeed, 96kb/s is fine for many applications. Drag the Quality slider up until you get the value you want. You probably want to set the mode to stereo unless you are streaming old 78s. A ‘bitrate’ (word length) of 16 bits is the same as CD and fine for streaming audio at this kind of data rate. 44100 Hz sample frequency is also CD quality and probably a good idea - but set the ‘bitrate’, ‘frequency’ and ‘quality’ to give you a good balance of audio quality versus bandwidth.

You can also highpass and lowpass filter the audio to minimise artefacts and optimise the stream. You may find the ‘auto’ works fine.

A Profile button allows you to save your settings here so you don’t have to type everything in again when MuSE crashes (for example).

Entering the Icecast server details
===================================

The lower half of the dialog allows you to enter the remote server data as supplied by your server provider. Enter the hostname or IP address, port number, mount point (of the form “/name” - “/live” is typical and the default), and give your stream a name and description. The space for a URL is also provided - this will appear, for example, in iTunes and ought to go somewhere useful. Also set up the login info by selecting the type of login and the password as supplied.

Again you can save a profile here. Clicking ‘Connect’ will cause MuSE to attempt to stream to the remote server. You will see a message telling you it has done so.

Note that you may need to ensure that there is a suitable hole in your firewall to allow this access. However in many cases, as you are actually ‘pushing’ the data to the remote server, you may not have to worry.

Playing the Slimserver stream
=============================

Now let’s play the stream from your Slimserver. Note that Slimserver and MuSE do not have to be on the same machine.

The second button from the left in the MuSE interface - a document with a jigsaw piece or something on it - brings up a Channel window. If you already have Channel 1 open you don’t need to click it again. Right-click in the channel window’s white area and choose URL. In the resulting box, enter something of the form ‘http://slimserverip:9000/stream.mp3’ where ‘slimserverip is the IP address of, you guessed it, your Slimserver machine.

You can actually build complete playlists here, by the way, by loading files direct from your music library - and by having, say, two channels open you can fade one up and another down and essentially not use Slimserver at all.

Make sure that you select “Continuous” in the button bottom-right of the window. Double-clicking on the item in the list will play it, or you can select it and click the play button above the window.

Clicking play will cause the player section of MuSe to connect to your Slimserver and in the Slimserver web interface you will see a Player with the IP address of your MuSe machine. You can rename this in Server Settings for this player. You can also check the maximum bitrate for the stream - I have almost all FLAC files in my library so the maximum bitrate will define what rate LAME converts these to mp3 and streams them out to MuSE. See caveat above.

Final touches
=============

If you want to listen to the output on the MuSE machine, click the loudspeaker button in the MuSE interface. Note that there is also a Microphone button here, and this allows you to bring in audio from your sound card if you want to make announcements over your stream.

In addition, as you can bring in audio from your sound card or audio interface here, you can alternatively bring in a live mix from your mixing console (or even simply different soundcard/audio interface inputs) and thus stream a live act... And indeed, as mentioned above, you don’t actually need Slimserver if the MuSe player will play back files from your library directly and you don’t want access to Slimserver’s comprehensive search and playlist-management capabilities. But these are not the purpose oif this document.

Clicking the little bargraph button brings up a couple of speed dials - regrettably not actual bargraph VU meters - one giving you the volume level and the other the data rate of the outgoing stream - useful for checking things are actually working. If your volume dial is wiggling, you’re sending audio; if the data rate dial is reading something, you’re streaming it.

You should now be on the air. Logging into your Icecast server address with a web browser will show you that there is actually a stream there and you can listen to it.

If you are streaming into Second Life (which is what I wanted this setup to do) then you can plug the Icecast server address into the media access URL for the land or give the URL to your venue manager. It will be of the form ‘http://icecast-iport/mount’ where ‘icecast-ip’ is the hostname or IP address of the Icecast server; ‘port’ is the port number supplied by your provider; and ‘mount’ is the mountpoint similarly provided.

Server provision for Second Life
================================

Looking for an affordable, supportive and efficient server provider specialising in streaming into Second Life? I recommend a Streaming Live Audio Server from Jamie Otis. Find him in Search, bring up his profile, and check his Picks for the location of his in-world store where you can order a server and pay for it on the spot - L$4000 per month for up to 100 listeners at up to 128kb/s.

====

I hope this helps anyone attempting to stream their Slimserver to a wider audience.