SqueezePlayer

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.

Here is an additional article how I used the servers setting of “Player Start Delay” and “Player Audio Delay” to get a good sync even with devices with greater inbuilt delays: https://forums.slimdevices.com/forum/user-forums/general-discussion/96569-android-tv-sticks-boxes-as-squeezebox-replacement

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

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!

Since February I’ve been working on this project, spending my nights to make my phone even more versatile.

Now SqueezePlayer is ready to be released in it’s very first version, and I’m excited to finally go life with my very first App on the Android market.

I did have some experience with SqueezeBox playback because I did the same for my iPad-App ‘SqueezePad‘.
I had hoped I could reuse a lot of what I had written already: but in the end it turned out that SqueezePlayer needed to be a full rewrite.

So how comes?

Well: first coding for Android is done in a completely different programming language.
But even more important: Androids sound system works totally different to that of iOS devices.
Unfortunately ‘different’ here means: it’s absolutely down to the minimum one could expect from a sound library.

In the shiny (well from a programmers perspective) iOS world you just say: “Hi sound library – this is my mp3 or AAC stream: go on and just play it!”
On Android I head to learn: the sound library says: “Well – if you want to stream something – please convert everything to 16bit stereo WAV first, I don’t care for your compressed music”.
Which means along with the not too easy Squeezebox networking stuff  now one has to dig into decoding mp3 streams, arrghhh …

After finishing my first version, which streamed nice on HTC Desire I send it to my first Beta tester (HTC Legend) who then said: “doesn’t work, my phone gets dead slow”. Bummer … my Desire has a 1Ghz CPU, the legend ‘just’ 528Mhz. So back to programming, not only implementing an mp3 decoder, but a FAST mp3 decoder …

To make a long long story short: it was an interesting ride indeed, I learned a lot and if I had known before – the SqueezePlayer project maybe never would have been started 😀

But here we are … so enjoy like I do now!