ALSA OSS MIDI emulation: input problems

ALSA OSS MIDI emulation: input problems

[Jonathan Woithe]

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.

Now, in order to correct this, seq_oss_event.c:send_synth_event() must have
access to the current time.  Investigation shows that the OSS timer's time
is not at all accurate which means it can't be used for this.  We really
need to get access to the underlying ALSA timer.  I will look into this more
tonight.  If anyone has any ideas I'd welcome them!

A side issue is of course why the OSS timer isn't tracking time.  It seems
that it's tick value is only ever set when echo event requests come in for
times greater than its current setting.  Jazz++ sometimes batches echo
requests in lots of 10 or more, so consequently the OSS timer's "cur_tick"
field is often miles in the future.  It doesn't seem to be updated in real
time.  Maybe it's not meant to, but to me this appears to be a problem.

In any case, if the OSS timer could be relied on to accurately track the
ALSA timer then it could be used to source the time for the TMR_WAIT_ABS
event preceeding the NOTEON event.  If not, some other method of getting
access to the timer may be needed.

Anyway, any help or insight people have to this would be appreciated.

Regards
  jonathan
-- 
* Jonathan Woithe    jwoithe@physics.adelaide.edu.au                        *
*                    http://www.physics.adelaide.edu.au/~jwoithe            *
***-----------------------------------------------------------------------***
** "Time is an illusion; lunchtime doubly so"                              **
*  "...you wouldn't recognize a subtle plan if it painted itself purple and *
*   danced naked on a harpsichord singing 'subtle plans are here again'"    *


-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en

Re: ALSA OSS MIDI emulation: input problems

[Takashi Iwai]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

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

[-- Attachment #2: seq-oss-timestamp.dif --]
[-- Type: application/octet-stream, Size: 563 bytes --]

Index: alsa-kernel/core/seq/oss/seq_oss_midi.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/core/seq/oss/seq_oss_midi.c,v
retrieving revision 1.8
diff -u -r1.8 seq_oss_midi.c
--- alsa-kernel/core/seq/oss/seq_oss_midi.c	12 Mar 2003 11:26:20 -0000	1.8
+++ alsa-kernel/core/seq/oss/seq_oss_midi.c	26 Mar 2003 17:51:31 -0000
@@ -593,6 +593,7 @@
 		break;
 	}
 	
+	snd_seq_oss_readq_put_timestamp(dp->readq, ev->time.tick, dp->seq_mode);
 	snd_seq_oss_readq_put_event(dp->readq, &ossev);
 
 	return 0;

Re: ALSA OSS MIDI emulation: input problems

[Jonathan Woithe]

> > 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?
> :
> diff -u -r1.8 seq_oss_midi.c
> --- alsa-kernel/core/seq/oss/seq_oss_midi.c	12 Mar 2003 11:26:20 -0000	1.8
> +++ alsa-kernel/core/seq/oss/seq_oss_midi.c	26 Mar 2003 17:51:31 -0000
> @@ -593,6 +593,7 @@
>  		break;
>  	}
>  	
> +	snd_seq_oss_readq_put_timestamp(dp->readq, ev->time.tick, dp->seq_mode);
>  	snd_seq_oss_readq_put_event(dp->readq, &ossev);
>  
>  	return 0;

I'll check this out tonight and report accordingly.

What I can confirm is that the mechanism I outlined is in fact the reason
why jazz++ (and probably most other OSS sequencers) have bad timing when
recording midi input.

A a hack to test this I did the following:
 * in seq_oss_midi.c:send_synth_event() I inserted the following just before
   the call to snd_seq_oss_readq_put_event():
     { queue_t *q = queueptr(dp->queue);
       snd_seq_oss_readq_put_timestamp(dp->readq,
         q->timer->tick.cur_tick,dp->seq_mode);
       queuefree(q);
     }
 * added include files so queueptr() prototype was available to
   seq_oss_midi.c
 * arranged for queueptr() to be exported from seq_queue.c

When used, this revised code produced correct results inside jazz++.  At the
time this was the only way I knew to get at a known good timer (I'd
previously verified that the queue's timer was incrementing as expected).
I had somehow missed that ev had a valid `time' field in this context.

Takashi's patch *should* work so long as ev->time.tick is correct (ie: it's
not derived from the oss timer).  My rudamentary knowledge of ALSA internals 
suggests that it should be fine though.  Again, I'll confirm tonight.

I also suspect that seq_oss_midi.c:send_midi_event() might also need to
reference ev->time.tick rather than the oss timer because as far as I can
tell the oss timer time is somewhat bogus (or at least that's what it
appears to me).  Is it correct that the oss timer doesn't actually track
real time?  If so, what exactly is the purpose of the oss timer in the
seq_oss_devinfo_t structure (other than to keep track time of the last
queued echo event)?  The other possibility is that the oss timer is only
valid for /dev/sequencer accesses - jazz++ uses /dev/sequencer2 and this is
the only interface I can conveniently test.

Regards
  jonathan
-- 
* Jonathan Woithe    jwoithe@physics.adelaide.edu.au                        *
*                    http://www.physics.adelaide.edu.au/~jwoithe            *
***-----------------------------------------------------------------------***
** "Time is an illusion; lunchtime doubly so"                              **
*  "...you wouldn't recognize a subtle plan if it painted itself purple and *
*   danced naked on a harpsichord singing 'subtle plans are here again'"    *


-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en

Re: ALSA OSS MIDI emulation: input problems

[Takashi Iwai]

At Thu, 27 Mar 2003 09:54:16 +1030 (CST),
Jonathan Woithe wrote:
> 
> I also suspect that seq_oss_midi.c:send_midi_event() might also need to
> reference ev->time.tick rather than the oss timer because as far as I can
> tell the oss timer time is somewhat bogus (or at least that's what it
> appears to me).

this part was already fixed shortly before the release of alsa 0.9.1.


ciao,

Takashi


-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en

Re: ALSA OSS MIDI emulation: input problems

[Jonathan Woithe]

> > 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?
> :
> diff -u -r1.8 seq_oss_midi.c
> --- alsa-kernel/core/seq/oss/seq_oss_midi.c	12 Mar 2003 11:26:20 -0000	1.8
> +++ alsa-kernel/core/seq/oss/seq_oss_midi.c	26 Mar 2003 17:51:31 -0000
> @@ -593,6 +593,7 @@
>  		break;
>  	}
>  	
> +	snd_seq_oss_readq_put_timestamp(dp->readq, ev->time.tick, dp->seq_mode);
>  	snd_seq_oss_readq_put_event(dp->readq, &ossev);
>  
>  	return 0;

Ok.  Last night I investigated ev->time.tick.  Admittedly this was under
0.90rc8b.  It transpires that ev->time.tick is *always* zero when the event
is a NOTEON/NOTEOF, and therefore gives no timing information what-so-ever. 
Thus the above patch does *not* fix the problem, at least under 0.90rc8b.

I will grab the latest release today (0.9.2) and give that a go over the
weekend in case this has been rectified since the later rc releases.  If
not, we'll have to find some other way of getting at the timer info (either
fixing ev->timer or perhaps formalising the rough hack I outlined in a
previous email).

Regards
  jonathan
-- 
* Jonathan Woithe    jwoithe@physics.adelaide.edu.au                        *
*                    http://www.physics.adelaide.edu.au/~jwoithe            *
***-----------------------------------------------------------------------***
** "Time is an illusion; lunchtime doubly so"                              **
*  "...you wouldn't recognize a subtle plan if it painted itself purple and *
*   danced naked on a harpsichord singing 'subtle plans are here again'"    *


-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en

Re: ALSA OSS MIDI emulation: input problems

[Takashi Iwai]

At Fri, 28 Mar 2003 08:58:47 +1030 (CST),
Jonathan Woithe wrote:
> 
> Ok.  Last night I investigated ev->time.tick.  Admittedly this was under
> 0.90rc8b.  It transpires that ev->time.tick is *always* zero when the event
> is a NOTEON/NOTEOF, and therefore gives no timing information what-so-ever. 
> Thus the above patch does *not* fix the problem, at least under 0.90rc8b.

0.9.0rc8b is way too old.  there have been changes for sequencer oss
emulation since that.  please try the cvs version.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en

Re: ALSA OSS MIDI emulation: input problems

[Jonathan Woithe]

> > > 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?
> > :
> > diff -u -r1.8 seq_oss_midi.c
> > --- alsa-kernel/core/seq/oss/seq_oss_midi.c   12 Mar 2003 11:26:20 -0000 1.8
> > +++ alsa-kernel/core/seq/oss/seq_oss_midi.c   26 Mar 2003 17:51:31 -0000
> > @@ -593,6 +593,7 @@
> >               break;
> >       }
> >       
> > +     snd_seq_oss_readq_put_timestamp(dp->readq, ev->time.tick, dp->seq_mode);
> >       snd_seq_oss_readq_put_event(dp->readq, &ossev);
> >  
> >       return 0;
> > 
> Ok.  Last night I investigated ev->time.tick.  Admittedly this was under
> 0.90rc8b.  It transpires that ev->time.tick is *always* zero when the event
> is a NOTEON/NOTEOF, and therefore gives no timing information what-so-ever. 
> Thus the above patch does *not* fix the problem, at least under 0.90rc8b.

Over the weekend I tested this patch against ALSA 0.9.2 release.  The patch
DOES fix the problem under this version of ALSA - so obviously the sequencer
changes since 0.9.0rc8b have rectified the problems with ev->time.tick. 
This is a good development - it means I can run a single sound driver now
rather than having to switch between ALSA and OSS depending on what I need
to do at the time.

So to confirm: the above patch fixes the input event timing when using ALSA 
OSS sequencer (/dev/sequencer2) emulation.

Best regards
  jonathan
-- 
* Jonathan Woithe    jwoithe@physics.adelaide.edu.au                        *
*                    http://www.physics.adelaide.edu.au/~jwoithe            *
***-----------------------------------------------------------------------***
** "Time is an illusion; lunchtime doubly so"                              **
*  "...you wouldn't recognize a subtle plan if it painted itself purple and *
*   danced naked on a harpsichord singing 'subtle plans are here again'"    *


-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en