Rawmidi bug or missed feature?

Rawmidi bug or missed feature?

[Peter Enderborg]

I have a program that read's from a raw midi device. In midi there are
some simple compression.
It is assumed that if the data flow is correct, and the data should be
interpreted as paramaters
to previus command if it's not a new command. But when I open a raw midi
stream I can get
in to the stream without having the "previus" command. Is there any way
to do a query or
reset the stream so I can get that command? If it's only one midi
channel sending the same type of command it will never get in to sync!


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Paul Davis]

>I have a program that read's from a raw midi device. In midi there
>are some simple compression.  It is assumed that if the data flow is
>correct, and the data should be interpreted as paramaters to previus
>command if it's not a new command. But when I open a raw midi stream
>I can get in to the stream without having the "previus" command. Is
>there any way to do a query or reset the stream so I can get that
>command? If it's only one midi channel sending the same type of
>command it will never get in to sync!

raw MIDI means ***RAW*** MIDI. there is no parsing, no state, no
history, no automatic reset. you just read and write a stream of
bytes.

it sounds as if you should issue a full MIDI reset sequence when you
open the device (all notes off on every channel, reset all controllers
to a default value, restore all programs to a known state, etc.)

--p

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Ricardo Colon]

It's not a bug or missing feature.

You're talking about opening a midi stream that is currently "running
status". Unfortunately, there's no way around it. I don't think it's
really possible to even guess what that previous status byte might have
been. So really you can't do anything until you receive the next status
byte.

I think this is part of the reason why MIDI programs give 4
metronome clicks before allowing you to record. So that they can sync with
the hardware.





On Fri, 1 Mar 2002, Paul Davis wrote:

> >I have a program that read's from a raw midi device. In midi there
> >are some simple compression.  It is assumed that if the data flow is
> >correct, and the data should be interpreted as paramaters to previus
> >command if it's not a new command. But when I open a raw midi stream
> >I can get in to the stream without having the "previus" command. Is
> >there any way to do a query or reset the stream so I can get that
> >command? If it's only one midi channel sending the same type of
> >command it will never get in to sync!
>
> raw MIDI means ***RAW*** MIDI. there is no parsing, no state, no
> history, no automatic reset. you just read and write a stream of
> bytes.
>
> it sounds as if you should issue a full MIDI reset sequence when you
> open the device (all notes off on every channel, reset all controllers
> to a default value, restore all programs to a known state, etc.)
>
> --p
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
>


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Peter Enderborg]

Paul Davis wrote:

> >I have a program that read's from a raw midi device. In midi there
> >are some simple compression.  It is assumed that if the data flow is
> >correct, and the data should be interpreted as paramaters to previus
> >command if it's not a new command. But when I open a raw midi stream
> >I can get in to the stream without having the "previus" command. Is
> >there any way to do a query or reset the stream so I can get that
> >command? If it's only one midi channel sending the same type of
> >command it will never get in to sync!
>
> raw MIDI means ***RAW*** MIDI. there is no parsing, no state, no
> history, no automatic reset. you just read and write a stream of
> bytes.
>

Yes it raw. But it's sent by the sequcenser within alsa.  So the state is
there.

This is the configuration:

Roland MCR-8->midi-device->alsa-seq->user_code->alsa-seq->raw_midi

So how far back should I need to reset? The communication roland and
alsa-seq is in sync and
my user-land code is sending snd_seq_event_t. I guess that my problem
will disapear if I turn
active-sening-on and that is what I going to try.

>
> it sounds as if you should issue a full MIDI reset sequence when you
> open the device (all notes off on every channel, reset all controllers
> to a default value, restore all programs to a known state, etc.)
>

That will not help my reading. The device is in sync with alsaseq and
there shuld not
be needed to reset the transmitter. And even if I do. The merge of midi
streams could be
smart enough to see that it is of the same type.

>
> --p

--
foo!




_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Paul Davis]

>This is the configuration:
>
>Roland MCR-8->midi-device->alsa-seq->user_code->alsa-seq->raw_midi

this is a crazy, wierd setup! but i'll try to just let that be. i
suspect you don't mean "raw MIDI" the way its meant in ALSA.

>So how far back should I need to reset? The communication roland and
>alsa-seq is in sync and my user-land code is sending
>snd_seq_event_t. 

you need to get this figured out. how is your user-land code sending
snd_seq_event_t if you're using the raw MIDI interface? i think you're
using the sequencer interface, and referring to "raw" MIDI just
because you're looking at MIDI messages.

		  I guess that my problem will disapear if I turn
>active-sening-on and that is what I going to try.

no, that will not get rid of it. 

all MIDI devices are allowed to use running status any time they want.
if something hooks into an ongoing MIDI data exchange, and it needs to
be able to understand what is going on, there is absolutely zero
choice: a MIDI reset is required so that the transmitter stops using
running status for at least one message and the data stream becomes
parseable. 

now, as to what should issue that reset - thats a different
question. one might suggest that the ALSA sequencer should do so as
soon as it connects to an inbound port. but how can it? its ports are
uni-directional - it has no way of knowing that it should issue a MIDI
reset on a different port so that the input data stream on *this* port
becomes parseable again.

thats why many good MIDI devices have a way to do a "MIDI reset" at
the user's request, precisely to deal with this kind of situation. its
certainly present on my Miditemp Matrix MIDI router. 

i don't understand what your application is doing, but if you plan on
connecting to an ongoing data stream, be prepared to reset.

>That will not help my reading. The device is in sync with alsaseq and
>there shuld not be needed to reset the transmitter. And even if I
>do. The merge of midi streams could be smart enough to see that it is
>of the same type.

I don't understand any of this. "sync" and "type" have nothing to do
with what is going on. You need to force the transmitting device to
stop using running status for at least one message so that correct
parsing can begin.

--p

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Peter Enderborg]

Paul Davis wrote:

> >This is the configuration:
> >
> >Roland MCR-8->midi-device->alsa-seq->user_code->alsa-seq->raw_midi
>
> this is a crazy, wierd setup! but i'll try to just let that be. i
> suspect you don't mean "raw MIDI" the way its meant in ALSA.
>

