Bug: ALSA Sequencer or MTPAV - easy to reproduce

Bug: ALSA Sequencer or MTPAV - easy to reproduce

[Ryan Pavlik]

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

I've finally gotten something reproducible.  I don't know if this is a
bug with the mtpav in particular or the sequencer, although I'd think
someone would have noticed if it were the latter by now.

Anyway, notes or messages are _still_ getting lost.  It seems that note
messages are getting lost when playing "overlapping" notes while two
MTPAV (or other?) devices are being sent to.  Let me illustrate:

Track 1:
  __   __   __   __

Track 2:
             _____
         _____
      _____
  _____

In my case, I play the first to device #1, and then the second to device
#0 (while the first is still playing).  I lose Note-on or Note-off
messages somewhere... you can hear that notes won't fire, or they won't
turn off.

Of course, each track alone plays fine.  Also, playing a second track
with no "overlap" seems to work fine, too (as in playing track1 on both
devices).

I have attached two tracks in MIDI form, created by Seq24
(http://filter24.org), which follow this pattern.  You can test them
using pmidi on the command line---the same problem occurs.  I use them
as follows:

   $ pmidi -p 72:1 track1.mid
   $ pmidi -p 72:0 track2.mid  # in a different term, while the first
                               # plays

Any fixes, pointers on where to look in the code, or general ideas would
be greatly appreciated.

-- 
Ryan Pavlik <rpav@users.sf.net>

"I distinctly remember dancing on your grave." - 8BT

[-- Attachment #2: track1.mid --]
[-- Type: audio/midi, Size: 384 bytes --]

[-- Attachment #3: track2.mid --]
[-- Type: audio/midi, Size: 162 bytes --]

Further info: Bug: ALSA Sequencer or MTPAV - easy to reproduce

[Ryan Pavlik]

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

On Wed, 12 Feb 2003 11:28:35 -0800
Ryan Pavlik <rpav@nwlink.com> wrote:

<snipped>

Further info:  The bug is definitely above the hardware level.  I added
a printk to snd_mtpav_send_byte() for logging device/bytes sent, and
came up with the attached log, which I commented on.  This log was
generated by playing the two tracks as described in my previous message.

As you can see (a page or two down, look for '??'), the status byte
for some midi messages is getting lost before it gets to
snd_mtpav_send_byte(). I'm going to go through and see if this is due
to complications elsewhere in mtpav.c, but I'm only about 50% sure
that's where the problem is.

-- 
Ryan Pavlik <rpav@users.sf.net>

"I distinctly remember dancing on your grave." - 8BT

[-- Attachment #2: midilog.gz --]
[-- Type: application/x-gzip, Size: 697 bytes --]

Re: Further info: Bug: ALSA Sequencer or MTPAV - easy to reproduce

[Jaroslav Kysela]

On Wed, 12 Feb 2003, Ryan Pavlik wrote:

> On Wed, 12 Feb 2003 11:28:35 -0800
> Ryan Pavlik <rpav@nwlink.com> wrote:
> 
> <snipped>
> 
> Further info:  The bug is definitely above the hardware level.  I added
> a printk to snd_mtpav_send_byte() for logging device/bytes sent, and
> came up with the attached log, which I commented on.  This log was
> generated by playing the two tracks as described in my previous message.
> 
> As you can see (a page or two down, look for '??'), the status byte
> for some midi messages is getting lost before it gets to
> snd_mtpav_send_byte(). I'm going to go through and see if this is due
> to complications elsewhere in mtpav.c, but I'm only about 50% sure
> that's where the problem is.

It seems that mtpav don't remeber the old status byte for each channels. 
If it's true, then we need to take care about the expansion in the mtpav 
driver, because the sequencer MIDI driver removes duplicated status bytes 
to opmitize throughput.

To test this behaviour, please, try this patch:

Index: seq_midi_event.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/core/seq/seq_midi_event.c,v
retrieving revision 1.10
diff -u -r1.10 seq_midi_event.c
--- seq_midi_event.c    31 Jan 2003 15:19:34 -0000      1.10
+++ seq_midi_event.c    12 Feb 2003 20:41:30 -0000
@@ -349,6 +349,8 @@
 {
        unsigned int cmd, type;

+       dev->nostat = 1;
+
        if (ev->type == SNDRV_SEQ_EVENT_NONE)
                return -ENOENT;



						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

RE: Further info: Bug: ALSA Sequencer or MTPAV - easy to reproduce

[Mark Knecht]

Jaroslav,
   Hi. Actually, I had been looking around for where to report this sort of
problem. I'm using an HDSP 9652 for MIDI input and getting stuck notes on
all soft synths I'm using. (amSynth, ZynAddSubFx and iiwusynth) I'm at a bit
of a loss as to how to debug this, but I do see the problem.

   I have found that it is independent of MIDI applications, as I see the
problem if I just use kaconnect to hook MIDI input to the soft synth and
qjackconnect to hook analog output to my speakers.

Mark

-----Original Message-----
From: alsa-devel-admin@lists.sourceforge.net
[mailto:alsa-devel-admin@lists.sourceforge.net]On Behalf Of Jaroslav
Kysela
Sent: Wednesday, February 12, 2003 12:42 PM
To: Ryan Pavlik
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: Further info: [Alsa-devel] Bug: ALSA Sequencer or MTPAV -
easy to reproduce


On Wed, 12 Feb 2003, Ryan Pavlik wrote:

> On Wed, 12 Feb 2003 11:28:35 -0800
> Ryan Pavlik <rpav@nwlink.com> wrote:
>
> <snipped>
>
> Further info:  The bug is definitely above the hardware level.  I added
> a printk to snd_mtpav_send_byte() for logging device/bytes sent, and
> came up with the attached log, which I commented on.  This log was
> generated by playing the two tracks as described in my previous message.
>
> As you can see (a page or two down, look for '??'), the status byte
> for some midi messages is getting lost before it gets to
> snd_mtpav_send_byte(). I'm going to go through and see if this is due
> to complications elsewhere in mtpav.c, but I'm only about 50% sure
> that's where the problem is.

It seems that mtpav don't remeber the old status byte for each channels.
If it's true, then we need to take care about the expansion in the mtpav
driver, because the sequencer MIDI driver removes duplicated status bytes
to opmitize throughput.

To test this behaviour, please, try this patch:

Index: seq_midi_event.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/core/seq/seq_midi_event.c,v
retrieving revision 1.10
diff -u -r1.10 seq_midi_event.c
--- seq_midi_event.c    31 Jan 2003 15:19:34 -0000      1.10
+++ seq_midi_event.c    12 Feb 2003 20:41:30 -0000
@@ -349,6 +349,8 @@
 {
        unsigned int cmd, type;

+       dev->nostat = 1;
+
        if (ev->type == SNDRV_SEQ_EVENT_NONE)
                return -ENOENT;



						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

RE: Further info: Bug: ALSA Sequencer or MTPAV - easy to reproduce

[Jaroslav Kysela]

On Wed, 12 Feb 2003, Mark Knecht wrote:

> Jaroslav,
>    Hi. Actually, I had been looking around for where to report this sort of
> problem. I'm using an HDSP 9652 for MIDI input and getting stuck notes on
> all soft synths I'm using. (amSynth, ZynAddSubFx and iiwusynth) I'm at a bit
> of a loss as to how to debug this, but I do see the problem.
> 
>    I have found that it is independent of MIDI applications, as I see the
> problem if I just use kaconnect to hook MIDI input to the soft synth and
> qjackconnect to hook analog output to my speakers.

Could you try the command 'dd if=/dev/snd/midiC0D0 of=abcd bs=1' and play
some notes on connected keyboard? In the file abcd will be the raw context
of midi input, so we can determine, if it's driver or sequencer problem.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

RE: Further info: Bug: ALSA Sequencer or MTPAV - easy to reproduce

[Mark Knecht]

Will do. I'll send it along this evening.

Thanks,
Mark

-----Original Message-----
From: Jaroslav Kysela [mailto:perex@suse.cz]
Sent: Wednesday, February 12, 2003 1:26 PM
To: Mark Knecht
Cc: alsa-devel@lists.sourceforge.net
Subject: RE: Further info: [Alsa-devel] Bug: ALSA Sequencer or MTPAV -
easy to reproduce


On Wed, 12 Feb 2003, Mark Knecht wrote:

> Jaroslav,
>    Hi. Actually, I had been looking around for where to report this sort
of
> problem. I'm using an HDSP 9652 for MIDI input and getting stuck notes on
> all soft synths I'm using. (amSynth, ZynAddSubFx and iiwusynth) I'm at a
bit
> of a loss as to how to debug this, but I do see the problem.
>
>    I have found that it is independent of MIDI applications, as I see the
> problem if I just use kaconnect to hook MIDI input to the soft synth and
> qjackconnect to hook analog output to my speakers.

Could you try the command 'dd if=/dev/snd/midiC0D0 of=abcd bs=1' and play
some notes on connected keyboard? In the file abcd will be the raw context
of midi input, so we can determine, if it's driver or sequencer problem.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

RE: Further info: Bug: ALSA Sequencer or MTPAV - easy to reproduce

[Mark Knecht]

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

On Wed, 2003-02-12 at 13:25, Jaroslav Kysela wrote:
> On Wed, 12 Feb 2003, Mark Knecht wrote:
> 
> > Jaroslav,
> >    Hi. Actually, I had been looking around for where to report this sort of
> > problem. I'm using an HDSP 9652 for MIDI input and getting stuck notes on
> > all soft synths I'm using. (amSynth, ZynAddSubFx and iiwusynth) I'm at a bit
> > of a loss as to how to debug this, but I do see the problem.
> > 
> >    I have found that it is independent of MIDI applications, as I see the
> > problem if I just use kaconnect to hook MIDI input to the soft synth and
> > qjackconnect to hook analog output to my speakers.
> 
> Could you try the command 'dd if=/dev/snd/midiC0D0 of=abcd bs=1' and play
> some notes on connected keyboard? In the file abcd will be the raw context
> of midi input, so we can determine, if it's driver or sequencer problem.
> 
> 						Jaroslav

Hi,
   OK, as requested, here's a few chords and some notes. However, I
cannot hear the soft synth when doing this, and I normally only get a
stuck note once every 5-10 minutes, so there's no guarantee that there's
anything interesting in here.

   Maybe I could record something, using Rosegarden, until I get a stuck
note, and give you a MIDI file? Don't know if that would be of much help
as this problem is not terribly repeatable yet.

   Is there any way I can pipe this input to my soft synth so I can hear
what I'm doing?

Cheers,
Mark

[-- Attachment #2: midi_notes --]
[-- Type: application/octet-stream, Size: 138 bytes --]

YES! :-) Was: Bug: ALSA Sequencer or MTPAV - easy to reproduce

[Ryan Pavlik]

On Wed, 12 Feb 2003 21:41:50 +0100 (CET)
Jaroslav Kysela <perex@suse.cz> wrote:


> It seems that mtpav don't remeber the old status byte for each
> channels. If it's true, then we need to take care about the expansion
> in the mtpav driver, because the sequencer MIDI driver removes
> duplicated status bytes to opmitize throughput.

Yes! this works! (Or basically the equivalent does.)  Now, from looking
at things, it seems like the MTPAV treats a device change like another
midi message... basically using 0xF5 as a midi system message to change
device.  According to the references I'm looking at, 0xF5 is left
undefined.  This means technically the mtpav isn't wrong, just
strange. ;-)

For a somewhat elegant solution, it may be possible to have the mtpav
track the last device and running status.  I initially thought this
would be impossible, but it looks like it could be done in
snd_mtpav_output_port_write() (mtpav.c:298).  I will work on this and
submit a patch shortly, unless someone suggests a better solution.

> To test this behaviour, please, try this patch:
<snip> 

Thanks :-)

-- 
Ryan Pavlik <rpav@users.sf.net>

"I distinctly remember dancing on your grave." - 8BT


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: YES! :-) Was: Bug: ALSA Sequencer or MTPAV - easy to reproduce

[Paul Davis]

>For a somewhat elegant solution, it may be possible to have the mtpav
>track the last device and running status.  I initially thought this
>would be impossible, but it looks like it could be done in
>snd_mtpav_output_port_write() (mtpav.c:298).  I will work on this and
>submit a patch shortly, unless someone suggests a better solution.

FYI, the isa/wavefront driver does the same thing (it has two ports
and uses un-assigned MIDI bytes to switch between them). you might (or
might not) find it useful to take look there.

--p


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: YES! :-) Was: Bug: ALSA Sequencer or MTPAV - easy to reproduce

[Immanuel Litzroth]

The information about the emagic unitor8 has also this

	Der Befehl F5 gefolgt von einem Datenbyte bestimmt die gerade aktive
        Kabelnummer (0,1,2,3 ... 64).

	Ist die Kabelnummer=0 werden alle MIDI Messages auf allen MIDI Outs
	ausgegeben (alle Outs von allen Boxen).
	Nach einem Kaltstart ist die Kabelnummer=0.

        Die Kabelnummer '7F' (dumme MIDI Schnittstelle) verhaelt sich wie die
        Kabelnummer 0. Kabelnummer '7F' sollte beim Verlassen von LOGIC
        gesendet werden, da dadurch moegliche Filter(MIDI In/Out) geloescht
        werden. Siehe MOTU: Mute NON-CHANNEL Messages.


Since this device is supposed to be compatible with the MOTU (or have
a motu-compatible mode) the documentation at
http://www.math.tu-berlin.de/~sbartels/unitor/unitor8_doc.txt
could maybe help
Immanuel

*************************************************************************** 
I have always been fascinated by those who want to work.
Prunesquallor - Ghormenghast
Immanuel Litzroth
Software Development Engineer
Enfocus Software
Kleindokkaai 3-5
B-9000 Gent
Belgium
Voice: +32 9 269 23 90
Fax : +32 9 269 16 91
Email: Immanuell@enfocus.be
web : www.enfocus.be
***************************************************************************



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: YES! :-) Was: Bug: ALSA Sequencer or MTPAV - easy to reproduce

[Takashi Iwai]

At 13 Feb 2003 12:54:39 +0100,
Immanuel Litzroth wrote:
> 
> The information about the emagic unitor8 has also this
> 
> 	Der Befehl F5 gefolgt von einem Datenbyte bestimmt die gerade aktive
>         Kabelnummer (0,1,2,3 ... 64).
> 
> 	Ist die Kabelnummer=0 werden alle MIDI Messages auf allen MIDI Outs
> 	ausgegeben (alle Outs von allen Boxen).
> 	Nach einem Kaltstart ist die Kabelnummer=0.
> 
>         Die Kabelnummer '7F' (dumme MIDI Schnittstelle) verhaelt sich wie die
>         Kabelnummer 0. Kabelnummer '7F' sollte beim Verlassen von LOGIC
>         gesendet werden, da dadurch moegliche Filter(MIDI In/Out) geloescht
>         werden. Siehe MOTU: Mute NON-CHANNEL Messages.
> 
> 
> Since this device is supposed to be compatible with the MOTU (or have
> a motu-compatible mode) the documentation at
> http://www.math.tu-berlin.de/~sbartels/unitor/unitor8_doc.txt
> could maybe help
> Immanuel

oh, where did you get it?  it's really helpful.
with this we can implement the init and smpte sysex code on mtpav
driver.  also unitor8 can be supported, too.


thanks!

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

[PATCH]: Bug: ALSA Sequencer or MTPAV - easy to reproduce

[Ryan Pavlik]

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

On Wed, 12 Feb 2003 21:41:50 +0100 (CET)
Jaroslav Kysela <perex@suse.cz> wrote:

<snip> 
> It seems that mtpav don't remeber the old status byte for each
> channels. If it's true, then we need to take care about the expansion
> in the mtpav driver, because the sequencer MIDI driver removes
> duplicated status bytes to opmitize throughput.
<snip>

OK, I've attached a patch that emulated running status in the mtpav
driver, so there shouldn't be any need to change stuff elsewhere.

Thanks for your pointer, I've been wanting to fix this problem for a
very long time. :-)

-- 
Ryan Pavlik <rpav@users.sf.net>

"I distinctly remember dancing on your grave." - 8BT

[-- Attachment #2: mtpav.patch --]
[-- Type: application/octet-stream, Size: 1164 bytes --]

--- mtpav.c	2003-02-12 14:24:48.000000000 -0800
+++ mtpav-rpav.c	2003-02-12 14:29:45.000000000 -0800
@@ -135,6 +135,7 @@
 	u8 number;
 	u8 hwport;
 	u8 mode;
+	u8 running_status;
 	snd_rawmidi_substream_t *input;
 	snd_rawmidi_substream_t *output;
 } mtpav_port_t;
@@ -300,6 +301,11 @@
 					snd_rawmidi_substream_t *substream)
 {
 	u8 outbyte;
+	int bytes_copied;
+
+	// Get the outbye first, so we can emulate running status if
+	// necessary
+	bytes_copied = snd_rawmidi_transmit(substream, &outbyte, 1);
 
 	// send port change command if necessary
 
@@ -310,12 +316,19 @@
 		snd_mtpav_send_byte(mtp_card, port->hwport);
 		//snd_printk("new outport: 0x%x\n", (unsigned int) port->hwport);
 
+		if (bytes_copied == 1 && !(outbyte & 0x80))
+			snd_mtpav_send_byte(mtp_card, port->running_status);
 	}
 
 	// send data
 
-	while (snd_rawmidi_transmit(substream, &outbyte, 1) == 1)
+	while (bytes_copied == 1) {
+		if(outbyte & 0x80)
+			port->running_status = outbyte;
+		
 		snd_mtpav_send_byte(mtp_card, outbyte);
+		bytes_copied = snd_rawmidi_transmit(substream, &outbyte, 1);
+	}
 }
 
 static void snd_mtpav_output_write(snd_rawmidi_substream_t * substream)

Re: [PATCH]: Bug: ALSA Sequencer or MTPAV - easy to reproduce

[Takashi Iwai]

Hi,

At Wed, 12 Feb 2003 14:35:29 -0800,
Ryan Pavlik wrote:
> 
> On Wed, 12 Feb 2003 21:41:50 +0100 (CET)
> Jaroslav Kysela <perex@suse.cz> wrote:
> 
> <snip> 
> > It seems that mtpav don't remeber the old status byte for each
> > channels. If it's true, then we need to take care about the expansion
> > in the mtpav driver, because the sequencer MIDI driver removes
> > duplicated status bytes to opmitize throughput.
> <snip>
> 
> OK, I've attached a patch that emulated running status in the mtpav
> driver, so there shouldn't be any need to change stuff elsewhere.
> 
> Thanks for your pointer, I've been wanting to fix this problem for a
> very long time. :-)

thanks for the patch.
i applied it to cvs with a little improvement (returning immediately
if snd_rawmidi_transmit() gets null).

also, i found a bug regarding magic-alloc/free in the driver (at
last!).  fixed on cvs, too.


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH]: Bug: ALSA Sequencer or MTPAV - easy to reproduce

[Jaroslav Kysela]

On Thu, 13 Feb 2003, Takashi Iwai wrote:

> Hi,
> 
> At Wed, 12 Feb 2003 14:35:29 -0800,
> Ryan Pavlik wrote:
> > 
> > On Wed, 12 Feb 2003 21:41:50 +0100 (CET)
> > Jaroslav Kysela <perex@suse.cz> wrote:
> > 
> > <snip> 
> > > It seems that mtpav don't remeber the old status byte for each
> > > channels. If it's true, then we need to take care about the expansion
> > > in the mtpav driver, because the sequencer MIDI driver removes
> > > duplicated status bytes to opmitize throughput.
> > <snip>
> > 
> > OK, I've attached a patch that emulated running status in the mtpav
> > driver, so there shouldn't be any need to change stuff elsewhere.
> > 
> > Thanks for your pointer, I've been wanting to fix this problem for a
> > very long time. :-)
> 
> thanks for the patch.
> i applied it to cvs with a little improvement (returning immediately
> if snd_rawmidi_transmit() gets null).
> 
> also, i found a bug regarding magic-alloc/free in the driver (at
> last!).  fixed on cvs, too.

Unfortunately, the patch is not perfect. I think that we need to buffer
the whole MIDI message and send it after completion, because it's
possible, that you'll get only partial MIDI message from the rawmidi API 
or at buffer overrun / full.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: [PATCH]: Bug: ALSA Sequencer or MTPAV - easy to reproduce

[Ryan Pavlik]

On Thu, 13 Feb 2003 17:27:25 +0100 (CET)
Jaroslav Kysela <perex@suse.cz> wrote:

<snip> 
> Unfortunately, the patch is not perfect. I think that we need to
> buffer the whole MIDI message and send it after completion, because
> it's possible, that you'll get only partial MIDI message from the
> rawmidi API or at buffer overrun / full.
<snip> 

Actually I have thought of this off and on, and figured that it
would probably be a Bad Thing:

   1)  It'd be painful to implement.  The mtpav driver would need a
       full understanding of MIDI, which means reimplementing things
       that are already there at higher levels.

         - You need to know the length of each message
         - You can't rely on finding the next status & 0x80, because
           it might not arrive right away
         - Buffering large Sysex dumps would suck ;)
         - "Other" messages you don't understand might not get through

   2)  More importantly: buffering would increase latency, which is
       always the reason I don't sit down and start coding.

It's true that it would be nice to be able to send partial messages,
though, but most things use the ALSA sequencer API anyway.


-- 
Ryan Pavlik <rpav@users.sf.net>

"Oh for the love of evil, not this again." - 8BT


-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: [PATCH]: Bug: ALSA Sequencer or MTPAV - easy to reproduce

[Jaroslav Kysela]

On Thu, 13 Feb 2003, Ryan Pavlik wrote:

> On Thu, 13 Feb 2003 17:27:25 +0100 (CET)
> Jaroslav Kysela <perex@suse.cz> wrote:
> 
> <snip> 
> > Unfortunately, the patch is not perfect. I think that we need to
> > buffer the whole MIDI message and send it after completion, because
> > it's possible, that you'll get only partial MIDI message from the
> > rawmidi API or at buffer overrun / full.
> <snip> 
> 
> Actually I have thought of this off and on, and figured that it
> would probably be a Bad Thing:
> 
>    1)  It'd be painful to implement.  The mtpav driver would need a
>        full understanding of MIDI, which means reimplementing things
>        that are already there at higher levels.
> 
>          - You need to know the length of each message
>          - You can't rely on finding the next status & 0x80, because
>            it might not arrive right away
>          - Buffering large Sysex dumps would suck ;)
>          - "Other" messages you don't understand might not get through
> 
>    2)  More importantly: buffering would increase latency, which is
>        always the reason I don't sit down and start coding.
> 
> It's true that it would be nice to be able to send partial messages,
> though, but most things use the ALSA sequencer API anyway.

The problem is that the driver is still buggy (only a bit less probably)
and output will not be correct under some circumstances.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en