12 Aug
2005
12 Aug
'05
7:34 p.m.
Hello folks,
I have two midi controller connected to my UM-2 usb midi interface
And I have a lot of trouble to figure out how to configure ecasound to use
them.
here is the aseqdump outputs :
$ aseqdump -l
Port Client name Port name
0:0 System Timer
0:1 System Announce
72:0 PHASE 26 USB(16/48) PHASE 26 USB(16/48) MIDI 1
80:0 UM-2 UM-2 MIDI 1
80:1 UM-2 UM-2 MIDI 2
if I want to monitor the first device (connected on the in 1 of the UM-2)
this is what I mostly get :
$ aseqdump -p 80:0
Cannot connect from port 80:0 - Resource temporarily unavailable
sometimes it works, but it is absolutely not reproductible
on the other hand, the second device (connected on the in 2 of the UM-2)
is always working :
$ aseqdump -p 80:1
Waiting for data. Press Ctrl+C to end.
Source_ Event_________________ Ch _Data__
80:1 Control change 0 1 69
80:1 Control change 0 1 70
but this information is useless to set up ecasound so I have tested with
gmidimon. The approach is not the same as it uses /dev/midix or
/dev/snd/midiCXDX
the only device I can monitor is /dev/midi2 and /dev/snd/midiC2D0 (same
device) and it gives me this information :
Status Chan Data1 Data2 time
Control(176) 0 1 54 1123881037
I suspect I can use this information in ecasound so when I run ecasound
like that :
# ecasound \
-G:jack,ecasound,notransport \
-Md:rawmidi,/dev/snd/midiC2D0 \
-a:6 -i:jack \
-ea:1000 -km:1,0,1000,176,0 -o:jack
I hear no sound even if I tweek the channel 0 of the suitable device.
If I remove the midi control :
# ecasound \
-G:jack,ecasound,notransport \
-Md:rawmidi,/dev/snd/midiC2D0 \
-a:6 -i:jack \
-ea:1000 -o:jack
I hear the sound
I'm sure that the midi devices are all working because when I connect them
to AMS or om-synth with qjackctl I can control everything with both
devices.
What am I doing wrong ? And why the midi monitoring is so erratic ?
Thanks in advance for your help.
Philippe
12 Aug
12 Aug
8:01 p.m.
# ecasound \
I just see some verbose info from ecasound :
(midi-cc) (midi-cc) Controller number must be a number between 0 and 127.
... Defaulting to controller 0
(midi-cc) (midi-cc) MIDI-channel must be a number between 1 and 16.
Defaulting to
... channel 1.
But this is more confusing to me :(
Regards
Dubphil
-G:jack,ecasound,notransport \
-Md:rawmidi,/dev/snd/midiC2D0 \
-a:6 -i:jack \
-ea:1000 -km:1,0,1000,176,0 -o:jack
I hear no sound even if I tweek the channel 0 of the suitable device. 
8:14 p.m.
On Sat, 2005-08-13 at 00:08 +0000, Dubphil wrote:
Um, /dev/snd/midi* are not supposed to be used directly by applications.
They are intended to be accessed via alsa-lib.
Lee
# ecasound \
I just see some verbose info from ecasound :
-G:jack,ecasound,notransport \
-Md:rawmidi,/dev/snd/midiC2D0 \
-a:6 -i:jack \
-ea:1000 -km:1,0,1000,176,0 -o:jack
I hear no sound even if I tweek the channel 0 of the suitable device. 
16 Aug
16 Aug
7:48 p.m.
Hi,
On Fri, 12 Aug 2005, Lee Revell wrote:
Um, /dev/snd/midi* are not supposed to be used
directly by applications.
They are intended to be accessed via alsa-lib.
has there been (or is under planning) any major changes to this, or known
problems?
Ecasound (and many other apps) has used /dev/snd/midi* with no reported
problems for many years now (at least since ALSA 0.6.x). See for example:
http://lalists.stanford.edu/lad/2001/Apr/0176.html
I understand the general principle of getting rid of all direct
"user-space apps <-> ALSA kernel modules" interactions, but in this case
I'd like to stick with the current code until there's some practical
reason to update (adding support for ALSA sequencer API is another thing).
The good ol' read/write interface is quite sufficient for rawmidi, and you
can cover many use-cases with one piece of code (ALSA, OSS, pipes, etc)...
PS In this case not using alsa-lib is obviously not the problem as
the same thing happens with /dev/midi*...
--
links, my public keys, etc at http://eca.cx/kv
9:53 p.m.
New subject: [linux-audio-user] UM2 USB midi interface is the guilty ?
Hi,
This thread is a legitimate continuation of the thread "midi and
ecasound", that I was the initiator in this list.
after few days having struggled with my midi the setup, and with the help
of Pedro and Kai, I'm comming to believe that there is a bad thing around
the UM2 edirol midi interface and linux when attempting to access
/dev/midi* or /dev/snd/midi* with certain applications such as ecasound or
gmidimon or directly monitoring the devices with aseqdump.
things can be expose in two points :
1 - When I use the "midi in" of my PHASE 26 USB, things are working
properly when the midi data are expected from this device (/dev/midi1).
But the second device connected via the UM2 is not detected by ecasound or
gmidimon (I have tried /dev/midi* and /dev/snd/midi*). Surprisingly,
aseqdump is detecting both devices.
2 - When both device are connected to the UM2 all the apps mentioned above
are not detecting in a reproducible way : sometimes it detect one or the
other, sometime none, sometimes all. It is the behaviour that I have
qualified of "erratic" (the way Pedro misandesrtood as he thought I was
speeking about the midi monitors output).
kick me out if I insist badly.
Regards
Philippe
17 Aug
17 Aug
12:45 p.m.
New subject: [linux-audio-user] UM2 USB midi interface is the guilty ?
Dubphil wrote:
1 - When I use the "midi in" of my PHASE 26
USB, things are working
properly when the midi data are expected from this device (/dev/midi1).
But the second device connected via the UM2 is not detected by ecasound or
gmidimon (I have tried /dev/midi* and /dev/snd/midi*).
Neither ecasound nor gmidimon support MIDI with ALSA correctly.
As a workaround, load the snd-virmidi driver (which make another
/dev/midi* available) and connect its sequencer port to the UM2's
second port.
Surprisingly, aseqdump is detecting both devices.
This one uses the ALSA API correctly.
2 - When both device are connected to the UM2 all the
apps mentioned above
are not detecting in a reproducible way : sometimes it detect one or the
other, sometime none, sometimes all.
When an application tries to open the internal ALSA device node
(/dev/snd/midiCxDx), it will get the first free subdevice, i.e., the
first port that isn't already in use.
HTH
Clemens
18 Aug
18 Aug
10:54 p.m.
New subject: [linux-audio-user] UM2 USB midi interface is the guilty ?
On Wed, 17 Aug 2005, Clemens Ladisch wrote:
Ugh, what do you mean? I'm first to admit that Ecasound does not a)
implement support for the ALSA sequencer API, and b) does not allow to
select subdevice numbers (only card and device). But AFAIK it does
correctly implement the rawmidi interface.
Oh well, current Ecasound CVS already has initial support for ALSA
sequencer support. A big thank you goes to Pedro Lopez-Cabanillas for the
implementation work. IOW, soon there's no need for snd-virmidi anymore for
to route MIDI from/to Ecasound and other apps.
--
links, my public keys, etc at http://eca.cx/kv
1 - When I use
the "midi in" of my PHASE 26 USB, things are working
properly when the midi data are expected from this device (/dev/midi1).
But the second device connected via the UM2 is not detected by ecasound or
gmidimon (I have tried /dev/midi* and /dev/snd/midi*).
Neither ecasound nor gmidimon support MIDI with ALSA correctly.
19 Aug
19 Aug
5:06 a.m.
New subject: [linux-audio-user] UM2 USB midi interface is the guilty ?
Kai Vehmanen wrote:
On Wed, 17 Aug 2005, Clemens Ladisch wrote:
Both programs use the OSS rawmidi API. If they would implement the
ALSA rawmidi interface, they would support ALSA device names like
"hw:X" or "virtual".
Regards,
Clemens
Neither ecasound nor gmidimon support MIDI with
ALSA correctly.
Ugh, what do you mean? I'm first to admit that Ecasound does not a)
implement support for the ALSA sequencer API, and b) does not allow to
select subdevice numbers (only card and device). But AFAIK it does
correctly implement the rawmidi interface.
18 Aug
18 Aug
10:55 p.m.
New subject: [linux-audio-user] UM2 USB midi interface is the guilty ?
On Wed, 2005-08-17 at 16:45 +0200, Clemens Ladisch wrote:
Actually I think there is a bug. Here's my MIDI setup:
Port Client name Port name
0:0 System Timer
0:1 System Announce
62:0 Midi Through Midi Through Port-0
64:0 Audigy MPU-401 (UART) Audigy MPU-401 (UART)
64:32 Audigy MPU-401 (UART) Audigy MPU-401 #2
If have gmidimon running on /dev/midi, aseqdump -p 64:0 fails with
-EBUSY, and dmesg says this:
ALSA sound/core/seq/seq_midi.c:187: midi input open failed!!!
But this should work, since gmidimon opens /dev/midi readonly:
rlrevell@mindpipe:~/cvs/alsa$ sudo lsof /dev/snd/midiC0D* /dev/midi*
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
gmidimon 20112 rlrevell 4r CHR 14,2 3793 /dev/midi
Is concurrent access to MIDI by the ALSA sequencer and OSS apps really
forbidden? The debug printk leads me to believe that this is supposed
to work.
BTW I hate GTK 1.2 so much that I took 10 minutes to port gmidimon to
gtk-2.0. Patch is attached. Apply it *after* running ./configure, as I
couldn't get autoconf work right as it insists on
using /usr/bin/gtk-config which doesn't exist in GTK-2.0.
Lee
Surprisingly,
aseqdump is detecting both devices.
This one uses the ALSA API correctly.
19 Aug
19 Aug
5:13 a.m.
New subject: [linux-audio-user] UM2 USB midi interface is the guilty ?
Lee Revell wrote:
Is concurrent access to MIDI by the ALSA sequencer and
OSS apps really
forbidden?
Concurrent accesses with the rawmidi and sequencer interfaces to the
same device are forbidden (regardless of whether the respective ALSA
or OSS interface is used).
The rawmidi APIs cannot allow sharing because, being 'raw', they don't
interpret the data going through them.
Regards,
Clemens
17 Aug
17 Aug
7:58 a.m.
New subject: [Alsa-devel] Re: [linux-audio-user] midi and ecasound
At Wed, 17 Aug 2005 00:48:44 +0300 (EEST),
Kai Vehmanen wrote:
Hi,
On Fri, 12 Aug 2005, Lee Revell wrote:
So far, no. Simple open/read/write/close the device should work.
Of course, this will lack of the functionality alsa-lib provides,
e.g. like virtual MIDI.
Um, /dev/snd/midi* are not supposed to be used
directly by applications.
They are intended to be accessed via alsa-lib.
has there been (or is under planning) any major changes to this, or known
problems? Ecasound (and many other apps) has used /dev/snd/midi*
with no reported
problems for many years now (at least since ALSA 0.6.x). See for example:
http://lalists.stanford.edu/lad/2001/Apr/0176.html
I understand the general principle of getting rid of all direct
"user-space apps <-> ALSA kernel modules" interactions, but in this case
I'd like to stick with the current code until there's some practical
reason to update (adding support for ALSA sequencer API is another thing).
virmidi is already in alsa-lib, so the byte streaming access via
snd_rawmidi_read()/write() can work as a sequencer port.
Takashi
18 Aug
18 Aug
10:24 p.m.
On Fri, 2005-08-12 at 23:41 +0000, Dubphil wrote:
$ aseqdump -p 80:0
Cannot connect from port 80:0 - Resource temporarily unavailable
sometimes it works, but it is absolutely not reproductible
but this information is useless to set up ecasound so I have tested with
gmidimon. The approach is not the same as it uses /dev/midix or
/dev/snd/midiCXDX
What am I doing wrong ? And why the midi monitoring is so erratic ?
I can repdoduce the problem here, and it's not erratic at all, in fact
the behavior is 100% consistent. If gmidimon or another app already has
the MIDI port open, then aseqdump will get -EBUSY (aka "Resource
temporarily unavailable").
If you had tested these apps one at a time then this would be obvious.
To check who is using the MIDI ports do:
sudo lsof /dev/snd/midiC0D* /dev/midi*
Lee
19 Aug
19 Aug
5:04 a.m.
I can repdoduce the problem here, and it's not
erratic at all, in fact
the behavior is 100% consistent. If gmidimon or another app already has
the MIDI port open, then aseqdump will get -EBUSY (aka "Resource
temporarily unavailable").
If you had tested these apps one at a time then this would be obvious.
I'm absolutely sure that I have succeeded, one time or more, in monitoring
the same midi device with gmidimon and aseqdump simultaneously.
Regards
Philippe
7038
days inactive
7045
days old
linux-audio-user@lists.linuxaudio.org
13 comments
5 participants
participants (5)
-
Clemens Ladisch -
Dubphil -
Kai Vehmanen -
Lee Revell -
Takashi Iwai