I'm trying to implement fast forward and rewind in an app that controls the Empeg. On the first key down I send a socket message to the empeg side app that in turn sends "SERIAL=F" (begin fastforward) to /proc/empeg_notify. On key up I send a socket message to the empeg side app that sends "SERIAL=A" (end fastforward) to /proc/empeg_notify. Between the begin and end of fastforward, every 1/10th of a second, the empeg side app sends socket messages to the PC side app containing the current time in the tune. The PC side uses this information to give feedback to the user of where in the tune the fastforwarding has advanced. The user uses this feedback to decide when to release the button.

The problem is that this gets out of hand when the user keeps the button pressed for more than a few seconds because the Empeg has an accelerating fast forward, because there are lags in the transmission of socket messages, and because the empeg side of the app doesnt run in a very high priority thread. Essentially, the Empeg super fastforwards into the next song or songs before the message to stop fast forwarding gets to it (user sees delayed feedback, releases button, socket msg gets to empeg side of app, SERIAL=A is copied to empeg_notify)

My questions in trying to solve this: Can I disable acceleration in fastforward, rewind? Can I prevent a fast forward from getting into the next tune or a rewind from backing into the previous tune? I've tried breaking a long fastforward or rewind with a SERIAL=A immediately (or after a very short pause) followed by a SERIAL=F to break up the acceleration, but this does not entirely solve the problem.

Any ideas, pointers, words of wisdom? Thanks!