[openbeos-midi] Re: Update (and SBLive midi tester wanted!)

>> 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

Other related posts: