SqueezePlayer

Some people are requesting me to provide an option to start SqueezePlayer automatically on startup.

Well actually this is already possible now as Android is a very cool an open platform, so I decided to write a small tutorial about how to achieve what you want.

The easy way “Automate It”

There is a very cool (free) application on the store called “AutomateIt” .
It allows you to automate almost everything on your devices – and this also includes automatically starting Apps at boot time.

There are several other Apps on the store allowing similar things, but AutomateIt beats them all, as it is sooo intuitive, one cannot believe it.

So just start this App, and tap “Add New Rule”. You are asked for a “trigger” where you just need to choose the autostart trigger.
The App then asks you for an “Action”, where you choose the “Start App” action. You will be presented a list of Apps and SqueezePlayer will be among them.

Final step is giving your new Rule a name – called it whatever makes sense to you, DONE !

Well now this was the easy part – be warned – the next two hours you will play with all the other features of AutomateIt.

This solution has one caveat though: The SqueezePlayer App main screen will be visible after you boot …

More Advanced “Tasker”

Tasker is an App like AutomateIt. Looks more clunky, but is much more powerful. It also costs a little bit, but if you want to get rid of the main screen of SqueezePlayer after booting up, I’m not aware of another possibility right now.

The steps are actually the same: we will need to configure a trigger (i.e. “at boot”) and an action/task (i.e. “start SqueezePlayer”).
As the action, please choose “Misc -> Send Intent”. We will use this one to automatically start SqueezePlayers hidden service (opposed to the mainscreen).
Such Intents do have a lot of field, you only need a few:
Package: de.bluegaspode.squeezeplayer
Class: de.bluegaspode.squeezeplayer.playback.service.PlaybackService
Target: Service

DONE!

Once you get the hang of it, it’s really to setup different things as well.
Some users for instance don’t like that SqueezePlayer shuts down after 15minutes on batteries. With Tasker you can send the Intent  every 10 minutes, SqueezePlayer resets it’s 15min shutdown timer then.

I’m often asked, if I can make SqueezePlayer work on GoogleTV / the Logitech Revue.

Unfortunately this is a very complicated story and I’d like to share some details (and a possible solution in the end).

The mysterious “NDK” SqueezePlayer uses an Android feature called “NDK” (native development kit). It essentially enables me to write ultra fast code – which is needed for the FLAC decoder. SqueezePlayer wouldn’t run on devices like the HTC Wildfire (just 500Mhz CPU) or Sony XPeria Mini if I didn’t use this technology.

Google TV and the “NDK”: GoogleTV unfortunately does not (officially) support the NDK. (see here: https://developers.google.com/tv/android/docs/gtv_android_features#NDK).
In the past (with their very first firmware version) this was a little bit understandable: Google TV runs on Intel processors while every smartphone/tablet is based on the ARM technology. The NDK (being ‘native’) is very picky about the platform it runs on and for a very long time the NDK did not run at all on Intel processors.
But it does for a while already – and personally I’m really clueless why Google just failed to include it for their own GTV.

SqueezePlayer and Intel: SqueezePlayer does run on (other) Intel based Android devices (for instance the Intel based O2 Joggler can run on Android:  http://en.wikipedia.org/wiki/O2_Joggler). Which shows that there isn’t actually a problem on the Intel platform – it’s just that GTV does not support it.

So as a conclusion: right now there is absolutely no chance for me to make SqueezePlayer compatible with the stock Revue.

So what can we do know?
Well there are some options:

#1: waiting. *sigh*. I have no clue if this is a good strategy 🙁 … Logitech dropped the Revue line altogether meantime.
And it looks like all GTV successors that are still in the game now abandon the Intel platform and use ARM again.
Which in my opinion makes it unlikely they will care for Revue anymore.
Anyway: call their support – make them hear you!

#2: hacking. The Revue can be “rooted” (i.e. you get full access to the operating system). And: some people brought the NDK even to GTV! *yeah*

Instructions can be found here: http://gtvhacker.com/index.php/GTv-OS_(AndroidTV)#NDK_Support

As I don’t have a GoogleTV I cannot try it myself – but would be happy to know if any one of you could make it work.
So far I don’t know anyone who tried it at all – but I’d love to hear from your experiences!

I’m often asked, if SqueezePlayer supports synchronisation to other Squeezeboxes.
And unfortunately I always have to answer “it depends on your particular device”.

With this post I want to give some background information about the whole topic and on the bottom I’m going to compile a list of devices that are known to have a working synchronisation to other Squeezeboxes. Be aware that I don’t consider this list to be a guarantee to you that synchronisation will work – too many influencing factors (your network stability, Android version) are still left.

If you tried out synchronization yourself on your device, don’t hesitate to report back, so that I can update this list.

Background information

SqueezePlayer supports the full synchronization protocol for SqueezeBoxes, so actually it should always work, BUT good synchronization (among others) mainly depends on two things
a) a stable clock in the device (i.e. 2 seconds of music shouldn’t have finished playing after 1,98 seconds)
b) exact information of what music frame is played right now (as this gets send back to the server who negotiates what devices should catch up).

Logitech with their Squeezeboxes is in complete control of both – they have their own firmware and dedicated audiodrivers in their boxes come along with very good DACs. Also the iPad hardware is marvellous in the regard by the way. My iPad App “SqueezePad” even mentions synchronization in the App description (and it is based on the same code-base by the way).

Android unfortunately is a very different beast. Every hardware manufacturer decided himself what to put into the device – and obviously not everyone cares for good and reliable sound chips (compromising requirement #a) and as they have to provide their own audio drivers there is also a risk, that they compromise requirement #b.

Also not many people will realize that, as the local player keep playing fine, so there is also no real motivation for manufacturers to care a lot for audio.

One more thing two know: The actual synchronisation protocol does have two steps:
Step one is, that synchronized streams are tried to be started at the same time. That means each device downloads portions of the songs, has to flag a “ready” flag and all get a “go” command at the same time. Then it depends on how fast a device can react onto this “go” signal (and Android sometimes is not the fastest to do so).
The second step is constant synchronisation: each synchronized device reports it’s current playback position. When the server realizes that one device is behind it sends a “skip some milliseconds” signals to get devices back into synchronized play.

It’s important to know the consequences: even if songs didn’t start in sync perfectly – let your devices play some seconds (up to 30 seconds) to check if they will get in sync still. As long as you don’t wipe your playlist they can keep the sync.

OK – enough talk – here is the compiled list of devices that have a high probability for working sychronisation:

Devices reported to be having good synchronisation

My own devices:

• HTC Desire
• HTC Wildwire
• Sony XPeria Mini

http://forums.slimdevices.com/showpost.php?p=674072&postcount=333:

• HTC Dream (G1)
• HTC Nexus One (N1)
• Samsung Galaxy S2
• Asus Transformer tablet

http://forums.slimdevices.com/showpost.php?p=670410&postcount=317:

• Motorola Xoom

http://forums.slimdevices.com/showthread.php?p=664600

• Motorola Charm

by mail:

• Droid X

AppStore or Blog Comments

• Galaxy Note
• Samsung Galaxy Tab 10.1
• Samsung Galaxy S
• Samsung Galaxy Nexus
• Samsung Galaxy Note 2
• Sanei N10 tablet
• LG Optimus T
• Lg Optimus Speed
• LG VM670
• Nexus 7
• Sony Tablet S SGPT112
• Acer Iconia Tab B1
• Sanei N10

If you followed all previous chapters you will have a rock solid remote streaming solution ready by now. Congratulations!

Now lets start to talk a bit about security and then you will need to decide, if you want to go on.
The following steps and considerations are optional (but probably worth it).

Our current solution has two possible flaws:

• your username and password is sent over the internet unencrypted. If someone can catch your wireless traffic (maybe your are using a public hotspot sometimes?), analyses the traffic and extracts the username/password (can be done with automated scripts very easily) he is able to log in into your Squeezebox Server as well and change your settings or remote control your other Squeezeboxes.
  Even worse: if you were lazy and used the same credentials as your Facebook or email account, well … I guess I don’t need to write on 😉
• Your Squeezebox Server is accessible from the internet to anyone. There is some tiny possibility someone can hack into this Squeezebox software and might take over your server.

Why might anyone want to hack your server you might ask?
Definitely not for controlling your Squeezeboxes I’d say – but there are many people out there that want to setup some new servers to send spam or do other illegal stuff.

How can we protect against this?

There are two common techniques to create a much more secure channel. One is called ‘OpenVPN’ – some routers support that and your mobile might be able to create a secure ‘tunnel’ through the internet to your router. Due to it’s complexity I won’t go into further details here, Google will be your friend.

Another possibility is to create a ‘SSH-tunnel’. SSH is a technique to connect via an encrypted channel to your server. If you are using a Linux based NAS or server you might already have used it to log in into your server (if you ever used the tool ‘Putty’ on Windows, you are on the right track … )

The good thing about SSH – it can also forward specified ports, which is perfect for our needs.
So from now on I expect you to have a server where you can already login with SSH.

• Update your port forwarding in your router. SSH uses TCP port 22. Any connection from the internet to this port should be forwarded to your Squeezebox-Server.
  You can delete the port forwards  9000 and 3483 on your router, we won’t need them anymore.
  These were insecure so let’s get rid of of them. 

  Is  SSH on port 22 more secure than Squeezebox-Server on port 9000+3483 you might ask?
  And the answer is: definitely – thousands of administrators around the world use SSH around the clock to remotely connect to their respective servers 🙂

• Download an App that can create a SSH tunnel with port forwarding.
  Um, well.The only viable option on the market ‘connectbot’ has a bug so it sort of works with Squeezebox-Server but has it’s issues. This issue with ConnectBot seems to be resolved on Honeycomb by the way, but on Android devices below tracks in a playlist are not advancing, when a song is finished.
• Even better might be SSH AutoTunnel and one user reported succes with it in the comments section. It might suffer from the same problems as ConnectBot on pre Honeycomb Android devices (though this has not been verified yet). I’d go with this App first!

  Both ConnectBot and SSH AutoTunnel allow you to connect to your SSH server first. Try if you get a connection. After it has been established within Connectbot or SSH AutoTunnel do configure port forwardings for port 9000 and 3483 before trying with SqueezePlayer (read below what to do in SqueezePlayer).

• Another option ‘SSHTunnel (Beta)’ only allows a single port to be forwarded (and we need two).That’s why I wrote my own App ‘SqueezeTunnel’ to care for all the common Squeezebox-SSH-Stuff. You can download it here.  Attention: your Android device needs to be rooted, for this tool to work (it comes with it’s own SSH client and wants to install it). Also this App is a quick hack/port of SSHTunnel and most of the SSH related code from the original I don’t understand 🙂
  As SqueezeTunnel is a fork of the ‘SSHTunnel’ project protected by the GPLv3 license, you can have a look at the source-code of SqueezeTunnel here.

Here is what you need to configure in SqueezeTunnel once you installed it.

• Host: your dyndns URL (see Part 1 for details) i.e. wow-my-server.dyndns.org
  Via this URL SqueezeTunnel is able to find your router and create the tunnel.
• Port: 22 is the default port for SSH
• User/Password: your username/password to login with SSH. This is NOT the username/password you entered in the Squeezebox-Server web-interface. It’s rather the username/password you need to enter, when you connect to your server via SSH.
• Squeezebox-Server Port: typically 9000. But you can change it in case it’s different in your setup.

Now try to create the tunnel with the topmost item ‘Enable/Disable SSH Tunnel’, you should get a new icon in the status bar, hopefully saying ‘connected’.

Now we need to configure SqueezePlayer to use the tunnel.
As the server-address in the SqueezePlayer settings just use ‘localhost’ instead of the DynDNS-URL we used before.

Yes this might sound strange – but the tunnel starts directly on your the AndroidPhone so we don’t need to look elsewhere this time. SqueezeTunnel which should still be running in the background will then take care of the correct encrypted routing through the internet to your Squeezebox-Server.

By the way: you can remove the username/password in the Squeezebox-Server settings now. They won’t give us any more security, the username/password used to establish the SSH connection are much much better and secure.

I really hope this last chapter was not too complicated to understand and you could get great inspiration about making your remote streaming very secure.

So your first test with streaming are working after you finished Part 3, ey?
Or do you face buffering issues already?

Let’s look at the last missing piece for a good setup!

All your music needs to travel back trough the internet from your Squeezebox-Server to your mobile or tablet.

First hurdle is your Internet Service Provider: Did you ever notice that sending a mail with a lot of pictures takes MUCH more time than to download the same amount of data?
For instance if I buy “DSL 6.000” from one of our German providers, I get ‘up to’ 6.000kBit/s downstream (i.e inbound) traffic, but they guarantee only ‘up to’ (haha) 576kBit/s upstream (outbound) traffic.

And that’s where your music wants to pass. Good enough for mp3, but a 44/16 FLAC is having much more bits.

Second hurdle: your mobile carrier. With different technologies (GPRS, EDGE, 3G, HSDPA) you get different speed – from as bad as 56kBit/s up to 56MBit/s.

How to cope with this?
Fortunately Squeezebox-Server is an awesome beast and can help us with it’s option ‘bitrate limiting’. If you activate that, the Server will transcode your music on the fly to your desired bitrate – doesn’t matter if it’s FLAC or high quality mp3s => you music gets crunched to whatever can go through your wires.
This can be activated only for SqueezePlayer, so the streaming to your other Squeezeboxes is unaffected.

To find this option, enter the web-interface of the Squeezebox-Server, open the settings page and move to the players audio settings:

For this to work you need to install the LAME encoder on your server.

Now the bad news: if you are running the Squeezebox server on lower CPU device (e.g. a NAS or SheevaPlug), the LAME plugin will not be fast enough to convert your files to the desired bitrate.

On the Squeezebox-Wiki you can instructions about how to install a much faster transcoder: Shine for Transcoding.

In Part 2 you configured your router so that it will route outbound traffic to your Squeezebox-Server.

This is very nice as you can now stream music BUT: anyone else will be able to do so as well.
Even worse: via port 9000 anyone can remote control your Squeezebox Server.

So don’t get annoyed when someone starts your music in the middle of the night 😉

Weeeelllll …

OK

Not so nice.

Let’s do something then, that this will not happen!

I’m sure you know that your Squeezebox server has a web-interface? And that there is a huuuuge settings screen? And that you can enable password protection there?

If you never saw it – you will find it under ‘Advanced -> Security’:

PLEASE – use a username and password that is unique (NOT your GMail, Facebook or Twitter account).
This username and password will be transferred unencrypted through the internet 🙁 – so there is a possibility someone else will catch it.

I’m not very happy Logitech calls this page ‘Security’ because my definition of security is a bit different – but well … this type of protection is better than nothing at least! We will take care of better security in Part 5 – then we can turn off the Squeezebox-Server ‘security’ again, as it’s not needed anymore.

All your Squeezeboxes will ask you for username and password of course now (just enter them once).
Also SqueezePlayer wants you to configure username and password on it’s setting page, so don’t forget to enter them there!

Next step is to care about bandwidth limiting in Part 4.

Part 1 showed you how to make SqueezePlayer knock on the doors of your router. Unfortunately routers are very picky: typically noone is allowed to get in, as the main task of routers is to protect your Home Network from the Big Bad Internet.

That’s why we need to tell your router:

– it should allow SqueezePlayers traffic to come in
– and route it directly to your Squeezebox Server

If you read the first part you might remember me talking about moving targets.
Also the Squeezebox-Servers IP address is changing in most setups. Typically not very fast, but once a month or on a restart it’s not uncommon with some routers.

So let’s cope with this first!
All modern routers are able to assign static (i.e. never changing) IP addresses to the devices of your network – if you just tell them.

The magic word you have to search for on your routers web interface is ‘DHCP reservation’. Here you can enter devices and configure their static IP. When this is done it might look similar like on my router:

You see I have some more devices on my network. This table is actually very easy to read.
A device  is typically identified by it’s ‘MAC address’ – and then the router is just told what IP address to give this device.

Where to get these values from?
The MAC address of your Squeezebox-Server is the hardest. But there are good tutorials out there and I love this one as it has a lot of screenshots.
As IP just take the one your server is having right now: if you have connected SqueezePlayer via WiFi it will show you the IP in the ‘server’ field.

Now that your router is always having the same address, here comes the easy part: tell your router to forward all traffic from an outside SqueezePlayer to your server.

Search the webpages of your router until your find a section ‘Port Forwarding’.
You need to forward port 9000 and 3483 (both TCP) to the IP of your server.

Typically this is done by configuring two rules on your router, here is how the page looks on my router as a reference:

Done!

If you did everything right, SqueezePlayer should now be showing ‘Connected’ when using 3G.
Also mp3s should be playing fine already – if you have a FLAC library we need to do some more steps.

Please continue reading Part 3. We opened your Network to the outside world – and you should setup at least the bare minimum of security!

One of the first things to do is to make SqueezePlayer connect back to your network.

Whenever your router connects to the internet, unfortunately every time it get’s assigned a new IP address by your Internet Service Provider (ISP).
So effectively your home network is a moving target from the perspective of SqueezePlayer – let’s find a way to pin it down!

The standard solution to our problem is to use a service (like DynDNS.com – must be supported by your router, there are others) that gives you a static name on the internet. When your register there (DynDNS is not free anymore, try no-ip.com instead) you can choose a name, which will be your own unique address on the internet, like ‘wow-my-server.dyndns.com’

Now your router works together with this service: everytime it get’s a new IP address signed, it tells this service ‘hello – did you know – you find me HERE’ …
And when you then call the address ‘wow-my-server.dyndns.com’ you get routed back to your home.

It’s like in real live when the kid says to mummy ‘if daddy asks, please tell him I’m at [put in some place]’.
Always on the run, but when well trained (almost) always easily findable.

Clever ey?

So let’s set this up on your router – it needs to tell DynDNS.com where it can be found on the internet. Unfortunately this is highly dependent on your router, click through all it’s menus until you see the words ‘Dynamic DNS’ or ‘Dyndns.org’.

To give you a clue – here is how it looks on my DLINK router:

As you can see you have to choose what service do you want to use (there are others than DynDNS.org), your address you reserved with them and the username and password of your account over at DynDNS.org.

Phew … the final step of course is to tell SqueezePlayer this new address as well.

On the settings screen under the option ‘Squeezebox Server’ choose ‘manually enter address’ and in the new option ‘Manual Server Address’ enter the new name of your home: ‘wow-my-server.dyndns.com’.

We are finished now with your first step: SqueezePlayer will now find your router through the internet, yeah!

If you don’t want to give up yet … follow me in Part 2.

Via WiFi SqueezePlayer directly connects to your router which is connected to the Squeezebox server.
This is a rather simple setup, but still very versatile as you can walk around with your phone or tablet anywhere you are in reach of your own WiFi network.

But what about listening to your music in your car, at work, at college or school?
Well just connect via your mobile connection, but …

alas – now it looks much more complicated!

As you can see, your music needs to travel a long way now (through something call ‘THE NET’) and there are some obstacles to be cared of.

This multipart tutorial will help you to get things set up, but here is the short version.
If anything is not clear to you: follow the links to read an indepth tutorial about each needed step.

Part 1: Make SqueezePlayer find your home network
Typically you need to setup a service like DynDns.org on your router, so that it tells this service where it can be found on the internet. In SqueezePlayer you can then configure a name like ‘myserver.dyndns.org’.
You will also need to tell your Controller App (i.e. SqueezeCommander) this new address.

Part 2: Make your router forward traffic to your Squeezebox-Server
SqueezePlayer wants to talks on ports 3483 and 9000 with your server. Make your router forward these ports.

Part 3: Secure your server

Activate Password protection in your server, otherwise anyone on the internet is able to control your Squeezeboxes

Part 4: Reduce the bandwidth to get robust streaming.

Typically DSL doesn’t have good upstream capabilities. Squeezebox-Server allows you to setup bitrate limiting, so any song will be transcoded to an appropiate mp3 stream that will make it’s way from your network through the internet to your Android device.

Part 5: Secure your communication channel

Think about setting up a virtual private network, to make your setup even more secure.
Another option is to setup a SSH tunnel (also called ‘poor mans VPN’)  which we will do in the final chapter.

Up until now SqueezePlayer could only stream MP3 and PCM.

This was enough, as the Squeezebox server can translate any other stream into these two formats. But this is not very CPU efficient nor does your network really like streaming uncompressed PCM streams.

So I took some more nights to implement a FLAC decoder for SqueezePlayer.
FLAC is a lossless format but it needs only 50% of bandwidth in your network, so is the preferred format of the Squeezebox-Server when it wants to send uncompressed data to a Squeezebox (or SqueezePlayer of course).

Along with the decoder some other new features have been implemented:

• support for media-buttons (play/stop/prev/next) if one connects headphones having those buttons
• display is allowed to go off now, saving you some battery life
• new setting ‘observe headphones’: if you want to stop playback when you unplug your headphones
• experimental support for synchronization: songs won’t drift apart anymore when SqueezePlayer is synchronized to a Squeezebox.
  Be aware that (in my experience) Androids sound system is a little mess: high latencies and inaccurate timing might spoil your experience, so whether this feature works for you is very device dependent.

Enjoy!