What so weird about it? The user_code map some event's from the MCR-8 in
to
other. (Control to control, different values on the parameter. For
example to get the locators and jog
to work with Cubase) And the raw midi socket is sent to a midiman
interface with no alsa driver.

>
> >So how far back should I need to reset? The communication roland and
> >alsa-seq is in sync and my user-land code is sending
> >snd_seq_event_t.
>
> you need to get this figured out. how is your user-land code sending
> snd_seq_event_t if you're using the raw MIDI interface? i think you're
> using the sequencer interface, and referring to "raw" MIDI just
> because you're looking at MIDI messages.
>

No. My user_code is using seq API.

>
>                   I guess that my problem will disapear if I turn
> >active-sening-on and that is what I going to try.
>
> no, that will not get rid of it.
>
> all MIDI devices are allowed to use running status any time they want.
> if something hooks into an ongoing MIDI data exchange, and it needs to
> be able to understand what is going on, there is absolutely zero
> choice: a MIDI reset is required so that the transmitter stops using
> running status for at least one message and the data stream becomes
> parseable.
>
> now, as to what should issue that reset - thats a different
> question. one might suggest that the ALSA sequencer should do so as
> soon as it connects to an inbound port. but how can it? its ports are
> uni-directional - it has no way of knowing that it should issue a MIDI
> reset on a different port so that the input data stream on *this* port
> becomes parseable again.
>
> thats why many good MIDI devices have a way to do a "MIDI reset" at
> the user's request, precisely to deal with this kind of situation. its
> certainly present on my Miditemp Matrix MIDI router.
>

I guess roland are not good then.

>
> i don't understand what your application is doing, but if you plan on
> connecting to an ongoing data stream, be prepared to reset.
>
> >That will not help my reading. The device is in sync with alsaseq and
> >there shuld not be needed to reset the transmitter. And even if I
> >do. The merge of midi streams could be smart enough to see that it is
> >of the same type.
>
> I don't understand any of this. "sync" and "type" have nothing to do
> with what is going on. You need to force the transmitting device to
> stop using running status for at least one message so that correct
> parsing can begin.
>

Yes! And the device that is using running status is alsa rawmidi device.
It's not the roland device since I
get them correct to the user_code.  And how do I force the rawmidi device
to stop sending running status,
and that is the original question!

>
> --p

--
foo!




_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Paul Davis]

>Yes! And the device that is using running status is alsa rawmidi device.

What makes you think that? AFAIK, the raw MIDI device code does no
parsing of MIDI data at all ...

>It's not the roland device since I
>get them correct to the user_code.  And how do I force the rawmidi device
>to stop sending running status,
>and that is the original question!

I would have thought that if its not the Roland that is doing it, then
its the sequencer. 

--p

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Paul Davis]

>get them correct to the user_code.  And how do I force the rawmidi device
>to stop sending running status,

BTW, are you talking about running status, or active sensing?

--p

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Peter Enderborg]

Paul Davis wrote:

> >Yes! And the device that is using running status is alsa rawmidi device.
>
> What makes you think that? AFAIK, the raw MIDI device code does no
> parsing of MIDI data at all ...

Parsing? It sends raw midi on a stream. That stream is _from_ alsa seq. It is
doing
the bandwith optimize by it self. I do the parsing.

>
>
> >It's not the roland device since I
> >get them correct to the user_code.  And how do I force the rawmidi device
> >to stop sending running status,
> >and that is the original question!
>
> I would have thought that if its not the Roland that is doing it, then
> its the sequencer.
>
> --p

--
foo!




_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Jaroslav Kysela]

On Thu, 28 Feb 2002, Peter Enderborg wrote:

> I have a program that read's from a raw midi device. In midi there are
> some simple compression. It is assumed that if the data flow is correct,
> and the data should be interpreted as paramaters to previus command if
> it's not a new command. But when I open a raw midi stream I can get in
> to the stream without having the "previus" command. Is there any way to
> do a query or reset the stream so I can get that command? If it's only
> one midi channel sending the same type of command it will never get in
> to sync!

RawMidi devices don't interpret MIDI data in any way. So, you get exactly 
what's on input. Or are you refering virmidi devices?

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Jaroslav Kysela]

On Fri, 1 Mar 2002, Peter Enderborg wrote:

> Paul Davis wrote:
> 
> > >Yes! And the device that is using running status is alsa rawmidi device.
> >
> > What makes you think that? AFAIK, the raw MIDI device code does no
> > parsing of MIDI data at all ...
> 
> Parsing? It sends raw midi on a stream. That stream is _from_ alsa seq.
> It is doing the bandwith optimize by it self. I do the parsing.

Ok, please, specify your problem in a more detailed way. At least, we need 
to know about midi paths in your applications and what sequencer clients 
are involved to help you. And yes, there could be a problem with running 
status, because our converts work with it.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Peter Enderborg]

Jaroslav Kysela wrote:

> On Fri, 1 Mar 2002, Peter Enderborg wrote:
>
> > Paul Davis wrote:
> >
> > > >Yes! And the device that is using running status is alsa rawmidi device.
> > >
> > > What makes you think that? AFAIK, the raw MIDI device code does no
> > > parsing of MIDI data at all ...
> >
> > Parsing? It sends raw midi on a stream. That stream is _from_ alsa seq.
> > It is doing the bandwith optimize by it self. I do the parsing.
>
> Ok, please, specify your problem in a more detailed way. At least, we need
> to know about midi paths in your applications and what sequencer clients
> are involved to help you. And yes, there could be a problem with running
> status, because our converts work with it.
>

I don't know how to be more specific. I have a program that listen to a raw midi

stream generated by alsa. But I try.

I have a midisport 8x8. It have a serial port. I have a computer linux. Alsa
don't have
driver for the unit. So I have writen a daemon that open the snd-card-virmidi
with
snd_rawmidi_open(). I have also writen a processor that handels event on a
sequencer level
to interface my Roland MCR-8 with varius applications, synths. Roland MCR-8 a
"multicontroler"
but it is not progammable. It have 9 knobs,9 slides a lot of buttons an a dialer
wheel.
But not all apps have the same mapping of events.  So the processor mapps them i
the way I like
to have them. But it is only control messages.  On the daemon side that
interfaces to the
raw midi stream in encapsulate them in to midimans format and sent them over the
serial port
to the unit. The unit is decapsulate them and send it to the right midi port.
But when I open the
virmidi device in raw mode. I is already assuming that I know what was the last
command. In my case
a control message.  Is this clear enougth? I know that this a very common midi
problem, but it should not have to be a problem within the same machine.

>
>                                                 Jaroslav
>
> -----
> Jaroslav Kysela <perex@suse.cz>
> Linux Kernel Sound Maintainer
> ALSA Project  http://www.alsa-project.org
> SuSE Linux    http://www.suse.com
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel

--
foo!




_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Paul Davis]

>I don't know how to be more specific. I have a program that listen to
>a raw midi stream generated by alsa. But I try.

You have a program that uses the sequencer to read MIDI data. That's
totally different from a program that uses the raw MIDI interface to
read MIDI data. This is very, very important.

>I have a midisport 8x8. It have a serial port. I have a computer
>linux. Alsa don't have driver for the unit. So I have writen a daemon
>that open the snd-card-virmidi with snd_rawmidi_open(). 

This makes no sense at all to me. snd_rawmidi_open() is a way to 
get access to an ALSA low level, raw MIDI driver. For example, my
trident card has a MIDI port on it, and the trident driver contains
code to deliver and receive data from the port. If I want to
read/write that data stream, I would use snd_rawmidi_open().

But snd_rawmidi_open() has nothing to do with the sequencer, or with
virmidi. virmidi exists to make sequencer ports available via the raw
MIDI API so that programs which don't know about the sequencer can
still read and write data to it. 

If there is no ALSA driver for the unit (or for serial MIDI - I am not
sure if we have such a thing, do we?), then why would you be calling
snd_rawmidi_open()?

>							 I have also
>writen a processor that handels event on a sequencer level to
>interface my Roland MCR-8 with varius applications, synths. 

Why are you using the sequencer for this?

--p


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Peter Enderborg]

Paul Davis wrote:

> >I don't know how to be more specific. I have a program that listen to
> >a raw midi stream generated by alsa. But I try.
>
> You have a program that uses the sequencer to read MIDI data. That's
> totally different from a program that uses the raw MIDI interface to
> read MIDI data. This is very, very important.
>
> >I have a midisport 8x8. It have a serial port. I have a computer
> >linux. Alsa don't have driver for the unit. So I have writen a daemon
> >that open the snd-card-virmidi with snd_rawmidi_open().
>
> This makes no sense at all to me. snd_rawmidi_open() is a way to
> get access to an ALSA low level, raw MIDI driver. For example, my
> trident card has a MIDI port on it, and the trident driver contains
> code to deliver and receive data from the port. If I want to
> read/write that data stream, I would use snd_rawmidi_open().
>

Yes, and my device is a midisport.

>
> But snd_rawmidi_open() has nothing to do with the sequencer, or with
> virmidi. virmidi exists to make sequencer ports available via the raw
> MIDI API so that programs which don't know about the sequencer can
> still read and write data to it.
>

I do. I is a connection. I gets a client ID. So it have very mush to do
with the
sequencser.

>
> If there is no ALSA driver for the unit (or for serial MIDI - I am not
> sure if we have such a thing, do we?), then why would you be calling
> snd_rawmidi_open()?
>

There is a serial driver. But it dont handle the same protocol as
midisport.
So how should I connect my device so I can use the midisport to talk to
my synths?
Rawmid on a snd-card-virmidi gives one way. Show me a better way instead
of say that
im wrong.

>
> >                                                        I have also
> >writen a processor that handels event on a sequencer level to
> >interface my Roland MCR-8 with varius applications, synths.
>
> Why are you using the sequencer for this?

It is the api for midi programming. I don't have to think about active
sensing, streaming or
anything on the low level. And I get tools for routing the data as I
like. I thougth that you should
know the concept. Almost everything is in realtime. But some mappings i
done in the time domain
as well. For example the dialer.

>
>
> --p

--
foo!




_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: ALSA sequencer in user land (was: Rawmidi bug or missed feature?)

[Paul Davis]

Frank - 

thanks for writing. I don't want to suggest for one moment that there
is any "blame" to be attached to the current sequencer design. None of
us knew what we know now, and as you point out the hardware state of
affairs has changed considerably.

>Pentium 60 MHz (though faster iron was available by then). At that time the
>only way to get reliable, audibily tight timing from a sequencer was to do
>scheduling triggered by a hardware interrupt in kernel space. Since then the
>hardware and Linux kernel evolved, making similar things possible from
>userland code.

i'm not actually sure that this is true - i have a feeling that
SCHED_FIFO was supported back then, and wakeups of a user space thread
from a device driver interrupt would probably have been just as fast
(bar a couple of usecs). the point is, we didn't know about this back
then (or at least, the people involved didn't know, including me).

however, whether its true or not, its irrelevant. we know that right
now user space can do the job in an absolute sense - the question is:
is there an acceptable way to use this fact?

>I believe it would be a good thing to reconcider the various
>functions/responsibilities of the ALSA sequecer, and move certain parts to
>user space (=alsa lib), leaving the IPC to device drivers in place. 
	
by device drivers, i presume you mean "kernel modules". this is
actually the least efficient part of the current design - we always
end up copying data between user space clients. if we put the
multiplexor/router in user space and use shm, we can move data between
(user-space) clients without any data copying at all.
							     
>								     To the
>user these changes would be transparant.

Yes, they will be transparent, which is the only reason I feel even
vaguely comfortable suggesting any of this. I really mean that. I am
not suggesting a single API change to be associated with this idea,
and I would be alarmed if any came up.

>However, the application design could be a trouble maker in this case.
>Drawing the parralel from audio streams, one could write an application
>which is not designed for real-time performance, but does deliver good
>results because it's relying on the kernels' buffering (or scheduling in
>case of a sequencer). Once the scheduling becomes part of the userland
>application, this application's implementation and real-time performance
>becomes key for the effective timing quality of the system. Surely this can
>be solved (perhaps by enforcing some framework?), but this is sort of a
>concern to me.

JACK has precisely the same problem. We solve it by running the code
from libjack (well, almost all of it) in its own thread, which when
necessary has the correct scheduling characteristics to provide
correct timing.

The buffering isn't really an issue i think - the code for this would
be the same in both user space or kernel space, bar the change of
kmalloc to malloc (i know i'm glossing over a few points here, but i
think that its true in an important way). There would still be a
scheduler, and it would still be doing buffering.

No, the truly enormous problem is that of permissions. SCHED_FIFO and
mlockall() will provide the performance we want/need. But you can't
get them without having either root euid or CAP_RESOURCE. no kernels
from any distributor or even from the default build procedure come
with capabilities enabled, and so CAP_RESOURCE is a dead-end for
now. I don't anyone who is using capabilities for anything on a
regular basis. Requiring root euid is a terrible idea. So this is a
huge stumbling block. 

OTOH, JACK faces this too, and we "get around it" by providing
adequate performance (more than adequate in some cases) without
SCHED_FIFO, and say that if you want better performance, then root
permission or a capabilities-enabled kernel is required.

Even so, I recognize that for most people this represents a step
backwards. They associate the kernel with rock solid timing (even
though it isn't), and then they find out that not only have we
provided worse performance by default, but that to get back the good
stuff, their programs need to run as root ... :((

Its not quite that bad here, however, since the majority of programs
that use MIDI pre-generate the data and are not subject to the same
kinds of continuous real-time parameter changes that invalid
already-delivered or computed data. As a result, most applications
will not upset the operation of a real-time scheduler because they
don't have to do things in a real-time way. Programs like playmidi and
pmidi basically just convert MIDI data streams to a long list of
sequencer events and then deliver that to the sequencer. This will
work just fine without these programs having RT scheduling. 

Programs like MusE, SoftWerk, KeyKit and so forth are more difficult
because they generate their data on a just-in-time basis, and hence
will need RT-scheduling if they are going to work correctly with an RT
scheduler. 

The reason this interests me so much is that the next obvious step for
JACK is to add MIDI support. I don't really want to do this when the
sequencer does everything we would want to add, but OTOH, the
sequencer's basic premise - kernel space operation - doesn't work well
for JACK. Reinventing the wheel is not without its appeal for me (:))
but it seems like a real waste of effort. I'd much rather figure out
how to take all the good work that you, Takashi, Jaroslav and Abramo
have done and be able to use it within JACK as a routing mechanism
(perhaps scheduling too, but I am not sure).

--p


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Roger E Critchlow Jr]

Peter Enderborg writes:
 > Jaroslav Kysela wrote:
 > 
 > > On Fri, 1 Mar 2002, Peter Enderborg wrote:
 > >
 > > > Paul Davis wrote:
 > > >
 > > > > >Yes! And the device that is using running status is alsa rawmidi device.
 > > > >
 > > > > What makes you think that? AFAIK, the raw MIDI device code does no
 > > > > parsing of MIDI data at all ...
 > > >
 > > > Parsing? It sends raw midi on a stream. That stream is _from_ alsa seq.
 > > > It is doing the bandwith optimize by it self. I do the parsing.
 > >
 > > Ok, please, specify your problem in a more detailed way. At least, we need
 > > to know about midi paths in your applications and what sequencer clients
 > > are involved to help you. And yes, there could be a problem with running
 > > status, because our converts work with it.
 > >
 > 
 > I don't know how to be more specific. I have a program that listen to a raw midi
 > 
 > stream generated by alsa. But I try.
 > 
 > I have a midisport 8x8. It have a serial port. I have a computer linux. Alsa
 > don't have
 > driver for the unit. So I have writen a daemon that open the snd-card-virmidi
 > with
 > snd_rawmidi_open(). I have also writen a processor that handels event on a
 > sequencer level
 > to interface my Roland MCR-8 with varius applications, synths. Roland MCR-8 a
 > "multicontroler"
 > but it is not progammable. It have 9 knobs,9 slides a lot of buttons an a dialer
 > wheel.
 > But not all apps have the same mapping of events.  So the processor mapps them i
 > the way I like
 > to have them. But it is only control messages.  On the daemon side that
 > interfaces to the
 > raw midi stream in encapsulate them in to midimans format and sent them over the
 > serial port
 > to the unit. The unit is decapsulate them and send it to the right midi port.
 > But when I open the
 > virmidi device in raw mode. I is already assuming that I know what was the last
 > command. In my case
 > a control message.  Is this clear enougth? I know that this a very common midi
 > problem, but it should not have to be a problem within the same machine.
 > 

I think you want to do this differently.

Your program for patching the midisport into the alsa sequencer
should connect to the midisport driver on one side and the sequencer
event interface on the other side and use the alsa/snd_midi_event.h
routines to translate between the two.

So, as you read raw midi bytes from the midisport driver, use

    /* encode from byte stream -
       return number of written bytes if success */
    long snd_midi_event_encode(snd_midi_event_t *dev,
			       unsigned char *buf,
			       long count,
			       snd_seq_event_t *ev);

to encode the incoming byte stream into snd_seq_event_t and send the
events the sequencer using the event interface.

As you receive events from the sequencer, use

   /* decode from event to bytes -
      return number of written bytes if success */
   long snd_midi_event_decode(snd_midi_event_t *dev,
                              unsigned char *buf,
                              long count,
                              snd_seq_event_t *ev);

to decode the incoming event stream into a midi byte stream which you
can then write() to the midisport.

You will need to send a reset on the midisport side when you first
connect to get the snd_midi_event_t state synchronized to the incoming
running status.

But you won't see any running status from the alsa side because the
event interface fully identifies each event.  snd_midi_event_decode
will use running status on the decode side, but the stream generated
will start from the first event decoded.

Does this help?

-- rec --

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Paul Davis]

>It is the api for midi programming. I don't have to think about
>active sensing, streaming or anything on the low level. And I get
>tools for routing the data as I like. I thougth that you should know
>the concept. Almost everything is in realtime. But some mappings i
>done in the time domain as well. For example the dialer.

I don't use the sequencer for anything. I don't agree that its "the
API for MIDI programming". Perhaps I should just keep my mouth
closed. Roger seems to have better suggestions ....

--p

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Peter Enderborg]

Roger E Critchlow Jr wrote:

> Peter Enderborg writes:
>  > Jaroslav Kysela wrote:
>  >
>  > > On Fri, 1 Mar 2002, Peter Enderborg wrote:
>  > >
>  > > > Paul Davis wrote:
>  > > >
>  > > > > >Yes! And the device that is using running status is alsa rawmidi device.
>  > > > >
>  > > > > What makes you think that? AFAIK, the raw MIDI device code does no
>  > > > > parsing of MIDI data at all ...
>  > > >
>  > > > Parsing? It sends raw midi on a stream. That stream is _from_ alsa seq.
>  > > > It is doing the bandwith optimize by it self. I do the parsing.
>  > >
>  > > Ok, please, specify your problem in a more detailed way. At least, we need
>  > > to know about midi paths in your applications and what sequencer clients
>  > > are involved to help you. And yes, there could be a problem with running
>  > > status, because our converts work with it.
>  > >
>  >
>  > I don't know how to be more specific. I have a program that listen to a raw midi
>  >
>  > stream generated by alsa. But I try.
>  >
>  > I have a midisport 8x8. It have a serial port. I have a computer linux. Alsa
>  > don't have
>  > driver for the unit. So I have writen a daemon that open the snd-card-virmidi
>  > with
>  > snd_rawmidi_open(). I have also writen a processor that handels event on a
>  > sequencer level
>  > to interface my Roland MCR-8 with varius applications, synths. Roland MCR-8 a
>  > "multicontroler"
>  > but it is not progammable. It have 9 knobs,9 slides a lot of buttons an a dialer
>  > wheel.
>  > But not all apps have the same mapping of events.  So the processor mapps them i
>  > the way I like
>  > to have them. But it is only control messages.  On the daemon side that
>  > interfaces to the
>  > raw midi stream in encapsulate them in to midimans format and sent them over the
>  > serial port
>  > to the unit. The unit is decapsulate them and send it to the right midi port.
>  > But when I open the
>  > virmidi device in raw mode. I is already assuming that I know what was the last
>  > command. In my case
>  > a control message.  Is this clear enougth? I know that this a very common midi
>  > problem, but it should not have to be a problem within the same machine.
>  >
>
> I think you want to do this differently.
>
> Your program for patching the midisport into the alsa sequencer
> should connect to the midisport driver on one side and the sequencer
> event interface on the other side and use the alsa/snd_midi_event.h
> routines to translate between the two.
>
> So, as you read raw midi bytes from the midisport driver, use
>
>     /* encode from byte stream -
>        return number of written bytes if success */
>     long snd_midi_event_encode(snd_midi_event_t *dev,
>                                unsigned char *buf,
>                                long count,
>                                snd_seq_event_t *ev);
>
> to encode the incoming byte stream into snd_seq_event_t and send the
> events the sequencer using the event interface.
>
> As you receive events from the sequencer, use
>
>    /* decode from event to bytes -
>       return number of written bytes if success */
>    long snd_midi_event_decode(snd_midi_event_t *dev,
>                               unsigned char *buf,
>                               long count,
>                               snd_seq_event_t *ev);
>
> to decode the incoming event stream into a midi byte stream which you
> can then write() to the midisport.
>
> You will need to send a reset on the midisport side when you first
> connect to get the snd_midi_event_t state synchronized to the incoming
> running status.
>
> But you won't see any running status from the alsa side because the
> event interface fully identifies each event.  snd_midi_event_decode
> will use running status on the decode side, but the stream generated
> will start from the first event decoded.
>
> Does this help?
>

Well. I guess it do. I will give it a try. It should work.  What about non midi
snd_seq_event_t.
The internal alsa stuff, like subscribe?

>
> -- rec --
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel

--
foo!




_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Peter Enderborg]

Paul Davis wrote:

> >It is the api for midi programming. I don't have to think about
> >active sensing, streaming or anything on the low level. And I get
> >tools for routing the data as I like. I thougth that you should know
> >the concept. Almost everything is in realtime. But some mappings i
> >done in the time domain as well. For example the dialer.
>
> I don't use the sequencer for anything. I don't agree that its "the
> API for MIDI programming". Perhaps I should just keep my mouth
> closed. Roger seems to have better suggestions ....
>

How do you solve the problem with sharing hardware then?

>
> --p

--
foo!




_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Paul Davis]

>How do you solve the problem with sharing hardware then?

I don't. I intend to wait for (and contribute too, if I can) what I
consider the correct solution:

  a) sequencer genuinely split into:

          1) a router/multiplexer
	  2) a scheduler

  b) sequencer moves into user space

As I've said before, I don't consider the current kernel-side
implementation of the sequencer, nor its merging of two completely
different functions, to be in anyone's interest. I think that Frank
was (like myself and everyone else) somewhat "blinded" by the fact
that OSS put the sequencer in the kernel, and we did not know that it
was possible to get similar performance in user space.

For the time being, I have hardware solutions that work for me when I
need to do complex MIDI routing (i.e. dedicated h/w MIDI patchbays),
and I never run multiple apps using the same port.

--p

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Peter Enderborg]

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

Paul Davis wrote:

> >How do you solve the problem with sharing hardware then?
>
> I don't. I intend to wait for (and contribute too, if I can) what I
> consider the correct solution:
>
>   a) sequencer genuinely split into:
>
>           1) a router/multiplexer
>           2) a scheduler
>
>   b) sequencer moves into user space
>
> As I've said before, I don't consider the current kernel-side
> implementation of the sequencer, nor its merging of two completely
> different functions, to be in anyone's interest. I think that Frank
> was (like myself and everyone else) somewhat "blinded" by the fact
> that OSS put the sequencer in the kernel, and we did not know that it
> was possible to get similar performance in user space.

How can we get the same performance i userspace? For me it is the
processor/OS schedule that gives the limit for that, and in kernel we
get
the hardware as the limit.

>
>
> For the time being, I have hardware solutions that work for me when I
> need to do complex MIDI routing (i.e. dedicated h/w MIDI patchbays),
> and I never run multiple apps using the same port.
>
> --p

--
foo!



[-- Attachment #2: Type: text/html, Size: 1415 bytes --]

Re: Rawmidi bug or missed feature?

[Paul Davis]

>How can we get the same performance i userspace? For me it is the
>processor/OS schedule that gives the limit for that, and in kernel we
>get
>the hardware as the limit.

there are two things done by the sequencer:

     a) routing/multiplexing
	
	this is mostly a matter of code design and memory management,
	and can be handled just as well in user space as in the
	kernel, perhaps even better (other libs can be used, for
	instance). there is almost nothing i can think of relating to
	this work that requires or even benefits from a kernel side
	location. 

     b) scheduling
     
        the kernel has no special access to system hardware for timing
	that is not available to a root-enabled or CAP_RESOURCE-enabled	
	task. the default system timer that the vast majority of
	sequencer users will use is of much worse resolution than some
	of the alternatives such as the RTC and a PCM audio
	clock.	

	however, both of these sources (as well as the default system
	timer) are available to user space processes. there is a
	small overhead involved, on the order of 2-10 microseconds, if
	that. 

	Since the sequencer would have to run with these permissions
	to be useful, as a user space process it has the same
	scheduling capabilities as it does in the kernel (for our
	purposes; obviously, it can't schedule processes in the same
	way as the OS task scheduler, but then for that matter,
	neither can the existing kernel sequencer).

	the processor has no part to play in scheduling except for
	executing code. fast processors don't schedule faster other
	than in the sense that they execute the scheduling code
	(whether its in user space or not) more or less quickly.
	
By putting the sequencer in user space we:

  a) remove a large and necessarily complex piece of code from the
       kernel, nearly always a good thing
  b) allow it to be developed more flexibly (code errors don't
       cause system panics or hangs)
  c) can make it more modular
  d) can port it to non-Linux systems more easily
  e) can extend it to work within or alongside other designs more easily

--p

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: ALSA sequencer in user land (was: Rawmidi bug or missed feature?)

[Paul Davis]

>ok, don't forget to put CAPs on the 2.5 wishlist :-)

they are already implemented and maintained. its just that (almost)
nobody turns them on. 

>> OTOH, JACK faces this too, and we "get around it" by providing
>> adequate performance (more than adequate in some cases) without
>> SCHED_FIFO, and say that if you want better performance, then root
>> permission or a capabilities-enabled kernel is required.
>
>Audio streams use the buffering from kernel space. 

Not JACK. It (or rather, the ALSA PCM JACK driver) uses mmap mode to
write directly into the hardware buffer. There is no kernel side
buffering at all. I've therefore skipped your observations based on
this idea - its simply wrong.

>I'm not certain yet how to proceed with all of this (damn... I just broke
>that crystal bulb that allows me to look in the future). Some wild thoughts
>going through my mind:
>
>- ALSA sequencer kernel scheduling is good for micro scheduling [1]

i claim the opposite. its harder for the kernel to use hardware
interrupts as timers - this is not part of the kernel design (though
it can be done, as with the PCM timers and Takashi's RTC patch).
having h/w interrupts wake up tasks is absolutely what the kernel is
all about. by trying to do more-accurate-than-HZ scheduling in the
kernel, you are trying to get the kernel to do something it doesn't
really want to do, but its quite happy helping you to achieve this in
user space (even if it might not necessarily succeed; if it fails,
however, it would have failed in the kernel as well).

>- Move as much complexity as possible from alsa-driver to alsa-lib
>- Using user land ipc (shm) to send data accros user land clients, avoiding
>  event fiddling in kernel space
>- I'm exited by the elegance of Jack's model. An ALSA sequencer (or alike)
>  event interface would be great to complement Jack.

right, and i can see how to implement 80% of it in a day. however, my
experience tells me that the other 20% will take 80% of the time, and
that the entire 100% has already been coded as part of the sequencer.
in particular, queues and buffering are tricky, and doing them with
shm is going to be even trickier, though the nice shm-based
reimplementations of malloc should help.

the problem with JACK's model for MIDI is that JACK is built around
the idea of streaming data and synchronicity. MIDI isn't like that,
really. Well, MIDI *delivery* is like that: "at time N, deliver these
bytes to here". But MIDI *receipt* is asynchronous with respect to the
audio stream. 

i *could* just go ahead and implement this within JACK, but i still
have a gut feeling that its a bad idea.

>- Avoid ending up with an alsa-lib router/scheduler sitting on top of an
>  alsa-kernel router/scheduler (unless there is a good reason for it). [2]

Yes, this sounds like it would be a nightmare.

>ad 1: There is a growing number of (propiatary/undocumented) USB midi
>devices that perform their own timing scheme. Providing a sequencer/event
>API to the applications and allow for (either alsa-lib or alsa kernel)
>scheduling makes use of these devices transparent to the
>application. 

As I've said in several recent emails on LAD, I think this should be
added to the raw MIDI API, something like:

      snd_rawmidi_queue (snd_rawmidi_t *, char *data, size_t bytes,
			 snd_rawmidi_time_t when);

it would return -EINVAL if the handle refers to a device that cannot
do pre-queueing. its a natural complement to snd_rawmidi_{read,write},
IMHO, and involves exactly the same mechanisms inside the driver (such
devices need a delivery time of "now" for ordinary read/writes anyway).

a bigger problem is actually looming: neither USB nor IEEE1394 support
is well worked out for ALSA yet. presumably, we'll do it by having
alsa-lib call into a userspace library that accesses the USB/IEEE1394
device drivers, does protocol translation and so forth. but we don't
have any working examples of this yet, and its not clear how well it
will work. i *think* it will work well, but i'm just a little nervous,
because in a few years, these devices will totally dominate the
landscape of what's available to buy.

>ad 2: The vision of having similar functionality in all layers makes me
>scared, and makes me wonder if that would be a good route to take. Think of
>an application like Muse (seq.#1) using alsa-lib (seq.#2) and
>alsa-kernel (seq.#3) driving an MOTU USB interface (seq.#4). Perhaps some
>futher though would prove if I'm seeing ghosts or not.

I am told that MusE never uses the queuing facilities of the
sequencer. So you can make that MusE->MOTU USB. Does that make you
feel better? :))

--p


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Roger E Critchlow Jr]

Peter Enderborg writes:
 >
 > Roger E Critchlow Jr wrote:

 [ ... ]

 > > Does this help?
 > >
 > 
 > Well. I guess it do. I will give it a try. It should work.  What about non midi
 > snd_seq_event_t.
 > The internal alsa stuff, like subscribe?
 > 

Hmm, hadn't thought about it.  You can look at the event type and
decide whether it's worth decoding, or just hand it to the decoder
and see if events which don't translate to midi just go away by
themselves, or you could look at the source for the library and see
if snd_seq_set_client_event_filter can do the work for you.

-- rec --

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Rawmidi bug or missed feature?

[Peter Enderborg]

Roger E Critchlow Jr wrote:

> Peter Enderborg writes:
>  >
>  > Roger E Critchlow Jr wrote:
>
>  [ ... ]
>
>  > > Does this help?
>  > >
>  >
>  > Well. I guess it do. I will give it a try. It should work.  What about non midi
>  > snd_seq_event_t.
>  > The internal alsa stuff, like subscribe?
>  >
>
> Hmm, hadn't thought about it.  You can look at the event type and
> decide whether it's worth decoding, or just hand it to the decoder
> and see if events which don't translate to midi just go away by
> themselves, or you could look at the source for the library and see
> if snd_seq_set_client_event_filter can do the work for you.
>

Im playing with it now. Realy nice. But there are some feature that are missing I
think
There are some undefined messages within the midi spec.  The bytes F4, F5,F9,FD are
undefined. Right now the parser ignores them and that make's thinks a little harder
for me...
An idea is that alsa could encapulate them in a own variable length message.
Otherwise we
can not be transparant! (or have I missed something?)

>
> -- rec --
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel

--
foo!




_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

ALSA sequencer in user land (was: Rawmidi bug or missed feature?)

[Frank van de Pol]

Paul,

I must admit that looking at the current state of things a move or migration
of the ALSA sequencer to user space (either fully or partially) would be a
good thing. 

At the time I came up with the ALSA sequencer we were talking about alsa
0.0.12. It was 1998, yet only 4 years ago and my development machine was a
Pentium 60 MHz (though faster iron was available by then). At that time the
only way to get reliable, audibily tight timing from a sequencer was to do
scheduling triggered by a hardware interrupt in kernel space. Since then the
hardware and Linux kernel evolved, making similar things possible from
userland code.

I believe it would be a good thing to reconcider the various
functions/responsibilities of the ALSA sequecer, and move certain parts to
user space (=alsa lib), leaving the IPC to device drivers in place. To the
user these changes would be transparant.

However, the application design could be a trouble maker in this case.
Drawing the parralel from audio streams, one could write an application
which is not designed for real-time performance, but does deliver good
results because it's relying on the kernels' buffering (or scheduling in
case of a sequencer). Once the scheduling becomes part of the userland
application, this application's implementation and real-time performance
becomes key for the effective timing quality of the system. Surely this can
be solved (perhaps by enforcing some framework?), but this is sort of a
concern to me.


Cheers,
Frank.


On Sat, Mar 02, 2002 at 02:31:50PM -0500, Paul Davis wrote:
> >How can we get the same performance i userspace? For me it is the
> >processor/OS schedule that gives the limit for that, and in kernel we
> >get
> >the hardware as the limit.
> 
> there are two things done by the sequencer:
> 
>      a) routing/multiplexing
> 	
> 	this is mostly a matter of code design and memory management,
> 	and can be handled just as well in user space as in the
> 	kernel, perhaps even better (other libs can be used, for
> 	instance). there is almost nothing i can think of relating to
> 	this work that requires or even benefits from a kernel side
> 	location. 
> 
>      b) scheduling
>      
>         the kernel has no special access to system hardware for timing
> 	that is not available to a root-enabled or CAP_RESOURCE-enabled	
> 	task. the default system timer that the vast majority of
> 	sequencer users will use is of much worse resolution than some
> 	of the alternatives such as the RTC and a PCM audio
> 	clock.	
> 
> 	however, both of these sources (as well as the default system
> 	timer) are available to user space processes. there is a
> 	small overhead involved, on the order of 2-10 microseconds, if
> 	that. 
> 
> 	Since the sequencer would have to run with these permissions
> 	to be useful, as a user space process it has the same
> 	scheduling capabilities as it does in the kernel (for our
> 	purposes; obviously, it can't schedule processes in the same
> 	way as the OS task scheduler, but then for that matter,
> 	neither can the existing kernel sequencer).
> 
> 	the processor has no part to play in scheduling except for
> 	executing code. fast processors don't schedule faster other
> 	than in the sense that they execute the scheduling code
> 	(whether its in user space or not) more or less quickly.
> 	
> By putting the sequencer in user space we:
> 
>   a) remove a large and necessarily complex piece of code from the
>        kernel, nearly always a good thing
>   b) allow it to be developed more flexibly (code errors don't
>        cause system panics or hangs)
>   c) can make it more modular
>   d) can port it to non-Linux systems more easily
>   e) can extend it to work within or alongside other designs more easily
> 
> --p
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel

-- 
+---- --- -- -  -   -    - 
| Frank van de Pol                  -o)    A-L-S-A
| FvdPol@home.nl                    /\\  Sounds good!
| http://www.alsa-project.org      _\_v
| Linux - Why use Windows if we have doors available?

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: ALSA sequencer in user land (was: Rawmidi bug or missed feature?)

[Frank van de Pol]

On Sat, Mar 02, 2002 at 12:55:00PM -0500, Paul Davis wrote:
> 
> >I believe it would be a good thing to reconcider the various
> >functions/responsibilities of the ALSA sequecer, and move certain parts to
> >user space (=alsa lib), leaving the IPC to device drivers in place. 
> 	
> by device drivers, i presume you mean "kernel modules". this is
> actually the least efficient part of the current design - we always
> end up copying data between user space clients. if we put the
> multiplexor/router in user space and use shm, we can move data between
> (user-space) clients without any data copying at all.

I was thinking of the alsa clients written as kernel modules, such as I/O
ports and synth drivers. Once talking about user->user messaging (which
becomes more and more common with eg. Muse's soft synths) a user space
mux/router might be a good thing.

> 							     
> >								     To the
> >user these changes would be transparant.
> 
> Yes, they will be transparent, which is the only reason I feel even
> vaguely comfortable suggesting any of this. I really mean that. I am
> not suggesting a single API change to be associated with this idea,
> and I would be alarmed if any came up.

Yeps!

> 
> >However, the application design could be a trouble maker in this case.
> >Drawing the parralel from audio streams, one could write an application
> >which is not designed for real-time performance, but does deliver good
> >results because it's relying on the kernels' buffering (or scheduling in
> >case of a sequencer). Once the scheduling becomes part of the userland
> >application, this application's implementation and real-time performance
> >becomes key for the effective timing quality of the system. Surely this can
> >be solved (perhaps by enforcing some framework?), but this is sort of a
> >concern to me.
> 
> JACK has precisely the same problem. We solve it by running the code
> from libjack (well, almost all of it) in its own thread, which when
> necessary has the correct scheduling characteristics to provide
> correct timing.
> 
> The buffering isn't really an issue i think - the code for this would
> be the same in both user space or kernel space, bar the change of
> kmalloc to malloc (i know i'm glossing over a few points here, but i
> think that its true in an important way). There would still be a
> scheduler, and it would still be doing buffering.
> 
> No, the truly enormous problem is that of permissions. SCHED_FIFO and
> mlockall() will provide the performance we want/need. But you can't
> get them without having either root euid or CAP_RESOURCE. no kernels
> from any distributor or even from the default build procedure come
> with capabilities enabled, and so CAP_RESOURCE is a dead-end for
> now. I don't anyone who is using capabilities for anything on a
> regular basis. Requiring root euid is a terrible idea. So this is a
> huge stumbling block. 

ok, don't forget to put CAPs on the 2.5 wishlist :-)

> 
> OTOH, JACK faces this too, and we "get around it" by providing
> adequate performance (more than adequate in some cases) without
> SCHED_FIFO, and say that if you want better performance, then root
> permission or a capabilities-enabled kernel is required.

Audio streams use the buffering from kernel space. If running from a process
without SCHED_FIFO et al, this is still posibile at the cost of some higher
latency, ie. more samples to be buffered by the kernel driver.

If you want to run a sequencer application, the SCHED_FIFO becomes mandatory
for getting decent timing. It's then no longer a question of "you can run
without it at the expense of higher latency", but the difference between
rock-steady or fluttering beats. Take Muse for example: you can't run in it
without SCHED_FIFO for tigh timing.

Applications generating just in time data (eg. Softwerk, and to some extend
Muse) always had, and always wil have the requirement to run SCHED_FIFO.
However most MIDI applications (including Muse) know what events should be
played ahead of time. 

I'm not certain yet how to proceed with all of this (damn... I just broke
that crystal bulb that allows me to look in the future). Some wild thoughts
going through my mind:

- ALSA sequencer kernel scheduling is good for micro scheduling [1]
- Move as much complexity as possible from alsa-driver to alsa-lib
- Using user land ipc (shm) to send data accros user land clients, avoiding
  event fiddling in kernel space
- I'm exited by the elegance of Jack's model. An ALSA sequencer (or alike)
  event interface would be great to complement Jack.
- Avoid ending up with an alsa-lib router/scheduler sitting on top of an
  alsa-kernel router/scheduler (unless there is a good reason for it). [2]

ad 1: There is a growing number of (propiatary/undocumented) USB midi
devices that perform their own timing scheme. Providing a sequencer/event
API to the applications and allow for (either alsa-lib or alsa kernel)
scheduling makes use of these devices transparent to the application. The
alsa client driver for these USB midi ports could send the events a few ms
ahead of time and let that device handle timing. Same applies for softsynths
which have a known latency hence want to receive events ahead of time.

ad 2: The vision of having similar functionality in all layers makes me
scared, and makes me wonder if that would be a good route to take. Think of
an application like Muse (seq.#1) using alsa-lib (seq.#2) and
alsa-kernel (seq.#3) driving an MOTU USB interface (seq.#4). Perhaps some
futher though would prove if I'm seeing ghosts or not.

Regards,
Frank.


btw, I'm still amazed about timing accuracy when playing with why old Atari
ST or the ALSA sequencer when comparing it to eg. Cubase VST on a Windows
PC. Fairly weird that a 1.6 GHz P4 running win2k is still audibilly worse
that the old hardware (or that same box running linux) ;-)


-- 
+---- --- -- -  -   -    - 
| Frank van de Pol                  -o)    A-L-S-A
| FvdPol@home.nl                    /\\  Sounds good!
| http://www.alsa-project.org      _\_v
| Linux - Why use Windows if we have doors available?

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

CAPs

[Bob Ham]

On Sat, 2002-03-02 at 20:18, Paul Davis wrote:
> >ok, don't forget to put CAPs on the 2.5 wishlist :-)
> 
> they are already implemented and maintained. its just that (almost)
> nobody turns them on. 

How do you do this now?  This http://www.tml.hut.fi/~tilmonen/givertcap/
page tells me to do change the lines

#define CAP_INIT_EFF_SET    ( ~0 )
#define CAP_INIT_INH_SET    ( ~0 )

in linux/capability.h.  The version I have (2.4.17 plus Andrew Morton's
low latency patch and the rtc patch from alsa's sources) has this:

#define CAP_INIT_EFF_SET    to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP))
#define CAP_INIT_INH_SET    to_cap_t(0)

Bob


-- 
Bob Ham: bob@ham.org

My music: http://mp3.com/obelisk_uk
GNU Hurd: http://hurd.gnu.org/

A pessimist expects the weather to get worse.
An optimist hopes it will improve.
A realist adjusts the sails.


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel