Last time I was here I talked about a custom modification that I had made to GSPlayer – an MP3 player on my WinMo smartphone – to allow limited, transparent control of a Home Audio streaming zone from within GSPlayer itself.  And it has proven quite handy.  The first trial went well, but then I was dismayed to discover that the stream was skipping.  It wasn’t happening regularly, and it would only skip for about 0.5 seconds each time… but it was enough to be noticeable.

I was beginning to wonder if perhaps this was the main reason why I had switched from GSPlayer to PocketMusic.

Perhaps I’d have to dig into the code.  But after thinking about it overnight it dawned on me that this may be a simple buffering issue.  It wasn’t behaving strictly like a buffering issue – the display wasn’t showing that the player was rebuffering, and it wouldn’t make sense that it would take 0.5 seconds to rebuffer each and every time – but what the hey, I figured it was worth a shot.

So I up’d the buffer from 128k to 1024k (1MB) and that seems to have fixed it 🙂  The prebuffer is still 32k so playback begins just as quickly as before.

Anyhow, everything up to this point has been a digression.  But I mentioned it all because; 1) it’s related, and (2) when taken with the real intent of this article, it serves as a nice illustration of the logical progression of this sort of project.

So… here’s what happened last Friday.

I left work, and decided to play some songs off the flash drive.  But after 5 minutes or so I decided that I would rather listen to the queued tracks on a streaming zone.  So I connected my phone to home and started playback, only to realize that music was coming out of the phone’s speaker itself…???  As it turns out, the USB drive was still plugged in under the armrest meaning the Bluetooth music gateway was not.

Well that certainly sucked.  And while it would have been physically possible to remove one and insert the other, there were two overriding thoughts which nagged me incessantly:

1) Those cables are inconvenient to reach, especially when driving

2) Why should I have to physically switch anything???

So on that Friday I decided to listen to nothing at all for the duration.  But the experience served to solidify and accelerate an idea I had from the very moment I decided to power the gateway off the USB port – which was, to split the port so I could power the gateway and leave a flash drive connected at the same time.

Normally you’ll find USB cables that wire two ports in parallel for the purposes of drawing combined current from both ports.  Only the power wires are connected together; the data wires are connected to one port only.  This allows you to connect devices that might exceed the 500mA that a single USB port can provide.

In my case, I needed a cable that could take one port and split the power to two USB devices, while again providing data connectivity to only one of those devices.  And I figured I’d be okay in the power department, since people regularly power USB hard drives off their BMW USB ports without issue; certainly a lowly flash drive and bluetooth A2DP adapter would be less power-hungry than a hard drive.

After looking around for a suitable cable it became apparent I wouldn’t find one.  I would have to make one myself.  And while I had a spare USB-to-mini-USB cable that I could hack (which would provide power to the A2DP adapter via mini-USB) I had no USB cable with a male plug on one end and a female receptacle on the other.

As luck would have it, I found just such a cable this weekend… for $2!  Perfect price.

So I spliced in my other cable and I’ve now got a 6″ USB extension with a spliced-in 2.5′ cable ending in a mini-USB connector.  I did multiple tests along the way to make sure that everything would work.  And once in the car, everything worked.

One comment I have to make – the wires inside said cables are t-i-n-y.  I had to use an X-acto knife to slice the sheathing off, and in 10 cuts I think I managed to sever one strand.  And because the wires were made up of 5 or 6 such tiny strands, I had to tin them with solder.  After twisting them together I soldered them again to solidify the splices, wrapped each splice individually in electrical tape, and then wrapped the whole shebang with more tape.

So there it is – I can play tunage off the flash drive or off the phone without having to reach under the armrest.

The particular flash drive I’m using – an 8GB Kingston C10 that I scored for $20 off Dell – is loaded with all the tracks from my “fav’s” list on the Home Audio system.  Syncing the two is fairly trivial, and in the process the system generates genre playlists since… well, I’ll explain.

Some of my tracks have “compound” genres.  For example: “R&B/Reggae”.  While the car has the ability to read these genres, the problem occurs when such a track is not listed in the R&B genre or the Reggae genre.  Personally, I’d want it to be listed in both.

The solution therefore was to gen my own playlists – which the car can read – and make sure that the track is listed in both playlists.  Done – this occurs during the syncing process.  This also allows me to group other genres – Dance, House, Techno, Electronica all get grouped as Dance – so that I can play them all while still keeping the original genres intact (and indeed, the sync will gen playlists for the original genres but name the playlist as, say, “Dance (House)” for house tracks)

So that’s cool.  But you know me, always wondering what the next step can be.

Here’s the thing – the car can control iPod’s and, apparently, certain other MP3 players.  How does this work, this “control”?  For the iPod I believe it’s a special set of code specifically designed to work with the iPod and act as an interface for the iPod.  But for all other devices, the car looks at the device as a storage container housing tracks.  Those devices can either be a Mass Storage device – so, a USB flash drive – or they can be a Media Transfer Protocol compliant device.

The difference between the two is  down to semantics, at the higher level at least.  Again, the car sees both as a storage of files.  In the case of Mass Storage, the device is a drive that the car mounts.  When you want to play a track the car opens the file and reads the data off the drive.  In the case of MTP, the car queries the device via MTP commands; when you want to play a track, the car asks the device for the data and the device sends it over.

So you can see that, to the end user, they both seem to operate the same way.  And indeed, the iPod appears to as well.  But the iPod’s interface is proprietary, and there may be more going on than I’m aware.

Actually I’m guessing about MTP as well, but it’s an educated guess.  And here’s where the magic would happen:

Unlike Mass Storage, there’s no reason why the files on an MTP device have to be on the device itself.  When the car queries for a list of tracks, or genres, or whatever, the MTP device can act as a mere proxy and query some other device for that info, then report back to the car.  When the car wants to play a track, the MTP device proxies the file from some other device and feeds the data back to the car.

Surely you see where I’m heading.  A full blown, customized implementation of this protocol would have me plug my phone into the USB port, then have an application that talks to the car via MTP on one “side” and on the other “side” it talks to my Home Audio system via VPN over 3G.  All of the constructs – albums, songs, playlists – exist on the Home Audio system.

That’s not the approach I’d take though, if only because I can just imagine what would happen trying to proxy metadata for 30,000 tracks.  Rather, you’d likely proxy metadata for a single playlist, or perhaps for the playlists only.  Something like that.

But the whole point of the exercise would be to provide a seamless way to connect back to the Home Audio system and use the car’s media system to playback songs and browse the collection.  Imagine seeing my list of fav tracks on my I-Drive screen, being pulled in realtime from my network at home.  With MTP this would be possible!

How much work is required?  Well, I can wrap my head around the concept and interaction of all the moving parts.  The good news is that we wouldn’t need to worry about decoding/encoding MP3 in the app, since we’d just be proxying song data.  The great unknown is the amount of work (or feasibility) of coding a WinMo app that can take over the USB port.