Ok, I got the lastest portmidi trunk, and I think I found an error: In Pm_OpenInput(), if NEWBUFFER is not defined, the buffer cannot be allocated because midi->buffer_len has not yet been defined. It appears that the mistake is that
(line 702) midi->buffer = (PmEvent *) pm_alloc(sizeof(PmEvent) * midi->buffer_len); should read midi->buffer = (PmEvent *) pm_alloc(sizeof(PmEvent) * bufferSize); Having said that, what is the purpose of the alternate buffer mechanism when NEWBUFFER is defined? I'd read the code and figure it out, but my old stuff still works without it and I'm kinda busy. Some brief explanation would be helpful. Will the old buffer style become deprecated? I'll post more errors when I find them. Adam On Thu, Mar 13, 2008 at 11:19 AM, Adam Somers <[EMAIL PROTECTED]> wrote: > oops! > > Definitely should have obtained the latest version first. Indeed, the > version I have been using is old and does not have the critical > section. > > Thanks a bunch! > > Adam > > > On Thu, Mar 13, 2008 at 7:23 AM, Roger Dannenberg <[EMAIL PROTECTED]> wrote: > > I'd like to retract my previous post. I should have read the code > > instead of going by memory. Here's some relevant code from the beginning > > of winmm_in_callback(): > > > > /* if this callback is reentered with data, we're in trouble. It's hard > > * to imagine that Microsoft would allow callbacks to be reentrant -- > > * isn't the model that this is like a hardware interrupt? -- but I've > > * seen reentrant behavior using a debugger, so it happens. > > */ > > EnterCriticalSection(&m->lock); > > > > So yes, callbacks are reentrant, even with a single MIDI device open. I > > believe PortMidi handles this in the best way. Adam reported some > > reentrance detection code and an assert() -- this must be from an older > > version of PortMidi. To update, please install SVN and follow the > > instructions posted here: > > > > http://portmedia.wiki.sourceforge.net/portmidi > > > > This makes me wonder: if immediately after the first instruction of the > > callback routine, the callback thread was preempted, what would prevent > > another thread from delivering another MIDI message, which would then be > > processed out-of-order? It seems the only way to prevent such a race > > condition is for the system to make the callbacks non-reentrant, at > > least on a per-device basis. (Alternatively, there could be a provision > > for the callback to say "I've handled the message, you can call me > > reentrantly now") I suspect this is a Microsoft bug, although I supposed > > there could be some argument about scheduling and priorities that > > prevents the race condition from causing problems in practice. > > > > > _______________________________________________ media_api mailing list media_api@create.ucsb.edu http://lists.create.ucsb.edu/mailman/listinfo/media_api
