MTP/AV / Sequencer MIDI problem... design issue?

MTP/AV / Sequencer MIDI problem... design issue?

[Ryan Pavlik]

Basically, the problem is this.  The MTP/AV protocol takes messages
like this:

   Dn B1 ... Bn

Where Dn is the device number, and B1..Bn are the midi message bytes.
This, at least, is what I gather from talking to Michael Mayers, the
original driver developer.

You may see the problem now.  When multiple threads talk to the device
at once, you have a problem:

A:  Dn B1 ,, ,, B2 ...
B:        Dn B1 ,, ...

The userland solution, when writing raw midi, is to just put a mutex
on the device and never write an incomplete message.

That is, of course, not an acceptable solution, and it also doesn't
work when you're using the ALSA sequencer interface (at least from the
API calls I've seen).  Fixing it in the driver requires interpreting
much MIDI, possibly buffering, and has some problems (what if someone
writes an incomplete message and dies?).

I'd like to hear recommendations; I have a particular interest in
seeing this work and am more than willing to submit patches.

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

"Hey! Captain talks-too-much, quiet time is now."


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: MTP/AV / Sequencer MIDI problem... design issue?

[Paul Davis]

>That is, of course, not an acceptable solution, and it also doesn't
>work when you're using the ALSA sequencer interface (at least from the
>API calls I've seen).  Fixing it in the driver requires interpreting
>much MIDI, possibly buffering, and has some problems (what if someone
>writes an incomplete message and dies?).

its not a solution to the problem, but i think its important to note
the behaviour of write(2) for FIFOs. if the byte count argument is
below the size of the pipe, the write(2) is atomic - that is, either
the entire write completes and the data is delivered to the pipe as a
continuous byte stream, or it does not and none of it is delivered.

i would hope that ALSA implemented similar semantics for MIDI
devices. the question would still remain: what is the equivalent to
the "size of the FIFO" (which is 5kB by the way).

if ALSA does supply these semantics, then you just need to make sure
that the messages are below the size limit and that they are delivered
in a single call.

i know this doesn't work for super-large sysex messages.

however, back to the core question:

>The userland solution, when writing raw midi, is to just put a mutex
>on the device and never write an incomplete message.
>
>That is, of course, not an acceptable solution, and it also doesn't

i'm afraid its an entirely acceptable solution, and its the same one
required by many other non-audio, non-MIDI device types. if you have
multiple threads writing to a disk-file, for example, and they
interleave their calls to write(2), you will get mixed up data on
disk.

>work when you're using the ALSA sequencer interface (at least from the
>API calls I've seen). 

why not?

--p




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: MTP/AV / Sequencer MIDI problem... design issue?

[Jaroslav Kysela]

On Fri, 10 Jan 2003, Ryan Pavlik wrote:

> Basically, the problem is this.  The MTP/AV protocol takes messages
> like this:
> 
>    Dn B1 ... Bn
> 
> Where Dn is the device number, and B1..Bn are the midi message bytes.
> This, at least, is what I gather from talking to Michael Mayers, the
> original driver developer.
> 
> You may see the problem now.  When multiple threads talk to the device
> at once, you have a problem:
> 
> A:  Dn B1 ,, ,, B2 ...
> B:        Dn B1 ,, ...
> 
> The userland solution, when writing raw midi, is to just put a mutex
> on the device and never write an incomplete message.

ALSA driver should handle this correctly (at least current CVS code).
The write sequence is locked.

						Jaroslav

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



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: MTP/AV / Sequencer MIDI problem... design issue?

[Ryan Pavlik]

(I'm checking out CVS again after Jaroslav Kysela's note, but I thought
I'd reply to this and clear up my statements.)

On Sat, 11 Jan 2003 08:55:10 -0500
Paul Davis <paul@linuxaudiosystems.com> wrote:

> its not a solution to the problem, but i think its important to note
> the behaviour of write(2) for FIFOs. <snip>

True, except the MTPAV driver writes byte-by-byte. ;)

<snip> 
>
> >The userland solution, when writing raw midi, is to just put a mutex
> >on the device and never write an incomplete message.
> >
> >That is, of course, not an acceptable solution, and it also doesn't
> 
> i'm afraid its an entirely acceptable solution, and its the same one
> required by many other non-audio, non-MIDI device types. if you have
> multiple threads writing to a disk-file, for example, and they
> interleave their calls to write(2), you will get mixed up data on
> disk.

Actually, I mean it's not an acceptable solution because (at least till
recent CVS I suppose) it's been the _only_ solution: things which (have)
used the sequencer interface to talk to the MTPAV on multiple outputs
simply didn't work.  It can't be expected that everyone specially code
mtpav code, or that defeats the point of having ALSA.

But, of course, if you're writing to rawmidi, you'll probably have to
deal with this.

> >work when you're using the ALSA sequencer interface (at least from
> >the API calls I've seen). 
> 
> why not?

I have seen no ALSA API calls for "binding" devices together.  You queue
up messages and they get sent... but putting a mutex around queue calls
doesn't do anything for you.  (At least, I'm looking at this from what
the code said, and I very well could have been missing something.)

Anywayt, all of this should be moot if it's fixed now... off to compile.
;)

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

"DEPLOY THE ROCKET BOAT!"


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: MTP/AV / Sequencer MIDI problem... design issue?

[Paul Davis]

>> i'm afraid its an entirely acceptable solution, and its the same one
>> required by many other non-audio, non-MIDI device types. if you have
>> multiple threads writing to a disk-file, for example, and they
>> interleave their calls to write(2), you will get mixed up data on
>> disk.
>
>Actually, I mean it's not an acceptable solution because (at least till
>recent CVS I suppose) it's been the _only_ solution: things which (have)
>used the sequencer interface to talk to the MTPAV on multiple outputs
>simply didn't work.  It can't be expected that everyone specially code
>mtpav code, or that defeats the point of having ALSA.

not really. the mtpav is a "non-standard" device that uses special
values in the datastream to switch its output port. the ALSA sequencer
can't know this, and so it can't have any idea that strange things are
happening at the hardware level.

another example of this that i know a bit more about is on the
tropez+. this has two MIDI output ports, and you can switch between
them with 2 "unused" MIDI bytes. what should ALSA do if you deliver
those bytes in a data stream? how can it know what they will do? why
should it pay any attention at all to them?

--p


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: MTP/AV / Sequencer MIDI problem... design issue?

[Ryan Pavlik]

On Sat, 11 Jan 2003 18:31:51 -0500
Paul Davis <paul@linuxaudiosystems.com> wrote:

<snip>
> not really. the mtpav is a "non-standard" device that uses special
> values in the datastream to switch its output port. the ALSA sequencer
> can't know this, and so it can't have any idea that strange things are
> happening at the hardware level.

That's what drivers are for. ;)  The ALSA sequencer shouldn't have to
know of course, but the driver should be able to handle it, and the
architecture should allow a working driver.

Nothing is "standard", anyway... I would contend that if the system
has to consider something "nonstandard" and treat is specially, when
it's just like any other device (pick a midi device at random), then the
system is wrong.

I do not believe, however, ALSA is this way.

> another example of this that i know a bit more about is on the
> tropez+. this has two MIDI output ports, and you can switch between
> them with 2 "unused" MIDI bytes. what should ALSA do if you deliver
> those bytes in a data stream? how can it know what they will do? why
> should it pay any attention at all to them?

It should pay attention because it's a universal sound architecture that
provides software from low-level driver to API.  The low-level driver
is all that needs to know about this.  The higher-level interface
probably does not.

I'm sure all this has been discussed before---I see evidence of it in
the very design and generalization of ALSA itself.  I can't imagine this
design is by accident.

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

"DEPLOY THE ROCKET BOAT!"


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: MTP/AV / Sequencer MIDI problem... design issue?

[Ryan Pavlik]

On Sat, 11 Jan 2003 15:46:15 +0100 (CET)
Jaroslav Kysela <perex@perex.cz> wrote:

<snip>
> ALSA driver should handle this correctly (at least current CVS code).
> The write sequence is locked.

Hrm, I'll check through the code---after playing with it, it doesn't
appear things are 100% yet.  I had decent luck at first, with messages
not trampling each other, but as I added new sequences (using seq24 to
test), odd problems developed.

The first was port 1 acting like broadcast, which I haven't seen before;
this would be fixed temporarily by reloading the driver.  Then voices
started losing notes and messages, much as before.

I will look at the (new?) write locking and see if I can figure
something out.

Thanks,

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

"Nautical, schmautical. Give me one hour and I'll know
 enough to sail us into orbit!


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: MTP/AV / Sequencer MIDI problem... design issue?

[Paul Davis]

>That's what drivers are for. ;)  The ALSA sequencer shouldn't have to
>know of course, but the driver should be able to handle it, and the
>architecture should allow a working driver.

i'd agree with that.

>> another example of this that i know a bit more about is on the
>> tropez+. this has two MIDI output ports, and you can switch between
>> them with 2 "unused" MIDI bytes. what should ALSA do if you deliver
>> those bytes in a data stream? how can it know what they will do? why
>> should it pay any attention at all to them?
>
>It should pay attention because it's a universal sound architecture that
>provides software from low-level driver to API.  The low-level driver
>is all that needs to know about this.  

i was asking those questions somewhat rhetorically. the tropez+ driver
*does* watch for those special bytes, and will not deliver them. user
space is not allowed to switch ports using this mechanism - its a
technique restricted to the driver itself. user space gets to open
whichever port(s) it wants to open and writes to them.

i would have thought that the mtpav driver should do the same
thing. if you want to access all 8 ports, you should have 8 access
points (whether this is via the sequencer or the rawmidi interface),
and write to each one of them. the use of the "Dn" byte(s?) to switch
output ports shouldn't be exported to user space. 

--p



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: MTP/AV / Sequencer MIDI problem... design issue?

[Ryan Pavlik]

On Sat, 11 Jan 2003 20:50:49 -0500
Paul Davis <paul@linuxaudiosystems.com> wrote:
> 
> i would have thought that the mtpav driver should do the same
> thing. if you want to access all 8 ports, you should have 8 access
> points (whether this is via the sequencer or the rawmidi interface),
> and write to each one of them. the use of the "Dn" byte(s?) to switch
> output ports shouldn't be exported to user space. 

It does, and you do... except the driver has the problems with parallel
access of ports I mentioned in the original message.  When you access
them with the sequencer API, the driver/library doesn't seem to properly
send entire messages.  Thus the problem arises.

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

"Nautical, schmautical. Give me one hour and I'll know
 enough to sail us into orbit!


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: MTP/AV / Sequencer MIDI problem... design issue?

[Jaroslav Kysela]

On Sat, 11 Jan 2003, Ryan Pavlik wrote:

> On Sat, 11 Jan 2003 20:50:49 -0500
> Paul Davis <paul@linuxaudiosystems.com> wrote:
> > 
> > i would have thought that the mtpav driver should do the same
> > thing. if you want to access all 8 ports, you should have 8 access
> > points (whether this is via the sequencer or the rawmidi interface),
> > and write to each one of them. the use of the "Dn" byte(s?) to switch
> > output ports shouldn't be exported to user space. 
> 
> It does, and you do... except the driver has the problems with parallel
> access of ports I mentioned in the original message.  When you access
> them with the sequencer API, the driver/library doesn't seem to properly
> send entire messages.  Thus the problem arises.

If the device needs full midi messages a stream parser must be implemented 
in the mtpav driver. There is no guarantee, that the MIDI message is 
complete in the rawmidi implementation. It behaves like a char stream 
device (something like tty).

Example:

port #2 received three bytes from an application: 0x80 0x10 0x15
port #3 received three bytes from an application: 0x90 0x20 0x00

So the mtpav driver might send this sequence in this order:

0xf5 0x02 0x80 0xf5 0x03 0x90 0xf5 0x02 0x10 0x15 0xf5 0x03 0x20 0x00

Where 0xf5 0xXX are port addresses. There is guarantee (using spinlocks) 
that the port will receive the right values but not whole midi message at 
once.

I think that the problem might be in another code.

						Jaroslav

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



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com