Menneisyys
01-02-2008, 09:47 AM
With the advent of cheap and/or unlimited data plans, good coverage and the increasing presence of Internet radio stations, the importance of listening to streaming radio stations have become much bigger than ever. In this Bible, I mostly elaborate on practices that
may make the sound quality much better using the same bandwidth, and/or
may save you tens or hundreds of bucks a month by heavily reducing data usage, while providing the same (or even better!) sound quality should you not be able to access any unlimited data plan (Canada with its ridiculous data rates (http://www.pocketpcmag.com/blogs/index.php?blog=15&title=why_the_larger_mobile_service_providers&more=1&c=1&tb=1&pb=1) comes into mind), and/or
may heavily increase your battery life by letting you “falling back” to the much more battery-friendly 2.(7)5G Internet access technologies instead of the power-hungry 3(.5)G ones, and/or
in cases, may even let you listen to some radio stations you would never have thought of because of the network / operating system restrictions, and/or
makes the central administration of your radio station favorites much easier – no need to switch between different radio programs if there’s a difference between the protocols / formats they use.
This article is part of my “Multimedia Bible” series and will, eventually, be incorporated in some way in the final version of Multimedia Bible, which, hopefully, will be published this month. Note that I'll also elaborate on TV (video) streaming and transcoding in a later Bible. We’ll use many of the tools / technologies introduced in this Bible in there; most importantly, Orb and VLC.
This Bible, as with my last multimedia-related articles, multiplatform. Don’t get offended by this if you're a fanboy of either of the platforms and just hate everything related to the other: both Windows Mobile and Symbian software developers need to know what the other operating system offers so that they can improve on their products. In addition, should you have devices of both operating systems, you'll be able to optimize the usage of these devices. Just an example: I mostly use the Nokia N95 as my main entertainment and light Web browser / mailer / communicator device because of its, compared to any Windows Mobile device, superior A2DP quality, built-in, stereo speakers, acceptable battery life and lightweight (120g), small body. Therefore, when I know I won't need a Pocket PC (and its high-resolution VGA screen), I know I can safely leave my comparatively heavy and "brick" HTC Universal at home, and go to, say, a quick walk with my N95 only. And, of course, when I do know I will need a Pocket PC and/or a high-resolution screen (for example, to do some serious (!) Web browsing or remote desktop access/control), I take my Universal with me too. (For phoning purposes, I still use my HTC Oxygen (s310) WM5 MS Smartphone because it's cheap - no problem if I'm robbed / it's stolen -, very sturdy and is one of the very few Windows Mobile devices that support flawless, two-party call recording capabilities (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2311&more=1&c=1&tb=1&pb=1). I always keep it in my trousers' pocket.)
Note that I planned to review the Palm OS as well. As, currently, I don’t have a Wi-Fi card for my Tungsten T3 and I just couldn’t make it use an external IrDA / Bluetooth modem (unlike with my old Zire 71), I couldn’t test streaming on it. By the time I publish the final Multimedia Bible, I’ll try to get hold of a Wi-Fi card and update this Bible so that Palm OS is also covered. (Sorry, I can't affort a 750p just to be even more multiplatform. If you have one lying around unused, of course, you can send it to me, particularly if you're inside the EU to avoid customs issues ;-) ). After all, on Palm OS, Pocket Tunes is a freaking good audio player well worth comparing other mobile operating systems to.
Introduction
While trying to listen to a radio stream, you surely have run into not being able to play back an Internet radio station either entirely or without severe quality and/or battery life degradation. After you read this Bible – and digest all its contents –, you’ll know how to fix problems like these.
1.1 When it’s completely impossible to listen to a stream...
First, let’s take a quick look at what can cause your handset to not be able to play back a particular Internet radio station.
Your connection speed simply doesn’t suffice for correctly playing back the stream. For example, you’re trying to listen to a 64 kbps (kilobit per second; that is, the so-called ‘bitrate’) stream over a standard GPRS connection. That is, your Internet connection speed is no more than 43 kbps. In these cases, you simply won’t be able to listen to the stream without severe pauses / stuttering, no matter how large buffers you use.
The situation is the same when you try to stay away from using a 3G (either a UMTS or a HSDPA) connection. Even if your handset supports 3G and you also have the necessary signal, you may still want to opt for disabling 3G entirely and going back to using GPRS. The most important reason for this is the vastly increased power usage of current 3G modules used in recent, even high-end handsets like the Windows Mobile HTC Kaiser or the Symbian Nokia N95 or N82. I’ve elaborated on this problem (with several tools that help in switching) in THIS (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2316&more=1&c=1&tb=1&pb=1) (Windows Mobile) and THIS (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2338&more=1&c=1&tb=1&pb=1) (Symbian) article.
In these cases, you will want something to (in cases, radically) decrease the bitrate of these streams. Fortunately, it’s in no way impossible. With current technology, you can transfer FM-quality, stereo music even at 24 kbps. I’m not kidding!
(Note that, in this Bible, I assume you only have GPRS access. Unfortunately, many GSM operators still stick with the GPRS + 3(.5)G schema, leaving out the 2.75G technology, EDGE (http://en.wikipedia.org/wiki/Enhanced_Data_Rates_for_GSM_Evolution) altogether. One example of them is Vodafone, which, with their unlimited data plans, only support GPRS, UMTS and HSDPA / HSUPA. That is, no support for EDGE at all - at least here.
EDGE has both (for radio streaming at least) good speed (236 kbps at most) and low power usage - according to my benchmarks, it doesn't use more power than GPRS.)
You’re trying to listen to a so-called ‘RTSP (http://en.wikipedia.org/wiki/RTSP)’ stream but your mobile phone operator doesn’t support direct Internet connections. They use firewalls and NAT’ing (Network Address Translation – see THIS (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=343&more=1&c=1&tb=1&pb=1) article for more info on the consequences), making it for the radio server to completely impossible to connect back to your handset. Unfortunately, about 60% of the world’s GSM operators do so.
Unfortunately, several radio stations or applications use RTSP. Most importantly, all (except for Mplayer (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2312&more=1&c=1&tb=1&pb=1) on Windows Mobile – more on this later) mobile RealAudio players use RTSP on both Windows Mobile and Symbian. This means you simply can’t listen to radio stations utilizing RealAudio unless you’re lucky enough to have a data subscription at a mobile operator not using NAT’ing.
(Speaking of the Windows Mobile port of Mplayer (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2312&more=1&c=1&tb=1&pb=1), it uses the firewall / NAT-friendly HTTP protocol instead of RTSP. However, it’s a real CPU hog: in the current version, RealOne streaming only works on 624 MHz Xscale CPU’s because it’s really-really CPU-intensive and, on these CPU’s, it chews through the battery really-really fast. It can’t be played back on current, TI OMAP-based Windows Mobile models at all. All in all, it’s pretty much useless.)
RTSP is also very extensively used by Orb, one of the best tools to transcode Internet radio stations. More on this in the Orb-related section.
There are simply no players to play back a given stream type. Then, even if you have a quick connection and/or a non-NAT’ing network operator, you still won’t be able to play back the stream.
The most important case of this are Windows Media Audio (WMA) streams on Symbian. While the built-in Music Player supports playing back local WMA files, it can’t do the same to WMA streams. The situation is particularly bad because the well-known, excellent Orb service, currently, only uses WMA as the only non-RTSP stream format. As WMA streams aren’t compliant with Symbian, you simply can’t use the otherwise excellent Orb if your connection is NAT’ed.
OGG stream support isn’t particularly good on Symbian either. Oggplayer is pretty much a joke and additional radio stations are pretty complicated to set up in the commercial LCG Jukebox (http://www.lonelycatgames.com/?app=lcgjukebox), the only other, SHOUTcast OGG-compliant player on Symbian. (Note that CorePlayer (http://www.coreplayer.com/) is able to play back WMA and OGG streams but, currently, as of the current beta version, its networking module is so bad that it’s unable to play back anything without severe problems surfacing after some minutes at most. This applies to not only WMA, but also other streams. Hope future versions - hopefully the forthcoming 1.2 - fix these issues. In the meantime, stay away from it.)
1.2 When you prefer optimizing an, otherwise, working stream...
Now that we’ve seen what can make it completely impossible to listen to a particular stream, let me also take a look at when you may still want to go for an optimized version of a radio station.
While, at your current connection speed, you already have a compatible stream, it isn’t of the best quality and you would prefer something much better.
The most important examples of this case are GPRS connections, meaning less than 43 kbps total download (downlink) speed, which means about 32 kbps effective radio stream bit rate. With traditional (non-HE-AAC v2) radio stations, you can only have streams of bad quality using GPRS.
For example, Orb only offers a 32 kbps, mono, 44 kHz stream when you switch to the GPRS mode (by using the “40 kbps” mode) if you can’t use RTSP because of the NAT restrictions of your operator. In no way can you instruct the Orb client to transfer stereo WMA audio in so low bitrates.
The (pretty few – most radio stations only have 60+ kbps OGG / WMA and 90+ kbps MP3 streams) radio stations that natively support 32-kbps-max bitrates suffer from the same problem: these streams are almost all mono and still of low sound quality.
You may want to prefer a single interface to quickly switch between your favourite radio stations, independent of their type / source. For example, you don’t want to fire up Internet Explorer Mobile (or, on Symbian, (Nokia) Web) to log into your Sirius account to listen to your Sirius stream only to find out you would still prefer a non-Sirius stream. In these cases, you’ll want to do this using an interface letting for quickly switching between your streams in order to avoid having firing up completely different interfaces to access them all.
And, I’ve already mentioned the vastly increased battery life when you fall back to 2.(7)5G technologies like GPRS (or EDGE – if you’re lucky enough to be a subscriber of a mobile operator with EDGE support). In general, you can count with about 50% (!) increased battery life if you do so.
Again and again, now, with the latest achievements in the radio streaming / encoding technology, you can get perfect sound quality even at GPRS speeds. That is, now, pre-3G technologies (and, particularly, GPRS – as has already been explained, EDGE, which offers far higher transfer speeds without any severe power usage increase, is able to stream most, if not all, current radio streams) have become much more important than ever before. You wouldn’t have thought you would force your shiny, HSDPA-capable, expensive handset to use GPRS only, have you? :) It certainly pays off if you need acceptably battery life while listening to your radio stations without any external charger for more than a few minutes.
If you don’t believe you can save a LOT of battery life by sticking to GPRS (or EDGE), just take a look at the following acbTaskMan screenshot showing the TCPMP playback of an MP3 stream on an HTC Universal. The first section shows playing back the stream over UMTS; the second over GPRS. The current difference is 200 mA / 330 mA = 60% (see the upper chart; the lower one shows the CPU usage which, in this test, is exactly the same because I played back the same stream with the same player). (Disregard the temporary power "bump" of the second part.) Yes, you can get 60% better battery life if you force your handset to operate in GPRS mode, instead of streaming over UMTS. Quite a difference, isn’t it?
http://www.winmobiletech.com/122007StreamTranscodingBible/CPUXscale520-TCPMP-GPRSvs3G-MP3.png
As can clearly be seen, the difference is almost the same as with the Nokia N95 – or, for that matter, with any other, current handset. As a rule of thumb, you will have at least 50% better battery life with any handset if you don’t use 3G for streaming.
To have a picture of what playback times you can expect of current handsets while playing back HE-AACv2 (and, on Symbian, MP3) streams over GPRS, I’ve made some serious long-time tests. On the TI OMAP-based HTC Vox / s710 MS Smartphone, HE-AACv2 (TCPMP) consumed 27% power an hour. Incidentally, as the TI OMAP platform exhibits far less CPU usage-dependent power usage than at least the older (but still most widely deployed) pre-PXA-3x0-series Intel Xscale’s, I’ve got almost the same figure with A2DP enabled. A2DP causes about an additional 20% CPU usage on the Vox; still, the difference in battery life is negligible when streaming (streaming itself is a very battery-consuming activity, even if you only use GPRS/EDGE, and stay away from 3G).
On the Nokia N95 v20, without A2DP, the power consumption is about 0.93W (see THIS (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2338&more=1&c=1&tb=1&pb=1)) ; with A2DP, about 1.15W. Therefore, you can expect slightly less than 4 hours of playback time without A2DP on the handset – just like with the HTC Vox.
Note that, currently, on Windows Mobile, you’ll want to use TCPMP to play back your streams. See THIS (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2362&more=1&c=1&tb=1&pb=1) article for more info on HE-AACv2 compliance. It’s only later that CorePlayer and, probably, Conduits Pocket Player / PocketMind Pocket Music (the developers of these apps promised they'd look into implementing support for them) get HE-AACv2 support.
Keep in mind the following: if you install TCPMP on a MS Smartphone (WM6 Standard), as opposed to “regular” Pocket PC’s, just extract 00000aac.001 from the AAC CAB file, rename it to aac.plg and copy it to the home directory of TCPMP on your Smartphone.
On Symbian, currently, Nokia Internet Radio (see remarks & quick review HERE (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2338&more=1&c=1&tb=1&pb=1)) is the best way to play back SHOUTcast MP3 streams.
Now, let’s take a quick look at what tools we have at our disposal.
1.3 Our tools: transcoders, stream formats
1.3.1 You must run a transcoder on your desktop PC!
First and foremost, for ALL the alternate technologies, you’ll need to have a desktop computer attached to the Internet and switched on when listening to music. The sole reason for this is that it’s on this machine that the so-called ‘transcoding’ (converting between two stream formats; Wiki page HERE (http://en.wikipedia.org/wiki/Transcoding)) takes place. Your handset will connect to this desktop PC instead of the original radio station URL.
Why no purely desktop PC-less setup, you might ask. Why can’t you just connect to a third-party server to do the trick for you? The reason for this is pretty simple: transcoding is a pretty much CPU-intensive task. A typical transcoding process, in VLC, takes about 10% CPU cycles on a contemporary 3.2 GHz P4. You can’t expect for example the Orb folks to install a supercomputer (http://en.wikipedia.org/wiki/Supercomputer) or some hundred PC’s to offer transcoding to their clients – for free. Of course, in the future, companies / services specialized in providing server-side, commercial transcoding services may turn up.
This is why you MUST have a desktop PC running your transcoder, independent of their particular type.
1.3.2 Stream formats
In my quick review of streaming audio formats (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2350&more=1&c=1&tb=1&pb=1), I’ve already elaborated on the different playback capabilities of the available media players.
You may already also know that you should go for the currently best, most effective audio format, HE-AAC v2 if you have a Windows Mobile device. If you have a Symbian one, then, either MP3 or, if you have a non-NAT’ed network connection, even Orb's RealAudio or RTSP/AAC will work for you.
Quality differences (in which, HE-AAC v2 is certainly the winner) and generic operating system compliance (again, streamed HE-AAC v2 is, currently, only compatible with Windows Mobile but not with Symbian) aside, there are some other factors you should consider when going for a given streaming format; for example, the CPU usage, which, at least on some architectures, may have a huge effect on the power usage and battery life of the handset.
The following screenshot shows playing back MP3 (which is a less CPU-hungry operation) and HE-AAC v2.
http://www.winmobiletech.com/122007StreamTranscodingBible/CPUXscale520-TCPMPMP3vsHEAAC2-GPRS.png
Note that this, mostly, affects Intel Xscale PXA-2xx users only – that is, users with HTC Universals, Athenas / X7500’s and several earlier PDA’s and handsets. Users of for example TI OMAP-based handsets won’t really notice any increase in battery life if they go for MP3 instead of HE-AAC v2. The reason for this has already been explained in my H.264 Bible (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2373&more=1&c=1&tb=1&pb=1): the TI OMAP platform is much more battery-friendly than the Intel PXA-2xx one. I can only hope Marvel, the new owner / developer of the old PXA architecture, have indeed improved on power usage in the brand new, 3x0-series PXA’s. (I still haven't had the chance to verify this as these new CPU's are used in very few and, in Europe, still not available, disconnected, traditional PDA models.)
1.4 Transcoders
Now, let’s elaborate on all the transcoder alternatives.
1.4.1 Orb (http://www.orb.com/)
Currently, the most widely known and popular transcoder (and generic radio streaming) service is that of Orb. It is hugely popular with both the Windows Mobile, Symbian and iPhone folks. It certainly deserves this: while, in some cases, it’s definitely lacking, the web access module it provides is by far the best of all. And, it not only allows for transcoding radio stations, but also accessing the files on your desktop computer and streaming multimedia files from there – as if they were located on your handset.
After installing, if you want to add your own radio stations to Orb, right-click the Orb icon in the Windows tray in the lower right corner, select Configuration and go to the Media tab. There, click the Add button in the “Music” group to add the directory of your playlist files.
http://www.winmobiletech.com/122007StreamTranscodingBible/AddRadioPLSFilesToOrb.png
They’ll, then, be shown under Audio / Playlists:
http://www.winmobiletech.com/122007StreamTranscodingBible/OrbMobilePlaylistsshown.png
Of course, under Audio / Internet Radio, you’ll still see the radio stations shipping with Orb (http://www.winmobiletech.com/122007StreamTranscodingBible/OrbInternetRadio.png) – you might also want to take a look at them.
I REALLY recommend giving Orb a try. Even if you don’t start to actively use it (because of the severe Orb restrictions and the vast superiority of the HE-AAC v2 format (Orb only uses the “dumbest” AAC-LC (http://forums.orb.com/viewtopic.php?t=3690))), it’s still worth paying a try.
1.4.1.1 Restrictions of Orb
If you take a look at the online Settings / Stream page of Orb, you see it offers several output stream types:
http://www.winmobiletech.com/122007StreamTranscodingBible/OrbMobileStreamTypes.png
(Incidentally, it’s this page that allows for selecting the streaming format. All this when accessed from a mobile browser like Internet Explorer on Windows Mobile, Nokia Web on Symbian or Opera Mobile on both operating systems.)
As can clearly be seen, WMA, RealAudio, some 3G formats (ALL in RTSP!), Winamp PLS and Flash are supported. Unfortunately, many of them (the 3G formats and RealAudio) are RTSP-only, which means they are completely useless if your mobile operator uses NAT’ing – that is, doesn’t expose your handset directly to the Internet.
As far as the Flash support of Orb is concerned, on Windows Mobile, the Flash player (screenshot running under Opera Mobile (http://www.winmobiletech.com/122007StreamTranscodingBible/FlashPlaybackInOrbOM.png)), while it starts with the official, latest MM7 Flash player plug-in, crashes after about 10 seconds when used from the built-in Internet Explorer (tested on two devices). On Opera Mobile 8.65, it keeps playing; however, it utilizes the CPU at 100% as can clearly be seen in HERE (http://www.winmobiletech.com/122007StreamTranscodingBible/FlashPlayerCPUUsage.png). And, in addition to the huge CPU usage, it also has a major problem: it uses a temporary file in the built-in storage of the device, which will, sooner or later, result in the storage’s entirely filling up and stopping / crashing the machine. A screenshot of these temporary files is HERE (http://www.winmobiletech.com/122007StreamTranscodingBible/FlashPlayerTempFiles.png). Flash Lite 2.1 (https://www.adobe.com/cfusion/entitlement/index.cfm?e=flashlite2%5F1%5Fwinmobile%5Fdownload) is totally incompatible with Orb’s Flash streams as can also be seen in HERE (http://www.winmobiletech.com/122007StreamTranscodingBible/FlashLiteWMIncomp.png).
Under Symbian, it doesn’t even start under the “old” but still official Flash Lite 2 support of Nokia Web as can also be seen in HERE (http://www.winmobiletech.com/122007StreamTranscodingBible/NokiaOrbFlashNo.png).
All in all, under the two mobile operating systems, using the Flash mode is in no way recommended.
Also note that the Winamp .pls format it offers internally just uses WMA streams – don’t think it’s a SHOUTcast-compatible stream meaning compatibility with Nokia Internet Radio / LCG Jukebox on Symbian or with many SHOUTcast clients (GSPlayer etc.) on Windows Mobile.
Two compatibility charts follow, which show the two major mobile operating systems in both NAT’ed and non-NAT’ed (direct) cases:
Windows Mobile:
http://www.winmobiletech.com/122007StreamTranscodingBible/t1.png
Symbian:
http://www.winmobiletech.com/122007StreamTranscodingBible/t2.png
As can clearly be seen, if your connection is NAT’ed, your only choice is WMA (which, incidentally, uses 32 kbps 44 kHz mono (!) sound in the 40 kbps, that is, GPRS setting). This will work on Windows Mobile but, currently, not on Symbian.
All in all, Orb is a decent choice if you have a faster (for example, EDGE or the even faster 3G, assuming you aren’t afraid of the huge battery usage of the latter) connection and/or a non-NAT’ed environment. In these cases, its technical inferiority (the lack of SHOUTcast stream support and, most importantly, the lack of HE-AAC v2 – that is, the only high-quality streaming format for GPRS connections) won’t cause you problems. Finally, it has pretty nice Sirius and XM support. See THIS (http://www.allaboutsymbian.com/forum/showpost.php?p=353195&postcount=7) for more info on the latter.
Let me, however, reiterate its disadvantages again:
if you try to listen to radio stations at GPRS speeds (meaning streams with 32 kbps bitrates max), it’s, audio quality-wise definitely a suboptimal solution and should only be used when you absolutely need to use it – for example, because you prefer its GUI to those of the other players. Why would you want to prefer mono WMA streaming with a lot of compression artifacts when, with other transcoders, you can have excellent, stereo HE-AAC v2 streams without compression artifacts - at the same bitrate? and/or
if you have Symbian (not WM) and a NAT’ed connection (ruling out everything – remember, in a NAT’ed environment, with Orb, you could only rely on WMA, but it’s not supported by the system and CorePlayer’s current version has very buggy streaming support),
you will definitely want to take a look at the SHOUTcast / Icecast2-based alternatives; most importantly, Oddsock.org’s excellent apps.
Note that I’m pushing the Orb folks to add Icecast2-based HE-AAC v2 and MP3 stream support. See THIS (http://forums.orb.com/viewtopic.php?t=9248) thread for more info.
1.4.1.2 Other Orb-related discussion threads of interest
Mobile Phone Streaming Issues (http://forums.orb.com/viewtopic.php?t=4139)
XM and Sirius (http://forums.orb.com/viewtopic.php?t=1833)
SKY.FM, DI.FM (http://forums.orb.com/viewtopic.php?t=9205)
Note that, while the old "High quality" option under 3GP, had a separate checkbox to switch to AAC(-LC); the new, 2beta version has a separate, top-level radio button for this mode. That is, don't let you be mislead by THIS (http://forums.orb.com/viewtopic.php?t=1432), THIS (http://forums.orb.com/viewtopic.php?t=1862), THIS (http://forums.orb.com/viewtopic.php?t=2271) and THIS (http://forums.orb.com/viewtopic.php?t=1860) threads, which still refer to the old approach.
Streaming, additional aac codec (http://forums.orb.com/viewtopic.php?t=2176)
1.4.2 Icecast2-based streaming
The following alternatives all require the usage of an Icecast2 server. (Note that, as an exception, VideoLAN VLC doesn’t necessarily need it unless you stream to a Symbian handset from it. The same stands for WME as well - it's a server on its own.)
1.4.2.1 Icecast2
Icecast2 (Wiki page HERE (http://en.wikipedia.org/wiki/Icecast)) is an open source equivalent of Nullsoft’s SHOUTcast (http://en.wikipedia.org/wiki/SHOUTcast) server, which does exactly the same. There, effectively, there isn’t much difference between SHOUTcast and Icecast2; geeks and other pros tend to prefer the latter; therefore, I also elaborate on it in here, instead of the closed-source, proprietary SHOUTcast.
You can get it HERE (http://icecast.org/). The download links are on the top of the page; if you have Windows, you’ll want to download the icecast2_win32_v2.X.X_setup.exe file. After installation, start it. Go to Configuration / Edit Configuration and edit the file in the following way:
Change the three passwords from “hackme” to anything under icecast / authentication. For example, in THIS (http://www.winmobiletech.com/122007StreamTranscodingBible/IcecastpasswordChange.png) screenshot, I’ve changed all the three to mennpwd. You don’t need to use the same word for all the three passwords.
The number of concurrent streams under icecast / limits / sources. If you plan to transcode more than two streams with a multiple stream-capable source client at the same time, you must modify this parameter too. For example, in THIS (http://www.winmobiletech.com/122007StreamTranscodingBible/IcecastSourceNr.png) screenshot, I’ve set it to 30 so that I can have 30 concurrent, different streams (we’ll see in which cases you’ll find this useful).
After editing, just close the Notepad window and answer Yes to saving it.
Now, when you click the Start Server button, it starts listening to incoming streams as can be seen in HERE (http://www.winmobiletech.com/122007StreamTranscodingBible/IcecastServerStarted.png). You won’t need to do anything else to Icecast2, other than starting / stopping the server if you need it or don’t need it any more.
Note that, by itself, Icecast2 doesn’t stream anything; it needs other clients (“source clients”), whose streams it just relays to the Net. That is, effectively, it uses the famous three-tiered Web application server model already known to many IT gurus, where the listening client equals to the Web browser, the middle tier (the application / Web server) is Icecast2 and the database back-end is, in this case, the transcoding source clients. It’s the stream of the latter that Icecast2, in the middle tier, “just” relays further to the client listener(s).
The streaming clients introduced in the next subsections are all geared towards using Icecast2 as the real streaming server. The only exceptions are:
VideoLAN VLC, which can also operate in a standalone mode (but, then, produce a stream not compatible with some media player clients, including Nokia Internet Radio);
Orb and, finally,
WME, which are also completely independent of Icecast2.
1.4.2.1.1 Mount points
You must be aware of the so-called ‘mount points’. Particularly when you stream more than one radio stations at the same time (in cases, you’ll want to prefer this solution to the others because it frees you from having to remote control the sound source), you will want to know what a mount point is.
When you configure an Icecast2 source client (VideoLAN VLC, Oddsock.org’s apps etc) to stream their contents to an Icecast2 server, you not only pass these clients the Internet address of the Icecast2 server they’ll need to connect to, but also an additional parameter that, later, uniquely identifies the stream: the mount point.
For example, let’s assume you stream two streams to your Icecast2 server from your VideoLAN VLC client. To quickly fire up the streams, you create a batch file with the following contents:
start vlc.exe --sout-shout-name="Iskelmä Radio" --sout-shout-description="Iskelmä Radio (Finnish)" http://217.30.180.250:8050/ :sout=#transcode{acodec=mp3,ab=32,channels=2}:duplicate{dst=std{access=shout,mux=ogg,dst=source:[email protected]:8000/iskelma}}
start vlc.exe --sout-shout-name="Radio Vaasa" --sout-shout-description=" Radio Vaasa (Finnish)" http://webcast.vlp.fi:8000/radioVaasa :sout=#transcode{acodec=mp3,ab=32,channels=2}:duplicate{dst=std{access=shout,mux=ogg,dst=source:[email protected]:8000/radioVaasa}}
Here, look for the iskelma and radioVaasa parameters. It’s there that you tell Icecast2 where to “map” these streams to. If you use these two mount points, you can access (listen to) these streams from a SHOUTcast/Icecast-compliant mobile client (TCPMP, CorePlayer, GSPlayer, Nokia Internet Radio, LCG Jukebox etc.) by simply supplying the mount point after the address and IP of your server like in the following direct URL you can directly enter in any of these players:
http://111.222.333.444:8000/iskelma
and
http://111.222.333.444:8000/radioVaasa
(111.222.333.444 is my desktop computer's imaginary IP address. You'll, of course, will need to provide yours. Use What Is My IP (http://whatismyip.com/) if not sure.)
Of course, prefer defining a playlist .pls file instead of entering URL’s like these into a player to make your life even easier because of the direct file access in most of these apps. The contents should be as follows:
[playlist]
numberofentries=2
File1= http://111.222.333.444:8000/iskelma
Title1=Radio Iskelmä
Length1=-1
File2=http://111.222.333.444:8000/radioVaasa
Title2=Radio Vaasa
Length2=-1
Version=2
(Note that you can leave out the Title and Length attributes. However, if you do so, the current beta of Nokia Internet Radio will crash and will be needed to reinstalled for it to work again.)
You can use any mount point name and you don’t need to explicitly configure the Icecast2 server to know anything about them. That is, you don’t need to tell Icecast2 “hey, I want to use the mount point “mystation”; let me configure you” at all. This is certainly very good news: only the original clients (transcoding the original Internet radios and streaming the transcoded contents to Icecast2) and the mobile players need to be aware of (that is, use) the same mount points.
An Icecast2 screenshot of showing several mount points being in use at the same time, with VLC acting as a streaming client:
http://www.winmobiletech.com/122007StreamTranscodingBible/ManyMountPointsInUseAtthesametime.png
1.4.2.1.2 Connecting to your Icecast2 server
In this section, I elaborate on how streaming clients and mobile multimedia players can connect to your Icecast2 server.
1.4.2.1.2.1 Streaming clients
As has already been mentioned, for a streaming client to connect to Icecast2, it must know the streaming source password (set in the icecast / authentication / source-password), the address: port (127.0.0.1:8000 if it’s running on the same desktop PC) and, finally, the arbitrary mounting point.
For example, in the above-shown VLC batch file,
start vlc.exe --sout-shout-name="Iskelmä Radio" --sout-shout-description="Iskelmä Radio (Finnish)" http://217.30.180.250:8050/ :sout=#transcode{acodec=mp3,ab=32,channels=2}:duplicate{dst=std{access=shout,mux=ogg,dst=source:[email protected]:8000/iskelma}}
the bold text, source:[email protected]:8000/iskelma, contains all this information.
Here, “source” is the username by default for streaming clients like VLC or the Oddsock.org apps. “mennpwd” is the password I use; “127.0.0.1:8000” is the IP address and port number of the Icecast2 server. In this example, it’s running on the local PC; hence the localhost address. Finally, “iskelma”, as we’ve already seen, is the mount point name.
1.4.2.1.2.2 (Mobile) receiver clients
As has already been mentioned in section “1.4.2.1.1 Mount points”, you can either directly enter the URL (of the form http://your desktop computer IP : port (8000 by default)/mount point) into the player or, alternatively, can create a .PLS (http://en.wikipedia.org/wiki/PLS_(file_format)) and/or (preferably extended, so that it also contains the station name) .M3U (http://en.wikipedia.org/wiki/M3u) file with the URL and a description. Note that these playlist files can have several URLs with separate descriptions. (Also note that I only use PLS files as examples in this tutorial because Nokia Internet Radio doesn’t support M3U files.)
An example PLS file having seven entries:
[playlist]
numberofentries=7
File1=http://111.222.333.444:1234/
Title1=Radio Peili
Length1=-1
File2=http://111.222.333.444:8000/iskelma
Title2=Radio Iskelma
Length2=-1
File3=http://111.222.333.444:1236/
Title3=Arkisto
Length3=-1
File4=http://111.222.333.444:8000/radioVaasa
Title4=Radio Vaasa
Length4=-1
File5=http://111.222.333.444:8000/rspo
Title5=RSPO
Length5=-1
File6=http://111.222.333.444:8000/klf
Title6=KLF
Length6=-1
File7=http://111.222.333.444:8000/rhesa
Title7=Radio Helsinki
Length7=-1
Version=2
Note that it has two non-8000, that is, two non-Icecast2 ports: 1234 and 1236 in the first and third records. I’ll elaborate on this a bit later, in the VLC section. All the other URL’s point to the same Icecast2 server with, of course, different mount points.
Colleting your favorite stations into one PLS file is pretty much useful because, then, it’ll become far easier for you to switch between the radio stations after opening the playlist file. For example, the above PLS file is rendered by Nokia Internet Radio the following way:
http://www.winmobiletech.com/122007StreamTranscodingBible/NIRPLSPlayListContents.png
By TCPMP, this way:
http://www.winmobiletech.com/122007StreamTranscodingBible/TCPMPPLSPlayListContents.png
and, by CorePlayer, this way:
http://www.winmobiletech.com/122007StreamTranscodingBible/CPPLSPlayListContents.png
Note that the two latter apps automatically start playing the first station in the playlist (Nokia Internet Radio doesn’t); if it’s a problem, you will want to separate your stations in separate PLS (or M3U) files. Also note that you can transfer these streams to your built-in "favorite" playlists in all these radio clients. Then, you won't need to click / import PLS files more than once.
may make the sound quality much better using the same bandwidth, and/or
may save you tens or hundreds of bucks a month by heavily reducing data usage, while providing the same (or even better!) sound quality should you not be able to access any unlimited data plan (Canada with its ridiculous data rates (http://www.pocketpcmag.com/blogs/index.php?blog=15&title=why_the_larger_mobile_service_providers&more=1&c=1&tb=1&pb=1) comes into mind), and/or
may heavily increase your battery life by letting you “falling back” to the much more battery-friendly 2.(7)5G Internet access technologies instead of the power-hungry 3(.5)G ones, and/or
in cases, may even let you listen to some radio stations you would never have thought of because of the network / operating system restrictions, and/or
makes the central administration of your radio station favorites much easier – no need to switch between different radio programs if there’s a difference between the protocols / formats they use.
This article is part of my “Multimedia Bible” series and will, eventually, be incorporated in some way in the final version of Multimedia Bible, which, hopefully, will be published this month. Note that I'll also elaborate on TV (video) streaming and transcoding in a later Bible. We’ll use many of the tools / technologies introduced in this Bible in there; most importantly, Orb and VLC.
This Bible, as with my last multimedia-related articles, multiplatform. Don’t get offended by this if you're a fanboy of either of the platforms and just hate everything related to the other: both Windows Mobile and Symbian software developers need to know what the other operating system offers so that they can improve on their products. In addition, should you have devices of both operating systems, you'll be able to optimize the usage of these devices. Just an example: I mostly use the Nokia N95 as my main entertainment and light Web browser / mailer / communicator device because of its, compared to any Windows Mobile device, superior A2DP quality, built-in, stereo speakers, acceptable battery life and lightweight (120g), small body. Therefore, when I know I won't need a Pocket PC (and its high-resolution VGA screen), I know I can safely leave my comparatively heavy and "brick" HTC Universal at home, and go to, say, a quick walk with my N95 only. And, of course, when I do know I will need a Pocket PC and/or a high-resolution screen (for example, to do some serious (!) Web browsing or remote desktop access/control), I take my Universal with me too. (For phoning purposes, I still use my HTC Oxygen (s310) WM5 MS Smartphone because it's cheap - no problem if I'm robbed / it's stolen -, very sturdy and is one of the very few Windows Mobile devices that support flawless, two-party call recording capabilities (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2311&more=1&c=1&tb=1&pb=1). I always keep it in my trousers' pocket.)
Note that I planned to review the Palm OS as well. As, currently, I don’t have a Wi-Fi card for my Tungsten T3 and I just couldn’t make it use an external IrDA / Bluetooth modem (unlike with my old Zire 71), I couldn’t test streaming on it. By the time I publish the final Multimedia Bible, I’ll try to get hold of a Wi-Fi card and update this Bible so that Palm OS is also covered. (Sorry, I can't affort a 750p just to be even more multiplatform. If you have one lying around unused, of course, you can send it to me, particularly if you're inside the EU to avoid customs issues ;-) ). After all, on Palm OS, Pocket Tunes is a freaking good audio player well worth comparing other mobile operating systems to.
Introduction
While trying to listen to a radio stream, you surely have run into not being able to play back an Internet radio station either entirely or without severe quality and/or battery life degradation. After you read this Bible – and digest all its contents –, you’ll know how to fix problems like these.
1.1 When it’s completely impossible to listen to a stream...
First, let’s take a quick look at what can cause your handset to not be able to play back a particular Internet radio station.
Your connection speed simply doesn’t suffice for correctly playing back the stream. For example, you’re trying to listen to a 64 kbps (kilobit per second; that is, the so-called ‘bitrate’) stream over a standard GPRS connection. That is, your Internet connection speed is no more than 43 kbps. In these cases, you simply won’t be able to listen to the stream without severe pauses / stuttering, no matter how large buffers you use.
The situation is the same when you try to stay away from using a 3G (either a UMTS or a HSDPA) connection. Even if your handset supports 3G and you also have the necessary signal, you may still want to opt for disabling 3G entirely and going back to using GPRS. The most important reason for this is the vastly increased power usage of current 3G modules used in recent, even high-end handsets like the Windows Mobile HTC Kaiser or the Symbian Nokia N95 or N82. I’ve elaborated on this problem (with several tools that help in switching) in THIS (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2316&more=1&c=1&tb=1&pb=1) (Windows Mobile) and THIS (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2338&more=1&c=1&tb=1&pb=1) (Symbian) article.
In these cases, you will want something to (in cases, radically) decrease the bitrate of these streams. Fortunately, it’s in no way impossible. With current technology, you can transfer FM-quality, stereo music even at 24 kbps. I’m not kidding!
(Note that, in this Bible, I assume you only have GPRS access. Unfortunately, many GSM operators still stick with the GPRS + 3(.5)G schema, leaving out the 2.75G technology, EDGE (http://en.wikipedia.org/wiki/Enhanced_Data_Rates_for_GSM_Evolution) altogether. One example of them is Vodafone, which, with their unlimited data plans, only support GPRS, UMTS and HSDPA / HSUPA. That is, no support for EDGE at all - at least here.
EDGE has both (for radio streaming at least) good speed (236 kbps at most) and low power usage - according to my benchmarks, it doesn't use more power than GPRS.)
You’re trying to listen to a so-called ‘RTSP (http://en.wikipedia.org/wiki/RTSP)’ stream but your mobile phone operator doesn’t support direct Internet connections. They use firewalls and NAT’ing (Network Address Translation – see THIS (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=343&more=1&c=1&tb=1&pb=1) article for more info on the consequences), making it for the radio server to completely impossible to connect back to your handset. Unfortunately, about 60% of the world’s GSM operators do so.
Unfortunately, several radio stations or applications use RTSP. Most importantly, all (except for Mplayer (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2312&more=1&c=1&tb=1&pb=1) on Windows Mobile – more on this later) mobile RealAudio players use RTSP on both Windows Mobile and Symbian. This means you simply can’t listen to radio stations utilizing RealAudio unless you’re lucky enough to have a data subscription at a mobile operator not using NAT’ing.
(Speaking of the Windows Mobile port of Mplayer (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2312&more=1&c=1&tb=1&pb=1), it uses the firewall / NAT-friendly HTTP protocol instead of RTSP. However, it’s a real CPU hog: in the current version, RealOne streaming only works on 624 MHz Xscale CPU’s because it’s really-really CPU-intensive and, on these CPU’s, it chews through the battery really-really fast. It can’t be played back on current, TI OMAP-based Windows Mobile models at all. All in all, it’s pretty much useless.)
RTSP is also very extensively used by Orb, one of the best tools to transcode Internet radio stations. More on this in the Orb-related section.
There are simply no players to play back a given stream type. Then, even if you have a quick connection and/or a non-NAT’ing network operator, you still won’t be able to play back the stream.
The most important case of this are Windows Media Audio (WMA) streams on Symbian. While the built-in Music Player supports playing back local WMA files, it can’t do the same to WMA streams. The situation is particularly bad because the well-known, excellent Orb service, currently, only uses WMA as the only non-RTSP stream format. As WMA streams aren’t compliant with Symbian, you simply can’t use the otherwise excellent Orb if your connection is NAT’ed.
OGG stream support isn’t particularly good on Symbian either. Oggplayer is pretty much a joke and additional radio stations are pretty complicated to set up in the commercial LCG Jukebox (http://www.lonelycatgames.com/?app=lcgjukebox), the only other, SHOUTcast OGG-compliant player on Symbian. (Note that CorePlayer (http://www.coreplayer.com/) is able to play back WMA and OGG streams but, currently, as of the current beta version, its networking module is so bad that it’s unable to play back anything without severe problems surfacing after some minutes at most. This applies to not only WMA, but also other streams. Hope future versions - hopefully the forthcoming 1.2 - fix these issues. In the meantime, stay away from it.)
1.2 When you prefer optimizing an, otherwise, working stream...
Now that we’ve seen what can make it completely impossible to listen to a particular stream, let me also take a look at when you may still want to go for an optimized version of a radio station.
While, at your current connection speed, you already have a compatible stream, it isn’t of the best quality and you would prefer something much better.
The most important examples of this case are GPRS connections, meaning less than 43 kbps total download (downlink) speed, which means about 32 kbps effective radio stream bit rate. With traditional (non-HE-AAC v2) radio stations, you can only have streams of bad quality using GPRS.
For example, Orb only offers a 32 kbps, mono, 44 kHz stream when you switch to the GPRS mode (by using the “40 kbps” mode) if you can’t use RTSP because of the NAT restrictions of your operator. In no way can you instruct the Orb client to transfer stereo WMA audio in so low bitrates.
The (pretty few – most radio stations only have 60+ kbps OGG / WMA and 90+ kbps MP3 streams) radio stations that natively support 32-kbps-max bitrates suffer from the same problem: these streams are almost all mono and still of low sound quality.
You may want to prefer a single interface to quickly switch between your favourite radio stations, independent of their type / source. For example, you don’t want to fire up Internet Explorer Mobile (or, on Symbian, (Nokia) Web) to log into your Sirius account to listen to your Sirius stream only to find out you would still prefer a non-Sirius stream. In these cases, you’ll want to do this using an interface letting for quickly switching between your streams in order to avoid having firing up completely different interfaces to access them all.
And, I’ve already mentioned the vastly increased battery life when you fall back to 2.(7)5G technologies like GPRS (or EDGE – if you’re lucky enough to be a subscriber of a mobile operator with EDGE support). In general, you can count with about 50% (!) increased battery life if you do so.
Again and again, now, with the latest achievements in the radio streaming / encoding technology, you can get perfect sound quality even at GPRS speeds. That is, now, pre-3G technologies (and, particularly, GPRS – as has already been explained, EDGE, which offers far higher transfer speeds without any severe power usage increase, is able to stream most, if not all, current radio streams) have become much more important than ever before. You wouldn’t have thought you would force your shiny, HSDPA-capable, expensive handset to use GPRS only, have you? :) It certainly pays off if you need acceptably battery life while listening to your radio stations without any external charger for more than a few minutes.
If you don’t believe you can save a LOT of battery life by sticking to GPRS (or EDGE), just take a look at the following acbTaskMan screenshot showing the TCPMP playback of an MP3 stream on an HTC Universal. The first section shows playing back the stream over UMTS; the second over GPRS. The current difference is 200 mA / 330 mA = 60% (see the upper chart; the lower one shows the CPU usage which, in this test, is exactly the same because I played back the same stream with the same player). (Disregard the temporary power "bump" of the second part.) Yes, you can get 60% better battery life if you force your handset to operate in GPRS mode, instead of streaming over UMTS. Quite a difference, isn’t it?
http://www.winmobiletech.com/122007StreamTranscodingBible/CPUXscale520-TCPMP-GPRSvs3G-MP3.png
As can clearly be seen, the difference is almost the same as with the Nokia N95 – or, for that matter, with any other, current handset. As a rule of thumb, you will have at least 50% better battery life with any handset if you don’t use 3G for streaming.
To have a picture of what playback times you can expect of current handsets while playing back HE-AACv2 (and, on Symbian, MP3) streams over GPRS, I’ve made some serious long-time tests. On the TI OMAP-based HTC Vox / s710 MS Smartphone, HE-AACv2 (TCPMP) consumed 27% power an hour. Incidentally, as the TI OMAP platform exhibits far less CPU usage-dependent power usage than at least the older (but still most widely deployed) pre-PXA-3x0-series Intel Xscale’s, I’ve got almost the same figure with A2DP enabled. A2DP causes about an additional 20% CPU usage on the Vox; still, the difference in battery life is negligible when streaming (streaming itself is a very battery-consuming activity, even if you only use GPRS/EDGE, and stay away from 3G).
On the Nokia N95 v20, without A2DP, the power consumption is about 0.93W (see THIS (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2338&more=1&c=1&tb=1&pb=1)) ; with A2DP, about 1.15W. Therefore, you can expect slightly less than 4 hours of playback time without A2DP on the handset – just like with the HTC Vox.
Note that, currently, on Windows Mobile, you’ll want to use TCPMP to play back your streams. See THIS (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2362&more=1&c=1&tb=1&pb=1) article for more info on HE-AACv2 compliance. It’s only later that CorePlayer and, probably, Conduits Pocket Player / PocketMind Pocket Music (the developers of these apps promised they'd look into implementing support for them) get HE-AACv2 support.
Keep in mind the following: if you install TCPMP on a MS Smartphone (WM6 Standard), as opposed to “regular” Pocket PC’s, just extract 00000aac.001 from the AAC CAB file, rename it to aac.plg and copy it to the home directory of TCPMP on your Smartphone.
On Symbian, currently, Nokia Internet Radio (see remarks & quick review HERE (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2338&more=1&c=1&tb=1&pb=1)) is the best way to play back SHOUTcast MP3 streams.
Now, let’s take a quick look at what tools we have at our disposal.
1.3 Our tools: transcoders, stream formats
1.3.1 You must run a transcoder on your desktop PC!
First and foremost, for ALL the alternate technologies, you’ll need to have a desktop computer attached to the Internet and switched on when listening to music. The sole reason for this is that it’s on this machine that the so-called ‘transcoding’ (converting between two stream formats; Wiki page HERE (http://en.wikipedia.org/wiki/Transcoding)) takes place. Your handset will connect to this desktop PC instead of the original radio station URL.
Why no purely desktop PC-less setup, you might ask. Why can’t you just connect to a third-party server to do the trick for you? The reason for this is pretty simple: transcoding is a pretty much CPU-intensive task. A typical transcoding process, in VLC, takes about 10% CPU cycles on a contemporary 3.2 GHz P4. You can’t expect for example the Orb folks to install a supercomputer (http://en.wikipedia.org/wiki/Supercomputer) or some hundred PC’s to offer transcoding to their clients – for free. Of course, in the future, companies / services specialized in providing server-side, commercial transcoding services may turn up.
This is why you MUST have a desktop PC running your transcoder, independent of their particular type.
1.3.2 Stream formats
In my quick review of streaming audio formats (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2350&more=1&c=1&tb=1&pb=1), I’ve already elaborated on the different playback capabilities of the available media players.
You may already also know that you should go for the currently best, most effective audio format, HE-AAC v2 if you have a Windows Mobile device. If you have a Symbian one, then, either MP3 or, if you have a non-NAT’ed network connection, even Orb's RealAudio or RTSP/AAC will work for you.
Quality differences (in which, HE-AAC v2 is certainly the winner) and generic operating system compliance (again, streamed HE-AAC v2 is, currently, only compatible with Windows Mobile but not with Symbian) aside, there are some other factors you should consider when going for a given streaming format; for example, the CPU usage, which, at least on some architectures, may have a huge effect on the power usage and battery life of the handset.
The following screenshot shows playing back MP3 (which is a less CPU-hungry operation) and HE-AAC v2.
http://www.winmobiletech.com/122007StreamTranscodingBible/CPUXscale520-TCPMPMP3vsHEAAC2-GPRS.png
Note that this, mostly, affects Intel Xscale PXA-2xx users only – that is, users with HTC Universals, Athenas / X7500’s and several earlier PDA’s and handsets. Users of for example TI OMAP-based handsets won’t really notice any increase in battery life if they go for MP3 instead of HE-AAC v2. The reason for this has already been explained in my H.264 Bible (http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2373&more=1&c=1&tb=1&pb=1): the TI OMAP platform is much more battery-friendly than the Intel PXA-2xx one. I can only hope Marvel, the new owner / developer of the old PXA architecture, have indeed improved on power usage in the brand new, 3x0-series PXA’s. (I still haven't had the chance to verify this as these new CPU's are used in very few and, in Europe, still not available, disconnected, traditional PDA models.)
1.4 Transcoders
Now, let’s elaborate on all the transcoder alternatives.
1.4.1 Orb (http://www.orb.com/)
Currently, the most widely known and popular transcoder (and generic radio streaming) service is that of Orb. It is hugely popular with both the Windows Mobile, Symbian and iPhone folks. It certainly deserves this: while, in some cases, it’s definitely lacking, the web access module it provides is by far the best of all. And, it not only allows for transcoding radio stations, but also accessing the files on your desktop computer and streaming multimedia files from there – as if they were located on your handset.
After installing, if you want to add your own radio stations to Orb, right-click the Orb icon in the Windows tray in the lower right corner, select Configuration and go to the Media tab. There, click the Add button in the “Music” group to add the directory of your playlist files.
http://www.winmobiletech.com/122007StreamTranscodingBible/AddRadioPLSFilesToOrb.png
They’ll, then, be shown under Audio / Playlists:
http://www.winmobiletech.com/122007StreamTranscodingBible/OrbMobilePlaylistsshown.png
Of course, under Audio / Internet Radio, you’ll still see the radio stations shipping with Orb (http://www.winmobiletech.com/122007StreamTranscodingBible/OrbInternetRadio.png) – you might also want to take a look at them.
I REALLY recommend giving Orb a try. Even if you don’t start to actively use it (because of the severe Orb restrictions and the vast superiority of the HE-AAC v2 format (Orb only uses the “dumbest” AAC-LC (http://forums.orb.com/viewtopic.php?t=3690))), it’s still worth paying a try.
1.4.1.1 Restrictions of Orb
If you take a look at the online Settings / Stream page of Orb, you see it offers several output stream types:
http://www.winmobiletech.com/122007StreamTranscodingBible/OrbMobileStreamTypes.png
(Incidentally, it’s this page that allows for selecting the streaming format. All this when accessed from a mobile browser like Internet Explorer on Windows Mobile, Nokia Web on Symbian or Opera Mobile on both operating systems.)
As can clearly be seen, WMA, RealAudio, some 3G formats (ALL in RTSP!), Winamp PLS and Flash are supported. Unfortunately, many of them (the 3G formats and RealAudio) are RTSP-only, which means they are completely useless if your mobile operator uses NAT’ing – that is, doesn’t expose your handset directly to the Internet.
As far as the Flash support of Orb is concerned, on Windows Mobile, the Flash player (screenshot running under Opera Mobile (http://www.winmobiletech.com/122007StreamTranscodingBible/FlashPlaybackInOrbOM.png)), while it starts with the official, latest MM7 Flash player plug-in, crashes after about 10 seconds when used from the built-in Internet Explorer (tested on two devices). On Opera Mobile 8.65, it keeps playing; however, it utilizes the CPU at 100% as can clearly be seen in HERE (http://www.winmobiletech.com/122007StreamTranscodingBible/FlashPlayerCPUUsage.png). And, in addition to the huge CPU usage, it also has a major problem: it uses a temporary file in the built-in storage of the device, which will, sooner or later, result in the storage’s entirely filling up and stopping / crashing the machine. A screenshot of these temporary files is HERE (http://www.winmobiletech.com/122007StreamTranscodingBible/FlashPlayerTempFiles.png). Flash Lite 2.1 (https://www.adobe.com/cfusion/entitlement/index.cfm?e=flashlite2%5F1%5Fwinmobile%5Fdownload) is totally incompatible with Orb’s Flash streams as can also be seen in HERE (http://www.winmobiletech.com/122007StreamTranscodingBible/FlashLiteWMIncomp.png).
Under Symbian, it doesn’t even start under the “old” but still official Flash Lite 2 support of Nokia Web as can also be seen in HERE (http://www.winmobiletech.com/122007StreamTranscodingBible/NokiaOrbFlashNo.png).
All in all, under the two mobile operating systems, using the Flash mode is in no way recommended.
Also note that the Winamp .pls format it offers internally just uses WMA streams – don’t think it’s a SHOUTcast-compatible stream meaning compatibility with Nokia Internet Radio / LCG Jukebox on Symbian or with many SHOUTcast clients (GSPlayer etc.) on Windows Mobile.
Two compatibility charts follow, which show the two major mobile operating systems in both NAT’ed and non-NAT’ed (direct) cases:
Windows Mobile:
http://www.winmobiletech.com/122007StreamTranscodingBible/t1.png
Symbian:
http://www.winmobiletech.com/122007StreamTranscodingBible/t2.png
As can clearly be seen, if your connection is NAT’ed, your only choice is WMA (which, incidentally, uses 32 kbps 44 kHz mono (!) sound in the 40 kbps, that is, GPRS setting). This will work on Windows Mobile but, currently, not on Symbian.
All in all, Orb is a decent choice if you have a faster (for example, EDGE or the even faster 3G, assuming you aren’t afraid of the huge battery usage of the latter) connection and/or a non-NAT’ed environment. In these cases, its technical inferiority (the lack of SHOUTcast stream support and, most importantly, the lack of HE-AAC v2 – that is, the only high-quality streaming format for GPRS connections) won’t cause you problems. Finally, it has pretty nice Sirius and XM support. See THIS (http://www.allaboutsymbian.com/forum/showpost.php?p=353195&postcount=7) for more info on the latter.
Let me, however, reiterate its disadvantages again:
if you try to listen to radio stations at GPRS speeds (meaning streams with 32 kbps bitrates max), it’s, audio quality-wise definitely a suboptimal solution and should only be used when you absolutely need to use it – for example, because you prefer its GUI to those of the other players. Why would you want to prefer mono WMA streaming with a lot of compression artifacts when, with other transcoders, you can have excellent, stereo HE-AAC v2 streams without compression artifacts - at the same bitrate? and/or
if you have Symbian (not WM) and a NAT’ed connection (ruling out everything – remember, in a NAT’ed environment, with Orb, you could only rely on WMA, but it’s not supported by the system and CorePlayer’s current version has very buggy streaming support),
you will definitely want to take a look at the SHOUTcast / Icecast2-based alternatives; most importantly, Oddsock.org’s excellent apps.
Note that I’m pushing the Orb folks to add Icecast2-based HE-AAC v2 and MP3 stream support. See THIS (http://forums.orb.com/viewtopic.php?t=9248) thread for more info.
1.4.1.2 Other Orb-related discussion threads of interest
Mobile Phone Streaming Issues (http://forums.orb.com/viewtopic.php?t=4139)
XM and Sirius (http://forums.orb.com/viewtopic.php?t=1833)
SKY.FM, DI.FM (http://forums.orb.com/viewtopic.php?t=9205)
Note that, while the old "High quality" option under 3GP, had a separate checkbox to switch to AAC(-LC); the new, 2beta version has a separate, top-level radio button for this mode. That is, don't let you be mislead by THIS (http://forums.orb.com/viewtopic.php?t=1432), THIS (http://forums.orb.com/viewtopic.php?t=1862), THIS (http://forums.orb.com/viewtopic.php?t=2271) and THIS (http://forums.orb.com/viewtopic.php?t=1860) threads, which still refer to the old approach.
Streaming, additional aac codec (http://forums.orb.com/viewtopic.php?t=2176)
1.4.2 Icecast2-based streaming
The following alternatives all require the usage of an Icecast2 server. (Note that, as an exception, VideoLAN VLC doesn’t necessarily need it unless you stream to a Symbian handset from it. The same stands for WME as well - it's a server on its own.)
1.4.2.1 Icecast2
Icecast2 (Wiki page HERE (http://en.wikipedia.org/wiki/Icecast)) is an open source equivalent of Nullsoft’s SHOUTcast (http://en.wikipedia.org/wiki/SHOUTcast) server, which does exactly the same. There, effectively, there isn’t much difference between SHOUTcast and Icecast2; geeks and other pros tend to prefer the latter; therefore, I also elaborate on it in here, instead of the closed-source, proprietary SHOUTcast.
You can get it HERE (http://icecast.org/). The download links are on the top of the page; if you have Windows, you’ll want to download the icecast2_win32_v2.X.X_setup.exe file. After installation, start it. Go to Configuration / Edit Configuration and edit the file in the following way:
Change the three passwords from “hackme” to anything under icecast / authentication. For example, in THIS (http://www.winmobiletech.com/122007StreamTranscodingBible/IcecastpasswordChange.png) screenshot, I’ve changed all the three to mennpwd. You don’t need to use the same word for all the three passwords.
The number of concurrent streams under icecast / limits / sources. If you plan to transcode more than two streams with a multiple stream-capable source client at the same time, you must modify this parameter too. For example, in THIS (http://www.winmobiletech.com/122007StreamTranscodingBible/IcecastSourceNr.png) screenshot, I’ve set it to 30 so that I can have 30 concurrent, different streams (we’ll see in which cases you’ll find this useful).
After editing, just close the Notepad window and answer Yes to saving it.
Now, when you click the Start Server button, it starts listening to incoming streams as can be seen in HERE (http://www.winmobiletech.com/122007StreamTranscodingBible/IcecastServerStarted.png). You won’t need to do anything else to Icecast2, other than starting / stopping the server if you need it or don’t need it any more.
Note that, by itself, Icecast2 doesn’t stream anything; it needs other clients (“source clients”), whose streams it just relays to the Net. That is, effectively, it uses the famous three-tiered Web application server model already known to many IT gurus, where the listening client equals to the Web browser, the middle tier (the application / Web server) is Icecast2 and the database back-end is, in this case, the transcoding source clients. It’s the stream of the latter that Icecast2, in the middle tier, “just” relays further to the client listener(s).
The streaming clients introduced in the next subsections are all geared towards using Icecast2 as the real streaming server. The only exceptions are:
VideoLAN VLC, which can also operate in a standalone mode (but, then, produce a stream not compatible with some media player clients, including Nokia Internet Radio);
Orb and, finally,
WME, which are also completely independent of Icecast2.
1.4.2.1.1 Mount points
You must be aware of the so-called ‘mount points’. Particularly when you stream more than one radio stations at the same time (in cases, you’ll want to prefer this solution to the others because it frees you from having to remote control the sound source), you will want to know what a mount point is.
When you configure an Icecast2 source client (VideoLAN VLC, Oddsock.org’s apps etc) to stream their contents to an Icecast2 server, you not only pass these clients the Internet address of the Icecast2 server they’ll need to connect to, but also an additional parameter that, later, uniquely identifies the stream: the mount point.
For example, let’s assume you stream two streams to your Icecast2 server from your VideoLAN VLC client. To quickly fire up the streams, you create a batch file with the following contents:
start vlc.exe --sout-shout-name="Iskelmä Radio" --sout-shout-description="Iskelmä Radio (Finnish)" http://217.30.180.250:8050/ :sout=#transcode{acodec=mp3,ab=32,channels=2}:duplicate{dst=std{access=shout,mux=ogg,dst=source:[email protected]:8000/iskelma}}
start vlc.exe --sout-shout-name="Radio Vaasa" --sout-shout-description=" Radio Vaasa (Finnish)" http://webcast.vlp.fi:8000/radioVaasa :sout=#transcode{acodec=mp3,ab=32,channels=2}:duplicate{dst=std{access=shout,mux=ogg,dst=source:[email protected]:8000/radioVaasa}}
Here, look for the iskelma and radioVaasa parameters. It’s there that you tell Icecast2 where to “map” these streams to. If you use these two mount points, you can access (listen to) these streams from a SHOUTcast/Icecast-compliant mobile client (TCPMP, CorePlayer, GSPlayer, Nokia Internet Radio, LCG Jukebox etc.) by simply supplying the mount point after the address and IP of your server like in the following direct URL you can directly enter in any of these players:
http://111.222.333.444:8000/iskelma
and
http://111.222.333.444:8000/radioVaasa
(111.222.333.444 is my desktop computer's imaginary IP address. You'll, of course, will need to provide yours. Use What Is My IP (http://whatismyip.com/) if not sure.)
Of course, prefer defining a playlist .pls file instead of entering URL’s like these into a player to make your life even easier because of the direct file access in most of these apps. The contents should be as follows:
[playlist]
numberofentries=2
File1= http://111.222.333.444:8000/iskelma
Title1=Radio Iskelmä
Length1=-1
File2=http://111.222.333.444:8000/radioVaasa
Title2=Radio Vaasa
Length2=-1
Version=2
(Note that you can leave out the Title and Length attributes. However, if you do so, the current beta of Nokia Internet Radio will crash and will be needed to reinstalled for it to work again.)
You can use any mount point name and you don’t need to explicitly configure the Icecast2 server to know anything about them. That is, you don’t need to tell Icecast2 “hey, I want to use the mount point “mystation”; let me configure you” at all. This is certainly very good news: only the original clients (transcoding the original Internet radios and streaming the transcoded contents to Icecast2) and the mobile players need to be aware of (that is, use) the same mount points.
An Icecast2 screenshot of showing several mount points being in use at the same time, with VLC acting as a streaming client:
http://www.winmobiletech.com/122007StreamTranscodingBible/ManyMountPointsInUseAtthesametime.png
1.4.2.1.2 Connecting to your Icecast2 server
In this section, I elaborate on how streaming clients and mobile multimedia players can connect to your Icecast2 server.
1.4.2.1.2.1 Streaming clients
As has already been mentioned, for a streaming client to connect to Icecast2, it must know the streaming source password (set in the icecast / authentication / source-password), the address: port (127.0.0.1:8000 if it’s running on the same desktop PC) and, finally, the arbitrary mounting point.
For example, in the above-shown VLC batch file,
start vlc.exe --sout-shout-name="Iskelmä Radio" --sout-shout-description="Iskelmä Radio (Finnish)" http://217.30.180.250:8050/ :sout=#transcode{acodec=mp3,ab=32,channels=2}:duplicate{dst=std{access=shout,mux=ogg,dst=source:[email protected]:8000/iskelma}}
the bold text, source:[email protected]:8000/iskelma, contains all this information.
Here, “source” is the username by default for streaming clients like VLC or the Oddsock.org apps. “mennpwd” is the password I use; “127.0.0.1:8000” is the IP address and port number of the Icecast2 server. In this example, it’s running on the local PC; hence the localhost address. Finally, “iskelma”, as we’ve already seen, is the mount point name.
1.4.2.1.2.2 (Mobile) receiver clients
As has already been mentioned in section “1.4.2.1.1 Mount points”, you can either directly enter the URL (of the form http://your desktop computer IP : port (8000 by default)/mount point) into the player or, alternatively, can create a .PLS (http://en.wikipedia.org/wiki/PLS_(file_format)) and/or (preferably extended, so that it also contains the station name) .M3U (http://en.wikipedia.org/wiki/M3u) file with the URL and a description. Note that these playlist files can have several URLs with separate descriptions. (Also note that I only use PLS files as examples in this tutorial because Nokia Internet Radio doesn’t support M3U files.)
An example PLS file having seven entries:
[playlist]
numberofentries=7
File1=http://111.222.333.444:1234/
Title1=Radio Peili
Length1=-1
File2=http://111.222.333.444:8000/iskelma
Title2=Radio Iskelma
Length2=-1
File3=http://111.222.333.444:1236/
Title3=Arkisto
Length3=-1
File4=http://111.222.333.444:8000/radioVaasa
Title4=Radio Vaasa
Length4=-1
File5=http://111.222.333.444:8000/rspo
Title5=RSPO
Length5=-1
File6=http://111.222.333.444:8000/klf
Title6=KLF
Length6=-1
File7=http://111.222.333.444:8000/rhesa
Title7=Radio Helsinki
Length7=-1
Version=2
Note that it has two non-8000, that is, two non-Icecast2 ports: 1234 and 1236 in the first and third records. I’ll elaborate on this a bit later, in the VLC section. All the other URL’s point to the same Icecast2 server with, of course, different mount points.
Colleting your favorite stations into one PLS file is pretty much useful because, then, it’ll become far easier for you to switch between the radio stations after opening the playlist file. For example, the above PLS file is rendered by Nokia Internet Radio the following way:
http://www.winmobiletech.com/122007StreamTranscodingBible/NIRPLSPlayListContents.png
By TCPMP, this way:
http://www.winmobiletech.com/122007StreamTranscodingBible/TCPMPPLSPlayListContents.png
and, by CorePlayer, this way:
http://www.winmobiletech.com/122007StreamTranscodingBible/CPPLSPlayListContents.png
Note that the two latter apps automatically start playing the first station in the playlist (Nokia Internet Radio doesn’t); if it’s a problem, you will want to separate your stations in separate PLS (or M3U) files. Also note that you can transfer these streams to your built-in "favorite" playlists in all these radio clients. Then, you won't need to click / import PLS files more than once.