Re: [Alsa-devel] ALSA OSS MIDI emulation: input problems
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 - 1.8 +++ alsa-kernel/core/seq/oss/seq_oss_midi.c 26 Mar 2003 17:51:31 - @@ -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[EMAIL PROTECTED]* *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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] ALSA OSS MIDI emulation: input problems
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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] ALSA OSS MIDI emulation: input problems
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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] ALSA OSS MIDI emulation: input problems
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 - 1.8 +++ alsa-kernel/core/seq/oss/seq_oss_midi.c 26 Mar 2003 17:51:31 - @@ -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[EMAIL PROTECTED]* *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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] ALSA OSS MIDI emulation: input problems
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 - 1.8
+++ alsa-kernel/core/seq/oss/seq_oss_midi.c 26 Mar 2003 17:51:31 -
@@ -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[EMAIL PROTECTED]*
*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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
