So here’s the scenario.

We’ve got this handy system called the Whole Home Audio system, and it allows us to play networked music to a number of physical and virtual zones.  We can use it to play music in the basement, or in the family room, or even in a car doing 100+ km/h on the highway.

Without question the physical zones are cool.  The family room zone is the coolest, since I can use my (dying) Harmony universal remote to issue transport controls and the system will respond accordingly.  That’s a pretty nice example of bridging hardware and software; in the family room, the nature of the audio system is completely* hidden.

* (the caveat is that, currently, you can’t select anything to play if nothing is loaded on that zone.  Minor issue, but I’m mentioning it in the interest of full disclosure).

The basement is somewhat unique in that the volume controls exist in the home audio interface, so you mash buttons on the interface page to increase/decrease volume.

In both cases, being physical zones, the requirement exists that we have sound hardware in the server to pump analog audio to the zones, and obviously, that there’s a physical connection between this sound hardware and the amplifying sound hardware at the destination.  This has worked for the basement and the family room, due to their proximity to the server.

The master bedroom, on the other hand, has never gotten to enjoy this sort of seamless/impressive hardware/software bridge.  It has always relied on a streaming client – functionally equivalent to my phone, or WinAMP on my work computer – to stream music through the floors and walls.  The streaming client in this case is GSPlayer running on a no-longer-used-but-still-loved PocketPC PDA, which itself is connected to a 2.1 speaker setup.

So playing anything to the master bedroom has meant:

1. Play something to a particular zone – usually streaming zone 3
2. Turn on the PDA and mash the play button repeatedly until WiFi connects and GSPlayer connects to the streaming zone
3. When your musical enjoyment has ended, power off the PDA

This works, but it’s less than convenient.  And as you can imagine, I wouldn’t be posting about it here if I didn’t come up with a solution.

And so, fresh off of my success with GSPlayer modifications, I once again delved into GSPlayer’s inner workings and gave it the ability to accept incoming TCP/IP connections.  That was part 1.  Part 2, was to give the home audio system the ability to connect to said GSPlayer and tell it to Do The Damned Thing(tm).

Okay, I’ll explain.  The idea here is that the user should only ever have to interact with the home audio interface/system when it comes to selecting joints and loading a zone.  You can use controls at the zone to control playback, once started, but starting playback should itself be a homogeneous process.  So obviously, pressing play on a home audio interface page, then powering on a PDA and pressing play repeatedly… well, that didn’t cut it.

The fact is that it’s the home audio system which receives your request to load a zone, so armed with that knowledge, it should be able to do Whatever Is Necessary(tm) to complete that request.  For the family room and the basement, this culminates in WinAMP being loaded with relevant song data and audio suddenly starts to stream out of the respective speakers.  Streaming zones will always* require a two-step process, and that’s to be expected given their nature.

* (there may be exceptions to this in the future; see this post for one example)

So yes, it’s true that the master bedroom needs to rely on a streaming zone since its physical proximity to the server can’t be (easily) overcome.  However, as a user of the system, your perception is that you’re at home, you’re in a static environment (ie, a room) and therefore you consider it a physical zone and hence you want it to behave as such.

Back to the technical stuff.  The GSPlayer modification allows the home audio system to tell the PDA to connect to the streaming zone and start playing.  And in a nutshell, that’s the crux of it.  You load the master bedroom zone using the home audio interface, and the system loads WinAMP and tells the master bedroom to connect.  The PDA must stay powered on all the time in order for this to work, but that’s trivial – much as the basement amp must be powered on to play music in the basement (it’s always left turned on).

Now, in practice, there were many considerations that had to be dealt with in order for this to work as expected.  A third component had to be modified – specifically, the WinAMP general purpose plugin that’s currently used to give certain feedback to the home audio system.  That plugin, being intimately tied to the guy that actually plays music, is the ultimate source for information on what’s happening.  And for the master bedroom, I decided that we wanted the “start playing darnit!” notification to be event driven and fired by the guy who knows when playback has actually started – ie, WinAMP, ie – the WinAMP plugin.

There are timing issues that help to lead one to this logical conclusion as well – as I said, there were many considerations.  But conceptually, the event-driven (ie, WinAMP-plugin-driven) approach it makes the most sense.  And the things that make the most sense are usually the things that are easily capable of resolving related, niggling issues.

So here’s what happens.  You select some Brian McKnight and send it to the Master Bedroom zone.  The home audio system goes through the motions of sending a playlist down to WinAMP.  WinAMP may churn and burn for a while, but we don’t care – nothing happens until WinAMP starts playing.  Once WinAMP does start playing, the plugin fires an event back in to the home audio system.  The system parses this, determines that the Master Bedroom has an “RPC-capable” client, and sends a suitable command to said client.  The client – GSPlayer in the master bedroom – gets the command to start playing and connects to the appropriate streaming zone.

And Bob is your uncle.

Once playback stops on the zone, GSPlayer will disconnect since the stream has stopped.  Or, if you’re no longer jonesing for Mr. McKnight, you press stop in a home audio interface page, and the system sends a command to GSPlayer to stop playback immediately – vs. waiting for the streaming buffer to empty.

So most of this has been tested successfully.  Today I cleaned it up and “properized”  it, so I’ve still got to make sure it works exactly as expected.  I may – or may not – post back here with my results 🙂

Time sure is flying.  Sometime in spring I made tentative plans to see “The Expendables” with a friend in August.  At the time I thought that the date – August 13th – was soooo far away.

Ya, right.

I’m not here to bemoan the rapid passing of Time though; I’ll leave that for another entry – which may or may not ever get written btw.  No, I’m here to continue the chronicle that is my Whole Home Automation journey.

Now, I can’t say that the scope of the project has changed.  It’s still limited to audio and surveillance.  On the surveillance side there’s not much to report; occupant detection is working, and although I haven’t hacked any USB Bluetooth dongles I can also say that the system is working acceptably as-is so I’m in no rush to change things.

On the audio front it’s been a case of small updates and bugfixes here and there.  One of the bigger useability updates has been to allow the download of a .zip file of select tracks.  This makes it easy to download a selection of tracks to a local device, or download an entire album to Shelly’s phone.  It’s not something that I’ll use often, but it’s nice to have.

Something that should be more useful for me, however, is a project I just completed that’s physically removed from the system at home – but interacts with it nonetheless.  I’m talking about playback of streaming zones, and in particular, playback of streaming zones using _my_ Windows Mobile smartphone.

Here’s the scenario.  I’ve got some tracks queued on a streaming zone.  I hop in the car, connect to home, and start playing that zone through my phone (and obviously through the car stereo).  Then I hit a joint that’s bangin’ – or lame – and I want to repeat that joint or skip it altogether.

Traditionally this has been possible, but it meant having a browser open on the phone and connected to the zone page for the streaming zone in question.  You press a transport control on the webpage, and some seconds later (up to 15 seconds in some cases) the streaming buffer gets around to reflecting the changes.

“Wouldn’t it better”, I wondered, “if you could use the player’s transport controls to control the zone directly?!?”

Yes, it would.  And so now it is.

I toyed with the idea of writing an app from scratch.  And while this is something I may still do, the opening lines of this entry are quite clear in this respect: Time is at a premium.  Sometimes you have to settle with something that works rather than something that’s perfect.  It’s not a mantra that I usually adopt, but in some cases – as with the Bluetooth dongle – it’s acceptable.

So as it turns out, GSPlayer is open-source.  It’s a player I’ve used in the past, and I think that I passed it over in favour of PocketMusic because the latter is purtier and has bigger buttons.  But if the buttons aren’t useful, then who cares?  That, and PocketMusic has some stability issues – to the tune of often requiring a soft-reset of the entire phone.

Anyhow, I modified GSPlayer and captured transport control events so that it will send RPC commands to the backend server.  So if I press the “next track” button in GSPlayer, it will tell the backend to move to the next track.  It will also disconnect/reconnect the stream to make sure the streaming buffer is cleared.

And of course, it only does all of this if a stream is active *and* that stream appears to be connected to my server.

So ya, that’s that.  I did a quick test on my phone and it seems to work.  I’m off to run a few errands shortly and I’ll do the trial-by-fire at that point.