/proc/empeg_notify delay when injecting buttons

For those who haven't been following this thread, a couple of us are trying to interface our empegs to our BMWs by emulating the BMW branded but Alpine built CD changer.

Basically we are injecting button codes into /proc/empeg_notify to simulate button presses. In my case I'm initially doing the 4 up, down, left, right buttons and also Mark Track as a special one.

My code consists of this (which I blatantly stole from an example or someone somewhere sorry can't remember where exactly):

Code:

---

int DoSerialCmd(const char* szCmd)
{
    FILE *fs_EmpegNotify=NULL;
    fs_EmpegNotify = fopen("/proc/empeg_notify", "a");

    if(NULL==fs_EmpegNotify) {
        perror("could not open empeg_notify to receive serial commands");
        return 0;
    }

    fprintf(fs_EmpegNotify, "%s\n",szCmd);
    fclose(fs_EmpegNotify);

    return 1;
}

---

which I then simply call with something like this:

Code:

---

DoSerialCmd("BUTTON=PrevTrack");

---

The problem is that when the button code is injected it can take a good 5 seconds for it to take effect. It would seem that the empeg is waiting for the drive(s) to spin up. Something to do with /proc being a filesystem (even though it's a pseudo filesystem)?

I don't really want to have the drives spinning all the time if possible. It's particularly annoying when skipping a few tracks at a time. Even when the drives are spun up it's not nearly as responsive as pressing a front panel button.

I didn't pay too much attention to the above code, but perhaps opening and closing the file is slowing it down a little? I'll try that. I'm not running anything else extra but would keeping it open prevent other apps from working?

So for those who have injected button presses via this method, did you find a lot of lagginess?

Any suggestions that might get around this issue?

Thanks

Is that only for the first press of a sequence, or slow for the others, too?

Is it still slow if you feed one press, wait for drives to spindown, then feed another?

Perhaps it is paging libc (the C library), since you're using the high level stream I/O utils, rather than simply calling open(), write(), and close() directly (which map to kernel syscalls, and shouldn't cause any new libc activity).

???

Quote:
Perhaps it is paging libc (the C library), since you're using the high level stream I/O utils, rather than simply calling open(), write(), and close() directly (which map to kernel syscalls, and shouldn't cause any new libc activity).

Very interesting hint! I will try to rewrite that piece of code tonight..