12 Sep
2007
12 Sep
'07
9 a.m.
hi
in an alsa-seq enabled application i would like to automatically connect
to all available "hardware" midi devices on startup.
however i have found no way to find out, which clients are real midi
devices and which are not.
my first attempt just connects to everything except itself and client-0
("system"), which is rather sub-optimal, as it includes the "midi
through" which tends to lead to wild midi feedbacks (our application
_can_ do midi through too...)
unfortunately i haven't found any documentation.
what i have found is:
- http://www.alsa-project.org/alsa-doc/alsa-lib/group___sequencer.html
(saying that "user clients" have ids 128..191; this is fine, to filter
out other applications, but not enough for me)
- http://alsa.opensrc.org/index.php/Aconnect (which gives a "simplistic
guideline for client numbers": 0..63=internal; 64..127==devicedrivers;
128..?==userapps; this would be perfect, but unfortunately this just
seems to be outdated information; e.g. i have 4 hw-midi devices
connected and they are assigned the numbers 16,20,24,28)
any hints?
or iam i totally out of my mind for trying to (optionally) a(uto)connect
on the application-side?
mfg.asdr
IOhannes
PS: i guess this question might be more appropriate on one of the alsa
lists, but since i am subscribed to lad and not to one of these, ....
PPS: sorry if this comes through 2 times; i originally sent this email
from an non-subscribed account...
12 Sep
12 Sep
10:19 a.m.
On Wednesday 12 September 2007 14:00, IOhannes M zmoelnig wrote:
however i have found no way to find out, which clients
are real midi
devices and which are not.
I've wondered this many times before, and have come to the conclusion that
there is no way that's any better than a "rule of thumb". I'd like to
know
if anyone out there thinks otherwise.
Prior to ALSA driver version 1.0.11rc1, system clients were numbered 0 to 63,
hardware clients 64 to 127 and software clients 128 onwards. ALSA 1.0.11rc1
changed this (for a good reason, but apparently without documenting it) so
that system clients were 0 to 15, hardware clients 16 to 127 and software
clients 128 onwards.
This was particularly problematic at the time, because it is the ALSA driver
that generates the client numbers, and there is nothing enforcing the rule
that the ALSA driver and library should be the same version. A user
application therefore couldn't rely on the alsalib version number when trying
to decide whether a client numbered 16 to 63 was system or hardware. (It's
always recommended that the ALSA driver and library version numbers match up,
but I don't think that a third-party application can necessarily assume that
this will be the case on every system.)
I assume it must be intended that ALSA applications treat these numbers as
meaningless opaque identifiers; otherwise they wouldn't have been changed so
lightly. But I don't see any alternative if you want to do autoconnection
(even under user control). Many people here will argue that autoconnection
is a bad idea in itself. I am not interested in having that argument again,
except perhaps in the pub with a few pints stacked up and ready.
Also, note that you can't rely on the SND_SEQ_PORT_TYPE flags to tell you
anything useful either.
Chris
11:08 a.m.
On Wednesday 12 September 2007 14:00, IOhannes M
zmoelnig wrote:
> however i have found no way to find out, which clients are real midi
> devices and which are not.
If your alsa-lib is new enough, you can try to check for
SND_SEQ_PORT_TYPE_HARDWARE.
Chris Cannam wrote:
A user application therefore couldn't rely on the
alsalib version number
when trying to decide whether a client numbered 16 to 63 was system or
hardware.
And there's userspace drivers for Bluetooth and Firewire.
I assume it must be intended that ALSA applications
treat these numbers as
meaningless opaque identifiers; otherwise they wouldn't have been changed so
lightly.
Indeed.
But I don't see any alternative if you want to do
autoconnection
(even under user control). Many people here will argue that autoconnection
is a bad idea in itself.
On my old SB-compatible card, opening the MIDI port will disable the
PCM device (or fail if the PCM is opened).
And what would the purpose be of automatically connecting to all
those ports, when there's more than one?
$ aplaymidi -l
Port Client name Port name
14:0 Midi Through Midi Through Port-0
14:1 Midi Through Midi Through Port-1
20:0 MPU-401 UART MIDI MPU-401 UART MIDI
24:0 Yamaha DS-1E (YMF754) MIDI Yamaha DS-1E (YMF754) MIDI
25:0 OPL3 FM synth OPL3 FM Port
32:0 SC-8820 SC-8820 Part A
32:1 SC-8820 SC-8820 Part B
32:2 SC-8820 SC-8820 MIDI
40:0 Virtual Raw MIDI 6-0 VirMIDI 6-0
41:0 Virtual Raw MIDI 6-1 VirMIDI 6-1
42:0 Virtual Raw MIDI 6-2 VirMIDI 6-2
43:0 Virtual Raw MIDI 6-3 VirMIDI 6-3
48:0 UM-2 UM-2 MIDI 1
48:1 UM-2 UM-2 MIDI 2
56:0 EMU10K1 MPU-401 (UART) EMU10K1 MPU-401 (UART)
57:0 Emu10k1 WaveTable Emu10k1 Port 0
57:1 Emu10k1 WaveTable Emu10k1 Port 1
57:2 Emu10k1 WaveTable Emu10k1 Port 2
57:3 Emu10k1 WaveTable Emu10k1 Port 3
60:0 Serial MIDI Serial MIDI 1
64:0 C-Media CMI8738-MC8 C-Media CMI8738-MC8 MIDI
(yes, I'm bragging :-)
Also, note that you can't rely on the
SND_SEQ_PORT_TYPE flags to tell you
anything useful either.
They're strictly optional, but at least all the drivers set them.
(Both the in-the-kernel-but-virtual drivers, snd-virmidi and snd-seq-dummy,
set SND_SEQ_PORT_TYPE_SOFTWARE instead of _HARDWARE.)
Regards,
Clemens
11:20 a.m.
On Wednesday 12 September 2007 16:08, Clemens Ladisch wrote:
Ah! I hadn't noticed that. It is in the header on this machine (ALSA library
1.0.14). When did it appear?
Chris
On Wednesday
12 September 2007 14:00, IOhannes M zmoelnig wrote:
> however i have found no way to find out, which clients are real midi
> devices and which are not.
If your alsa-lib is new enough, you can try to check for
SND_SEQ_PORT_TYPE_HARDWARE. 
12 Sep
12 Sep
2:54 p.m.
On Wed, 2007-09-12 at 17:08 +0200, Clemens Ladisch wrote:
$ aplaymidi -l
Port Client name Port name
14:0 Midi Through Midi Through Port-0
14:1 Midi Through Midi Through Port-1
-<snip>-
Ome thing I have many times wondered, what is the semantics of those
Midi Through ports? In hardware those would be replications of Midi
Input to some other hardware device, and on output you would never see
them ... Is it supposed to be some kind of Midi Merge or what is it?
13 Sep
13 Sep
8:07 a.m.
Jens M Andreasen wrote:
The semantics if a Midi Through port is simple: anything received by the
port is also sent from the port.
If you make several connections from other ports to a through port, the
data is indeed merged.
If you make several connections from a through port to other ports, the
received data is copied to all ports.
These ports aren't used that much in practice because any ALSA sequencer
port that allows connections allows any number of them.
Regards,
Clemens
$ aplaymidi
-l
Port Client name Port name
14:0 Midi Through Midi Through Port-0
14:1 Midi Through Midi Through Port-1
Ome thing I have many times wondered, what is the semantics of those
Midi Through ports? In hardware those would be replications of Midi
Input to some other hardware device, and on output you would never see
them ... Is it supposed to be some kind of Midi Merge or what is it?
6321
days inactive
6322
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
4 participants
participants (4)
-
Chris Cannam -
Clemens Ladisch -
IOhannes M zmoelnig -
Jens M Andreasen