Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Alsa /dev/sequencer stuff
@ 2003-05-20  4:15 Ivica Bukvic
  2003-05-20  4:47 ` [linux-audio-dev] " Paul Davis
  0 siblings, 1 reply; 2+ messages in thread
From: Ivica Bukvic @ 2003-05-20  4:15 UTC (permalink / raw)
  To: alsa-devel; +Cc: alsa-user, linux-audio-dev

Hi all, I was wondering the following:

In my app (RTMix) I will be soon implementing multiple midi-input device
opens, so that the app can be controlled from as many of the midi
controllers simultaneously as possible. One way of devising this was to
design a separate thread for every open device (using raw midi /dev/midi
etc., although I will be re-implementing that to use ALSA devices
directly). However, this might not be the most elegant way of doing
this, so what I was wondering is how does the /dev/sequencer correspond
to this issue? I mean, does it work the same way like addressing the raw
midi ports, are the message formats the same, and most importantly does
one SINGULAR /dev/sequencer encompass all of the midi ports that are
currently available?

I would greatly appreciate any help on this issue, as well as some code
examples. Thank you! Sincerely,

Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico




-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [linux-audio-dev] Alsa /dev/sequencer stuff
  2003-05-20  4:15 Alsa /dev/sequencer stuff Ivica Bukvic
@ 2003-05-20  4:47 ` Paul Davis
  0 siblings, 0 replies; 2+ messages in thread
From: Paul Davis @ 2003-05-20  4:47 UTC (permalink / raw)
  To: linux-audio-dev; +Cc: alsa-devel, alsa-user

>In my app (RTMix) I will be soon implementing multiple midi-input device
>opens, so that the app can be controlled from as many of the midi
>controllers simultaneously as possible. One way of devising this was to
>design a separate thread for every open device (using raw midi /dev/midi
>etc., although I will be re-implementing that to use ALSA devices
>directly). 

although i've been a big advocate of using raw midi ports in the past,
i've pretty swung around on this issue. i think you should use the
ALSA sequencer API instead. that way you can connect applications to
each other, rather than just applications to h/w. same thinking as
JACK in this regard.

>	    However, this might not be the most elegant way of doing
>this, so what I was wondering is how does the /dev/sequencer correspond
>to this issue? I mean, does it work the same way like addressing the raw
>midi ports, are the message formats the same, and most importantly does
>one SINGULAR /dev/sequencer encompass all of the midi ports that are
>currently available?

no, just one port. the OSS sequencer /dev/sequencer is only a
scheduler - it has no routing capabilities at all.

the ALSA sequencer (/dev/snd/seq etc.) is a multiplexer/demultiplexer,
and handles both scheduling and routing, and covers all available h/w
ports and registered s/w clients.

don't leave home without it :)


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-05-20  4:47 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-05-20  4:15 Alsa /dev/sequencer stuff Ivica Bukvic
2003-05-20  4:47 ` [linux-audio-dev] " Paul Davis

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox