At Wed, 26 Mar 2003 17:30:09 +1030 (CST), Jonathan Woithe wrote: > > Hi all > > I've been messing with the following problem on and off for the last few > weeks. It occurs when the OSS sequencer emulation is used with Jazz++ > 4.1.3. In essence, incoming MIDI events from an external MIDI interface > have their time quantised to multiples of 48 ticks, which is not very > satisfactory. > > After a lot of messing around, I think I'm starting to work out why this is. > Jazz++ updates its play position every 48 ticks and the trigger for this is > a SEQ_ECHO event. When one of these arrives, jazz increments its time > counters, sets another SEQ_ECHO event to happen in 48 ticks time and then > finishes. This means that in the absence of MIDI input, jazz++ time goes up > in increments of 48 ticks. > > Now, when input occurs, Jazz++ needs to know the current time, which is very > unlikely to be a multiple of 48 ticks. Under nateive OSS it seems that > before the NOTEON event (for example) OSS sends a TMR_WAIT_ABS event to > update the application on the current time - the NOTEON event then follows > and is assumed to have occurred at the "current time" which of course will > be the time set by the TMR_WAIT_ABS event. > > The problem as I see it is that the ALSA OSS emulation does not send this > TMR_WAIT_ABS event - it only sends the NOTEON event. Jazz gets this and > without any TMR_WAIT_ABS to tell it otherwise, assumes that it occured at > the "current" time - which is always a multiple of 48 ticks.
does the attached patch cure? Takashi
seq-oss-timestamp.dif
Description: Binary data
