It's been stated that whilst the guys in Cambridge (R) are busy with other stuff, they cannot really commit to the likelihood that they will be able to build USB based download capability from the Rio Central to allow us to talk to the empeg car/Rio car from same. This means, in the short term anyway, there is no real chance we're going to be able to download ripped tracks/playlists etc. from a Central to a Car.

So here's the idea. Sort out a daemon that runs as a d in the background on the Car. It knows how to talk the protocol of one of the supported portables that the Central can talk to (choice of device yet to be determined - depends on the capability of the portable and how close it matches the Car). When plugged into the Central, the device identification exchange means that the Car know's it's talking to a Central, and identifies itself as a Rio XXXX (where XXXX is our emulated device type).

One smart bloke then writes an emulator to allow the Central to believe it is downloading material to a flat playlist device, such as an XXXX. The daemon on the Car will accept downloaded tracks and then place them into a special playlist under the root of the menu structure, which can be immediately played in track order.

The daemon running in background would be required to create tracks with appropriate FIDs on the correct mount points, allowing for database construction at boot time of the Car player. This would be the "synch".

This would provide us with a short-term fix to allow us to perform downloads from the Central, without interfering with the Player source, in a manner that is compatible with the database structure used on disk, without causing problems.

Comments, flames? Obvious mistakes, misunderstandings? Anyone reverse engineered any of the USB protocols for any of the Rio portables?

Can a piece of software spoof a device's identity on the USB cable? Or is the USB identity of a device a function of its chip set and therefore not changeable?

It depends on how the hardware is set up, and which chipset is being used. Generally Si companies put their own ID's in there, and then any product using them can override them. I guess the question for this application is "are the vendor and device ID set by HW or SW", and it is probably down to one of the Cam boys to anwser.

Yeah. It's possible to change the product ID on the empeg.

0x4f,0x08, /* empeg's vendor ID */
0x01,0x00, /* empeg car product ID */
0x01,0x00, /* empeg's revision ID */

It's set by the kernel driver for the USB chip. Twiddle the product ID to whatever a Rio portable is and it should identify itself as that. Probably a good idea to change the product ID strings as well. None of the empeg car protocol is in the kernel driver, it's all implemented by the player application by the looks of things.

However, If you mess about with the driver then you wouldn't be able to use the USB port to sync normally anymore unless you fudge together a method of selecting which USB driver to use.

- Trevor

The correct answer is simply to run emptool on the Central, surely? It's running Linux. It's got USB master. Better than that, just persuade rsync to run over USB, and run an rsync daemon on the car player. Then they'll be completely in sync. There are a couple of corner cases, but I dare say that it'll be easier and more reliable than making the car player pretend to be a Rio 600.

Ooooooo I like that idea.

And with a USB keyboard, it's easy to get a shell on the Central...