3 Mar
2010
3 Mar
'10
5:33 p.m.
Hello, whenever I try to run aconnect to connect some alsa-midi ports, I
get
Connection failed (Operation not permitted)
even as root. I can smoothly make alsa-midi connections from patchage
or qjackctl. What should I check?
Renato
3 Mar
3 Mar
8:46 p.m.
On Wed, Mar 3, 2010 at 10:35 PM, Renato wrote:
Hello, whenever I try to run aconnect to connect some
alsa-midi ports, I
get
Connection failed (Operation not permitted)
even as root. I can smoothly make alsa-midi connections from patchage
or qjackctl. What should I check?
Renato
I get this message when the port names given on
the command line are in the wrong order.
Could this be the reason?
To me, the naming of the options '-i, --input' and
'-o, --output' was misleading.
The output of 'man aconnect' clarifies a little:
input (readable), output (writable).
use
aconnect <readable_port> <writable_port>
which corresponds to the (misleading)
aconnect <input_port> <output_port>
best,
d
4 Mar
4 Mar
12:54 p.m.
On Thu, 4 Mar 2010 01:46:16 +0100
David Adler <david.jo.adler(a)gmail.com> wrote:
On Wed, Mar 3, 2010 at 10:35 PM, Renato wrote:
Yeah, but *worse* in qjackctl they are inverted, i.e.
Readable Clients / Output Ports
and
Writable Clients / Input Ports
what a headache!!
Hello, whenever I try to run aconnect to connect
some alsa-midi
ports, I get
Connection failed (Operation not permitted)
even as root. I can smoothly make alsa-midi connections from
patchage or qjackctl. What should I check?
Renato
I get this message when the port names given on
the command line are in the wrong order.
Could this be the reason?
To me, the naming of the options '-i, --input' and
'-o, --output' was misleading.
The output of 'man aconnect' clarifies a little:
input (readable), output (writable).
use
aconnect <readable_port> <writable_port>
which corresponds to the (misleading)
aconnect <input_port> <output_port>
Ok, it works, sometimes. The problem is that, at least on my system,
all the alsa-midi clients have the same human-readable identifier for
both the input and the output - so I have to use the numbers, but
FreeWheeling in particular has also the same port numbers (132)!! So I
can only access the port "FreeWheeling IN 1", but not the port
"FreeWheeling OUT 1" because they are both 132:0 (and aconnect chooses
it to be "FreeWheeling IN 1")
Is this caused by my system, alsa-midi or FreeWheeling?
Renato
2:23 p.m.
On 3/4/10, Renato wrote:
[...]
Ok, it works, sometimes. The problem is that, at least
on my system,
all the alsa-midi clients have the same human-readable identifier for
both the input and the output - so I have to use the numbers, but
FreeWheeling in particular has also the same port numbers (132)!! So I
can only access the port "FreeWheeling IN 1", but not the port
"FreeWheeling OUT 1" because they are both 132:0 (and aconnect chooses
it to be "FreeWheeling IN 1")
$ aconnect -i
client 130: 'FreeWheeling' [type=user]
1 'FreeWheeling OUT 1'
2 'FreeWheeling OUT 2'
3 'FreeWheeling OUT 3'
4 'FreeWheeling OUT 4'
$ aconnect -o
client 130: 'FreeWheeling' [type=user]
0 'FreeWheeling IN 1'
Don't bother about the IN/OUT stuff and numbers that
are part of the human readable names.
Use the 'real' port numbers (the ones at the beginning
of the lines aconnect -io outputs) instead.
The following works for me:
either using the client name string and port numbers
$ aconnect FreeWheeling:1 FreeWheeling:0
or using the the client number and port numbers
$ aconnect 130:1 130:0
I hope this helps.
best,
d
6 Mar
6 Mar
8:26 a.m.
On Thu, 4 Mar 2010 19:23:45 +0100
David Adler <david.jo.adler(a)gmail.com> wrote:
On 3/4/10, Renato wrote:
[...]
Thanks, it does work now. But I am pretty
sure that yesterday I had something like this (note port numberings):
$ aconnect -i
client 130: 'FreeWheeling' [type=user]
0 'FreeWheeling OUT 1'
1 'FreeWheeling OUT 2'
2 'FreeWheeling OUT 3'
3 'FreeWheeling OUT 4'
$ aconnect -o
client 130: 'FreeWheeling' [type=user]
0 'FreeWheeling IN 1'
and hence my headache. Or maybe I'm just freaking out :)
anyway, I think (hope) I've got how it works now, thanks again.
Renato
Ok, it works, sometimes. The problem is that, at
least on my system,
all the alsa-midi clients have the same human-readable identifier
for both the input and the output - so I have to use the numbers,
but FreeWheeling in particular has also the same port numbers
(132)!! So I can only access the port "FreeWheeling IN 1", but not
the port "FreeWheeling OUT 1" because they are both 132:0 (and
aconnect chooses it to be "FreeWheeling IN 1")
$ aconnect -i
client 130: 'FreeWheeling' [type=user]
1 'FreeWheeling OUT 1'
2 'FreeWheeling OUT 2'
3 'FreeWheeling OUT 3'
4 'FreeWheeling OUT 4'
$ aconnect -o
client 130: 'FreeWheeling' [type=user]
0 'FreeWheeling IN 1'
Don't bother about the IN/OUT stuff and numbers that
are part of the human readable names.
Use the 'real' port numbers (the ones at the beginning
of the lines aconnect -io outputs) instead.
The following works for me:
either using the client name string and port numbers
$ aconnect FreeWheeling:1 FreeWheeling:0
or using the the client number and port numbers
$ aconnect 130:1 130:0
I hope this helps.
best,
d
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
9:21 a.m.
On 3/6/10, Renato wrote:
...
Thanks,
it does work now. But I am pretty
sure that yesterday I had something like this (note port numberings):
$ aconnect -i
client 130: 'FreeWheeling' [type=user]
0 'FreeWheeling OUT 1'
1 'FreeWheeling OUT 2'
2 'FreeWheeling OUT 3'
3 'FreeWheeling OUT 4'
$ aconnect -o
client 130: 'FreeWheeling' [type=user]
0 'FreeWheeling IN 1'
and hence my headache. Or maybe I'm just freaking out :)
anyway, I think (hope) I've got how it works now, thanks again.
Hmm. I hope it'll consistently work from now on. :)
All this gave me some headache as well back
when I started using aconnect, especially the
input/output naming.
If I where asked, I'd say it is a mistake in aconnect,
since Jack audio, Jack MIDI and qjackctl all handle
it the other way round. However, me (humble) just
assumed there is a valid reason from a dev POV
to name I/O towards the 'connecting entity' instead
of towards the 'application entity'.
Changing it now would certainly be a bad idea,
breaking all apps and scripts that rely on aconnect.
best,
d
5378
days inactive
5381
days old
linux-audio-user@lists.linuxaudio.org
5 comments
2 participants
participants (2)
-
David Adler -
Renato