>> There's still a few things that I am not 100% sure about. >The undocumented workarounds flag in the generic_mpu401_module >create_device() call, maybe >:-\ Yup, thats one of them! But I have a suspicion what it is. Some soundcards do not implement a UART command port, only a data port, so that it is always in UART mode. The generic module should not try to reset, or enter UART mode on these cards. With no command port, I think the data port is slightly different too. I haven't seen a soundcard that does this, but they supposedly exist. >> Is the module copied for each sound card, or is the module only >> loaded once and all cards share it >> I'm not that familiar how modules are used. >Kernel modules are load on demand, and when more than one driver or >other module call get_module() on it, he's shared between us, yes. >However, each generic_mpu401_module "client" should call >create_device() first, and pass in void **out_storage argument a place >to keep >an "handle" to client specific data. That way the MPU401 module attach, >with client help, each specific module "client" (aka sound card driver) >data... Okay, that makes sense. Thats something that would still need to be added. >> Is the midi parser even used >Good question! >I guess his purpose is to help midi driver coders to implement in their >driver a read() hook that return full, valid, MIDI event bytes, as the >midi server expect to get at least one event per read() call. One thing that I saw was that if I ever returned anything other than a single byte at a time from the read_hook, the thread would die and the read_hook wasn't called again. This makes sense if num_bytes=0, but I would think that if I had 4 bytes in the buffer, they should all be returned. Maybe I'm doing something wrong still. I will try to clean-up, debug my code over the weekend and post it monday, working or not. More eyes looking at it would only help. Greg Crain gsc70@xxxxxxxxxxx