Hi,

I've been trying to get to grips with the USB support in the Empeg.
USB is presented as a device /dev/usb0 making control trivial by using ioctl(), read(), write() and poll()

ioctl( fd, 0, args) will get the state. args[0] is the endpoint you want to query and after the call args[1] contains the returned state.

ioctl( fd, 1, args) will set the state. args[0] is the endpoint you want to set, args[1] contains the state to set.

The Phillips PDIUSBD12 chip (used in MK2 and MK2a) provides 3 endpoint numbers:
0 control (endpoint indexes 0 and 1)
1 generic (endpoint indexes 2 and 3)
2 generic-main (endpoint indexes 4 and 5)
Endpoint numbers 0 and 1 have a 16 byte hardware buffer and 64 byte software buffer. Endpoint number 2 has a 64 byte hardware double buffer (allowing greater throughput than endpoint 1).

Now for those all-important questions...

1. Which endpoint numbers are used by Empeg (I think endpoint numbers 0 and 2, endpoint number 1 is unused)?

2. What is responsible for the player menus and navigation - is it the player itself, or some other process?

3. What is responsible for the file synchronisation on the Empeg (I think this is the player - so when the player isn't running, nothing has /dev/usb0 open)?

Hi,

Here is what I have found in the USB stuff I have been doing:
1) Endpoints 0 (control endpoint on all USB devices) and endpoint 2 (Bulk data) are the only 2 endpoints the Empeg currently uses, endpoint 1 is indeed unused.

2) I believe all of the menus and navigation related to the player are controlled by the player.

3) The File Sync is controlled by the player app, for confirmation of this drop to a shell on the empeg (press q with a dev kernel loaded) then try to connect Emplode, it should fail to find your player.

Thanks for confirming my fears

I am trying to achive two (somewhat unconnected) objectives.

1. Send and receive data through the USB port while the player is running without upsetting the player. It looks like using endpoint 1 or adding USB configurations will require a change to the usb driver software. I'll probably need to use endpoint 2 anyway.

2. Add an option to the Source menu that will rerun the TTSclock program and display some text on the VFD. I guess that the option could be added to the Hijack menu instead but either way I need to be able to take over the audio, display and user input systems, pausing normal player operation until the user chooses to exit my 'mode'.

Thanks for confirming my fears

Sorry about that, I just got out of a meeting where I did the same thing to someone else's idea, maybe it is my day to rain on peoples parades again

1) I don't know how much of a hurry you are in to do this, but I am working on a few kernel modifications that make the empeg look like it is connected over Ethernet even though there is a USB cable used. The benifit of this for you is that you could just pick up an un-used TCP port and that wouldn't bother the player app, and wouldn't need any modifications to the windows drivers.

2) The tone generator stuff just released takes over audio, display and input from a Hijack menu, you could look at that and see if there is anything useful you that could be borrowed (with permission of course)

1. Send and receive data through the USB port while the player is running without upsetting the player. It looks like using endpoint 1 or adding USB configurations will require a change to the usb driver software. I'll probably need to use endpoint 2 anyway.

If you start the player with the "-u-" command-line argument, it doesn't open /dev/usb0 (and is thus inaccessible over USB).

Peter

2) The tone generator stuff just released takes over audio, display and input from a Hijack menu, you could look at that and see if there is anything useful you that could be borrowed (with permission of course)

That stuff is all GPL'd code, or modifications to GPL'd code (and therefore..), so no explicit permission is needed. Feel free!