26 Sep
2014
26 Sep
'14
11:15 p.m.
On Fri, 26 Sep 2014, Philipp Überbacher wrote:
Alles klar. Well, mostly. I guess that alsa_midi only
makes sense
when alsa is used as a backend, so I don't quite see why it is a server
option instead of a backend option. Anyway, using the -X alsa_midi as
server option works.
That is not true at all, Audio and MIDI are separate and so it is very
possible (even likely) that the backend for audio may not be relevant to MIDI.
MIDI is handled by ALSA, but is not treated as a part of the same audio
interface as the sound that goes with it. So the user who has a FW audio IF
with no MIDI would not be able to use a USB MIDI along with it if this was in
the backend only. Along the same lines is the FW user who does have MIDI in
their FW IF wants to use a lot of the older SW that creates ALSA MIDI ports
they are again stuck if it is only available in the ALSA back end.
The only thing I would like to see different in a2jmidi is the naming. (I am
not sure how jack1 works) a2j opens as one client called a2j that when expanded
has the alsa client name followed by the actual port name. This is hard to read
and use. It is also confusing to new users who ask where the port is just
because a2j has not been expanded. I would guess the best thing (from a user
POV) would be for a2j to open a new jack client for each ALSA client with the
ALSA name. I am not sure what other consequences this would have though :)
--
Len Ovens
www.ovenwerks.net
27 Sep
27 Sep
12:17 a.m.
New subject: Bridging alsa and jack midi
On Fri, 26 Sep 2014 14:15:32 -0700 (PDT)
Len Ovens <len(a)ovenwerks.net> wrote:
The only thing I would like to see different in
a2jmidi is the naming. (I am
not sure how jack1 works) a2j opens as one client called a2j that when expanded
has the alsa client name followed by the actual port name. This is hard to read
and use. It is also confusing to new users who ask where the port is just
because a2j has not been expanded. I would guess the best thing (from a user
POV) would be for a2j to open a new jack client for each ALSA client with the
ALSA name. I am not sure what other consequences this would have though :)
^ this ^
The existing arrangement makes it far from clear what the connections are.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
1:45 a.m.
New subject: Bridging alsa and jack midi
On Fri, Sep 26, 2014 at 6:17 PM, Will Godfrey <willgodfrey(a)musically.me.uk>
wrote:
I would guess the best thing (from a user
the alsa_midi internal client (based on a2jmidi doesn't change this design.
the correct way to deal with this is to use the pretty-name metadata for
the ports, then you can name them however you wish. for example, here is a
qjackctl screenshot after I've a script that calls jack_property to set
pretty-name values for my RME device:
http://community.ardour.org/files/portprettynames.png
(note the complete absence of "system", "capture" and
"playback" in the
names)
of course, not much at all uses the pretty-name metadata yet, but this is
definitely the right way for us all to move forward. the screenshot comes
from a version of qjackctl that isn't even in svn yet :(
POV) would be for a2j to open a new jack client
for each ALSA client
with the
ALSA name. I am not sure what other consequences
this would have though
:)
^ this ^
The existing arrangement makes it far from clear what the connections are.
5:30 a.m.
New subject: [Bulk] Re: Bridging alsa and jack midi
On September 26, 2014 07:45:44 PM Paul Davis wrote:
On Fri, Sep 26, 2014 at 6:17 PM, Will Godfrey
<willgodfrey(a)musically.me.uk>
wrote:
I don't have the latest Jack with metadata.
Can you tell me what kind of data exists now?
If I ask a hardware port for its metadata, will I see useful data
like port names?
Have any conventions been established as to what to call our properties,
port naming formats, tags etc?
Thanks for the valuable updated info in these threads!
Tim.
I would guess the best thing (from a user
the alsa_midi internal client (based on a2jmidi doesn't change this design.
the correct way to deal with this is to use the pretty-name metadata for
the ports, then you can name them however you wish. for example, here is a
qjackctl screenshot after I've a script that calls jack_property to set
pretty-name values for my RME device:
http://community.ardour.org/files/portprettynames.png
(note the complete absence of "system", "capture" and
"playback" in the
names)
of course, not much at all uses the pretty-name metadata yet, but this is
definitely the right way for us all to move forward. the screenshot comes
from a version of qjackctl that isn't even in svn yet :( POV) would be for a2j to open a new jack client
for each ALSA client
with the
ALSA name. I am not sure what other consequences
this would have though
:
:)
^ this ^
The existing arrangement makes it far from clear what the connections are.
4:05 p.m.
New subject: [Bulk] Re: Bridging alsa and jack midi
On Fri, Sep 26, 2014 at 11:30 PM, Tim E. Real <termtech(a)rogers.com> wrote:
m a version of qjackctl that isn't even in svn yet
:(
I don't have the latest Jack with metadata.
Can you tell me what kind of data exists now?
Malformed question. The metadata API exists for users (or systems) to add
arbitrary data. So no data "exists now".
If I ask a hardware port for its metadata, will I see
useful data
like port names?
Depends on whether any was added. I am probably the only person worldwide
to have added pretty-name data, and I'm the only person right now to have a
qjackctl hacked to display them.
Have any conventions been established as to what to
call our properties,
port naming formats, tags etc?
This was all discussed on the jack-devel mailing list last year.
(1) read the output of man jack_property
(2) then add in the fact that well known metadata "keys" were discussed
there, and the idea is for well-known ones to be URIs that resolve to
actual URLs where someone could actually read a description of what the
data is. So for example, we did decide upon http://jackaudio.org/metadata/*
as an "official" namespace, and there was wide support for
http://jackaudio.org/metadata/pretty-name and
http://jackaudio.org/metadata/role (although the 2nd one needs a vocabulary
which is not currently defined).
Unfortunately when we "lost" the drupal jackaudio site due to hacking
earlier this year, we lost the metadata/ part of the website, so the URIs
do not function as URLs right now.
4:19 p.m.
New subject: Bridging alsa and jack midi
Perhaps OT, perhaps not.
[rocketmouse@archlinux ~]$ amidi -l
Dir Device Name
IO hw:0,0 HDSPMx579bcc MIDI 1
IO hw:1,0 TerraTec EWX24/96 MIDI
IO hw:2,0 TerraTec EWX24/96 MIDI
IO hw:3,0,0 nanoKONTROL MIDI 1
IO hw:4,0,0 USB Device 0x170b:0x11 MIDI 1
Currently I need to manually connect the TerraTec cards MIDI ports. Is
there a way to give both cards an unique name? JFTR the TerraTec cards
have different IRQs. It would be comfortable if e.g. aj-snapshot could
distinguish both cards.
29 Sep
29 Sep
4:22 a.m.
New subject: [Bulk] Re: Bridging alsa and jack midi
On September 27, 2014 04:19:10 PM Ralf Mardorf wrote:
Perhaps OT, perhaps not.
[rocketmouse@archlinux ~]$ amidi -l
Dir Device Name
IO hw:0,0 HDSPMx579bcc MIDI 1
IO hw:1,0 TerraTec EWX24/96 MIDI
IO hw:2,0 TerraTec EWX24/96 MIDI
IO hw:3,0,0 nanoKONTROL MIDI 1
IO hw:4,0,0 USB Device 0x170b:0x11 MIDI 1
Currently I need to manually connect the TerraTec cards MIDI ports. Is
there a way to give both cards an unique name? JFTR the TerraTec cards
have different IRQs. It would be comfortable if e.g. aj-snapshot could
distinguish both cards.
Can you, or someone, please tell me what happens in a case like this?
Each day he boots his computer, is it guaranteed
TerraTec A = hw:1 and TerraTec B = hw:2 ?
Thanks.
Tim.
5:25 a.m.
New subject: [Bulk] Re: Bridging alsa and jack midi
On Sun, Sep 28, 2014 at 10:22:36PM -0400, Tim E. Real wrote:
On September 27, 2014 04:19:10 PM Ralf Mardorf wrote:
I'm not sure, but would a udev rule help here? That's the first thing
that springs to mind. It would seem that hw:1 and hw:2 are physically
fixed or are they named during the boot process?
--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the
oppressing." --- Malcolm X
Perhaps OT, perhaps not.
[rocketmouse@archlinux ~]$ amidi -l
Dir Device Name
IO hw:0,0 HDSPMx579bcc MIDI 1
IO hw:1,0 TerraTec EWX24/96 MIDI
IO hw:2,0 TerraTec EWX24/96 MIDI
IO hw:3,0,0 nanoKONTROL MIDI 1
IO hw:4,0,0 USB Device 0x170b:0x11 MIDI 1
Currently I need to manually connect the TerraTec cards MIDI ports. Is
there a way to give both cards an unique name? JFTR the TerraTec cards
have different IRQs. It would be comfortable if e.g. aj-snapshot could
distinguish both cards.
Can you, or someone, please tell me what happens in a case like this?
Each day he boots his computer, is it guaranteed
TerraTec A = hw:1 and TerraTec B = hw:2 ?
6:41 a.m.
New subject: Bridging alsa and jack midi
On September 29, 2014 04:25:04 PM Chris Bannister wrote:
On Sun, Sep 28, 2014 at 10:22:36PM -0400, Tim E. Real
wrote:
Thanks. Found this reeeally simple instruction for udev:
http://www.alsa-project.org/main/index.php/Changing_card_IDs_with_udev
Check it out Ralf.
It looks like you can even set your own device names ! Awesome.
A link to this may also be on the Jack website.
Tim.
On September 27, 2014 04:19:10 PM Ralf Mardorf
wrote:
I'm not sure, but would a udev rule help here? That's the first thing
that springs to mind. It would seem that hw:1 and hw:2 are physically
fixed or are they named during the boot process? Perhaps OT, perhaps not.
[rocketmouse@archlinux ~]$ amidi -l
Dir Device Name
IO hw:0,0 HDSPMx579bcc MIDI 1
IO hw:1,0 TerraTec EWX24/96 MIDI
IO hw:2,0 TerraTec EWX24/96 MIDI
IO hw:3,0,0 nanoKONTROL MIDI 1
IO hw:4,0,0 USB Device 0x170b:0x11 MIDI 1
Currently I need to manually connect the TerraTec cards MIDI ports. Is
there a way to give both cards an unique name? JFTR the TerraTec cards
have different IRQs. It would be comfortable if e.g. aj-snapshot could
distinguish both cards.
Can you, or someone, please tell me what happens in a case like this?
Each day he boots his computer, is it guaranteed
TerraTec A = hw:1 and TerraTec B = hw:2 ? 
9:05 a.m.
New subject: Bridging alsa and jack midi
I think this one is not linked on jackaudio.org, and the other link on jackaudio.org seems
to be broken again...
-- Markus
11:06 a.m.
New subject: Bridging alsa and jack midi
On Mon, 2014-09-29 at 00:40 -0400, Tim E. Real wrote:
Thank you for the Link Tim.
Regards,
Ralf
30 Sep
30 Sep
9:35 p.m.
New subject: Bridging alsa and jack midi
On Mon, 2014-09-29 at 00:40 -0400, Tim E. Real wrote:
Hi :)
I don't understand how to create the udev rule.
The target is, that
hw:0 is the RME card, named by it's original name
hw:1 is Envy card 1 , named by it's original name
hw:2 is Envy card 2 , named by a customized name
any USB device should become
hw:>=3 and get it's original name, even if snd_ice1712 isn't loaded.
Excepted of the customized name, this is provided
by /etc/modprobe.d/alsa-base.conf.
The below udev rule doesn't work [1].
Regards,
Ralf
[1]
[rocketmouse@archlinux ~]$ cat /etc/modprobe.d/alsa-base.conf
# ALSA module ordering
options snd slots=snd_hdspm,snd_ice1712,snd_ice1712
[rocketmouse@archlinux ~]$ cat /lib/udev/rules.d/85-TerraTec_EWX24_96_2.rules
SUBSYSTEM!="sound", GOTO="TerraTec_EWX24_96_2_end"
ACTION!="add", GOTO="TerraTec_EWX24_96_2_end"
DEVPATH=="/devices/pci0000:00/0000:00:14.4/0000:04:06.0/sound/card?",
ATTR{id}="TerraTec EWX24/96_2"
LABEL="TerraTec_EWX24_96_2_end"
[rocketmouse@archlinux ~]$ cat /proc/asound/cards
0 [HDSPMx579bcc ]: HDSPM - RME AIO_579bcc
RME AIO S/N 0x579bcc at 0xfddf0000, irq 18
1 [EWX2496 ]: ICE1712 - TerraTec EWX24/96
TerraTec EWX24/96 at 0xbf00, irq 20
2 [EWX2496_1 ]: ICE1712 - TerraTec EWX24/96
TerraTec EWX24/96 at 0xbb00, irq 21
[rocketmouse@archlinux ~]$ amidi -l
Dir Device Name
IO hw:0,0 HDSPMx579bcc MIDI 1
IO hw:1,0 TerraTec EWX24/96 MIDI
IO hw:2,0 TerraTec EWX24/96 MIDI
[rocketmouse@archlinux ~]$ udevadm monitor --kernel --subsystem-match=sound
monitor will print the received events for:
KERNEL - the kernel uevent
[rocketmouse@archlinux ~]$ sudo modprobe -r snd_ice1712
[rocketmouse@archlinux ~]$ sudo modprobe snd_ice1712
KERNEL[434.220676] remove
/devices/pci0000:00/0000:00:14.4/0000:04:06.0/sound/card2/midi2 (sound)
KERNEL[434.220746] remove
/devices/pci0000:00/0000:00:14.4/0000:04:06.0/sound/card2/dmmidi2 (sound)
KERNEL[434.222669] remove
/devices/pci0000:00/0000:00:14.4/0000:04:06.0/sound/card2/midiC2D0 (sound)
KERNEL[434.222742] remove
/devices/pci0000:00/0000:00:14.4/0000:04:06.0/sound/card2/pcmC2D0p (sound)
KERNEL[434.222772] remove
/devices/pci0000:00/0000:00:14.4/0000:04:06.0/sound/card2/pcmC2D0c (sound)
KERNEL[434.222800] remove
/devices/pci0000:00/0000:00:14.4/0000:04:06.0/sound/card2/controlC2 (sound)
KERNEL[434.222823] remove /devices/pci0000:00/0000:00:14.4/0000:04:06.0/sound/card2
(sound)
KERNEL[434.222851] remove
/devices/pci0000:00/0000:00:14.4/0000:04:05.0/sound/card1/midi1 (sound)
KERNEL[434.222880] remove
/devices/pci0000:00/0000:00:14.4/0000:04:05.0/sound/card1/dmmidi1 (sound)
KERNEL[434.222907] remove
/devices/pci0000:00/0000:00:14.4/0000:04:05.0/sound/card1/midiC1D0 (sound)
KERNEL[434.222934] remove
/devices/pci0000:00/0000:00:14.4/0000:04:05.0/sound/card1/pcmC1D0p (sound)
KERNEL[434.222961] remove
/devices/pci0000:00/0000:00:14.4/0000:04:05.0/sound/card1/pcmC1D0c (sound)
KERNEL[434.222988] remove
/devices/pci0000:00/0000:00:14.4/0000:04:05.0/sound/card1/controlC1 (sound)
KERNEL[434.223010] remove /devices/pci0000:00/0000:00:14.4/0000:04:05.0/sound/card1
(sound)
KERNEL[441.948404] add /devices/pci0000:00/0000:00:14.4/0000:04:05.0/sound/card1
(sound)
KERNEL[441.948627] add
/devices/pci0000:00/0000:00:14.4/0000:04:05.0/sound/card1/controlC1 (sound)
KERNEL[441.948667] add
/devices/pci0000:00/0000:00:14.4/0000:04:05.0/sound/card1/pcmC1D0p (sound)
KERNEL[441.948804] add
/devices/pci0000:00/0000:00:14.4/0000:04:05.0/sound/card1/pcmC1D0c (sound)
KERNEL[441.948839] add
/devices/pci0000:00/0000:00:14.4/0000:04:05.0/sound/card1/midiC1D0 (sound)
KERNEL[441.948973] add
/devices/pci0000:00/0000:00:14.4/0000:04:05.0/sound/card1/midi1 (sound)
KERNEL[441.949009] add
/devices/pci0000:00/0000:00:14.4/0000:04:05.0/sound/card1/dmmidi1 (sound)
KERNEL[441.956442] change /devices/pci0000:00/0000:00:14.4/0000:04:05.0/sound/card1
(sound)
KERNEL[442.002086] add /devices/pci0000:00/0000:00:14.4/0000:04:06.0/sound/card2
(sound)
KERNEL[442.002242] add
/devices/pci0000:00/0000:00:14.4/0000:04:06.0/sound/card2/controlC2 (sound)
KERNEL[442.002264] add
/devices/pci0000:00/0000:00:14.4/0000:04:06.0/sound/card2/pcmC2D0p (sound)
KERNEL[442.002280] add
/devices/pci0000:00/0000:00:14.4/0000:04:06.0/sound/card2/pcmC2D0c (sound)
KERNEL[442.002297] add
/devices/pci0000:00/0000:00:14.4/0000:04:06.0/sound/card2/midiC2D0 (sound)
KERNEL[442.002379] add
/devices/pci0000:00/0000:00:14.4/0000:04:06.0/sound/card2/midi2 (sound)
KERNEL[442.002399] add
/devices/pci0000:00/0000:00:14.4/0000:04:06.0/sound/card2/dmmidi2 (sound)
KERNEL[442.016664] change /devices/pci0000:00/0000:00:14.4/0000:04:06.0/sound/card2
(sound)
10:26 p.m.
New subject: Bridging alsa and jack midi
On Tue, 2014-09-30 at 21:35 +0200, Ralf Mardorf wrote:
DEVPATH=="/devices/pci0000:00/0000:00:14.4/0000:04:06.0/sound/card?",
ATTR{id}="TerraTec EWX24/96_2"
After changing the ATTR{id} it does work for the audio name, but the
MIDI name doesn't change, so the udev rule is useless for my purpose.
[rocketmouse@archlinux ~]$ grep DEVPATH /lib/udev/rules.d/85-TerraTec_EWX24_96_2.rules
DEVPATH=="/devices/pci0000:00/0000:00:14.4/0000:04:06.0/sound/card?",
ATTR{id}="TerraTec_EWX24_96_2"
[rocketmouse@archlinux ~]$ cat /proc/asound/cards
0 [HDSPMx579bcc ]: HDSPM - RME AIO_579bcc
RME AIO S/N 0x579bcc at 0xfddf0000, irq 18
1 [EWX2496 ]: ICE1712 - TerraTec EWX24/96
TerraTec EWX24/96 at 0xbf00, irq 20
2 [TerraTec_EWX24_]: ICE1712 - TerraTec EWX24/96
TerraTec EWX24/96 at 0xbb00, irq 21
[rocketmouse@archlinux ~]$ amidi -l
Dir Device Name
IO hw:0,0 HDSPMx579bcc MIDI 1
IO hw:1,0 TerraTec EWX24/96 MIDI
IO hw:2,0 TerraTec EWX24/96 MIDI
10:45 p.m.
New subject: Bridging alsa and jack midi
On Tue, 30 Sep 2014, Ralf Mardorf wrote:
[rocketmouse@archlinux ~]$ cat /proc/asound/cards
0 [HDSPMx579bcc ]: HDSPM - RME AIO_579bcc
RME AIO S/N 0x579bcc at 0xfddf0000, irq 18
1 [EWX2496 ]: ICE1712 - TerraTec EWX24/96
TerraTec EWX24/96 at 0xbf00, irq 20
2 [EWX2496_1 ]: ICE1712 - TerraTec EWX24/96
TerraTec EWX24/96 at 0xbb00, irq 21
[rocketmouse@archlinux ~]$ amidi -l
Dir Device Name
IO hw:0,0 HDSPMx579bcc MIDI 1
IO hw:1,0 TerraTec EWX24/96 MIDI
IO hw:2,0 TerraTec EWX24/96 MIDI
I don't think you can refer to midi by name in the same way as audio
ports. For example, as above you have hw:2,0 or hw:EWX2496_1, but you can
not use hw:ICE1712 - TerraTec EWX24/96. What I am saying is that EWX2496_1
is a device, not a name or description. MIDI does not have this. However,
qjackctl at least does use the description. So what you want to change is
the description that is shown as "Name" above. The udev rules will be
different than those used to change the device because you are changing a
different part of things. Because of a flood, I don't have access to any
of my MIDI IFs to try things here though.
--
Len Ovens
www.ovenwerks.net
10:57 p.m.
New subject: Bridging alsa and jack midi
On Tue, 2014-09-30 at 13:44 -0700, Len Ovens wrote:
I don't think you can refer to midi by name in the
same way as audio
ports. For example, as above you have hw:2,0 or hw:EWX2496_1, but you can
not use hw:ICE1712 - TerraTec EWX24/96. What I am saying is that EWX2496_1
is a device, not a name or description. MIDI does not have this. However,
qjackctl at least does use the description. So what you want to change is
the description that is shown as "Name" above. The udev rules will be
different than those used to change the device because you are changing a
different part of things. Because of a flood, I don't have access to any
of my MIDI IFs to try things here though.
The problem here is that I manually can connect
20:TerraTec EWX24/96
|- 0:TerraTec EWX 24/96 MIDI
24:TerraTec EWX24/96
|- 0:TerraTec EWX 24/96 MIDI
they always are distinguished by "20" and "24", the sequence of the
cards always is the same, but QjactCtl's Patchbay and aj-snapshot are
unable to restore the connections automatically.
11:25 p.m.
New subject: Bridging alsa and jack midi
On Tue, 30 Sep 2014, Ralf Mardorf wrote:
On Tue, 2014-09-30 at 13:44 -0700, Len Ovens wrote:
Odd, aconnect would use 20:0 and 24:0 as the port names. Aconnect calls
this "sender, receiver = client:port" ... Why would qjc or aj-s use
something different? unless you talk about jack-midi with a port like:
a2j:Midi Through [14] (capture): Midi Through Port-0
This should be 14:0 somewhere in there.
My first response is that this is a bug because there is enough
information there that each port is unique. Unless the 20 and 24 are
different each time... but I would expect it to work sometimes then.
I think if it was me, and I was changing the description with udev, I
would change both of them to shorter names with no spaces like TT_0 and
TT_1
--
Len Ovens
www.ovenwerks.net
I don't think you can refer to midi by name
in the same way as audio
ports. For example, as above you have hw:2,0 or hw:EWX2496_1, but you can
not use hw:ICE1712 - TerraTec EWX24/96. What I am saying is that EWX2496_1
is a device, not a name or description. MIDI does not have this. However,
qjackctl at least does use the description. So what you want to change is
the description that is shown as "Name" above. The udev rules will be
different than those used to change the device because you are changing a
different part of things. Because of a flood, I don't have access to any
of my MIDI IFs to try things here though.
The problem here is that I manually can connect
20:TerraTec EWX24/96
|- 0:TerraTec EWX 24/96 MIDI
24:TerraTec EWX24/96
|- 0:TerraTec EWX 24/96 MIDI
they always are distinguished by "20" and "24", the sequence of the
cards always is the same, but QjactCtl's Patchbay and aj-snapshot are
unable to restore the connections automatically.
11:42 p.m.
New subject: Bridging alsa and jack midi
On Tue, 2014-09-30 at 14:24 -0700, Len Ovens wrote:
Why would qjc or aj-s use something different?
I don't know, but restoring doesn't work.
My first response is that this is a bug because there
is enough
information there that each port is unique.
And a bug that was more than one time reported, that's why I again asked
for a workaround.
I think if it was me, and I was changing the
description with udev, I
would change both of them to shorter names with no spaces like TT_0
and TT_1
Backward compatibility, at least restoring when just the first card was
used should work, so keeping the original name makes sense. Anyway, for
the MIDI names the udev rule doesn't work.
1 Oct
1 Oct
9:19 a.m.
New subject: Bridging alsa and jack midi
On Tue, Sep 30, 2014 at 11:42:33PM +0200, Ralf Mardorf wrote:
On Tue, 2014-09-30 at 14:24 -0700, Len Ovens wrote:
I have a workaround (no tested).
'TerraTec EWX24/96' is the shortname of your soundcard and it is used
to set the rawmidi name (`snd_mpu401_uart_new' called in ice1712.c,
the source of the kernel module). So, if you change the shortname, you
also change the rawmidi name.
The info about the irq number is enough to get two different rawmidi
names. The new shortname after the follow patch is
'TerraTec EWX24/96, irq %d'
consequently the longname becomes
'TerraTec EWX24/96, irq %d at 0x%lx'
The new rawmidi name is
'TerraTec EWX24/96, irq %d MIDI'
You can change the format of the string by editing the patch
(the maxsize for shortname is 31 characters). You can also edit the
basename for your card in linux/sound/pci/ice1712/ews.c:1035.
diff -ur linux~/sound/pci/ice1712/ice1712.c linux/sound/pci/ice1712/ice1712.c
--- linux~/sound/pci/ice1712/ice1712.c 2014-10-01 08:02:27.208159287 +0200
+++ linux/sound/pci/ice1712/ice1712.c 2014-10-01 08:03:49.868120111 +0200
@@ -2688,7 +2688,8 @@
for (c = *tbl; c->subvendor; c++) {
if (c->subvendor == ice->eeprom.subvendor) {
ice->card_info = c;
- strcpy(card->shortname, c->name);
+ sprintf(card->shortname, "%s, irq %i",
c->name,
+ ice->irq);
if (c->driver) /* specific driver? */
strcpy(card->driver, c->driver);
if (c->chip_init) {
@@ -2786,8 +2787,7 @@
snd_ice1712_set_input_clock_source(ice, 0);
- sprintf(card->longname, "%s at 0x%lx, irq %i",
- card->shortname, ice->port, ice->irq);
+ sprintf(card->longname, "%s at 0x%lx", card->shortname, ice->port);
err = snd_card_register(card);
if (err < 0) {
Why would qjc or aj-s use something different?
I don't know, but restoring doesn't work.
My first response is that this is a bug because
there is enough
information there that each port is unique.
And a bug that was more than one time reported, that's why I again asked
for a workaround.
I think if it was me, and I was changing the
description with udev, I
would change both of them to shorter names with no spaces like TT_0
and TT_1
Backward compatibility, at least restoring when just the first card was
used should work, so keeping the original name makes sense. Anyway, for
the MIDI names the udev rule doesn't work.
10:01 a.m.
New subject: Bridging alsa and jack midi
On Wed, 2014-10-01 at 09:19 +0200, Tito Latini wrote:
diff -ur linux~/sound/pci/ice1712/ice1712.c
linux/sound/pci/ice1712/ice1712.c
Thank you :)
unfortunately I can't find the source of the driver.
[rocketmouse@archlinux ~]$ ls -hAl /usr/src/linux-3.10.47-rt50-1-rt-lts/sound/pci/
total 32K
drwxr-xr-x 2 root root 4.0K Jul 17 23:39 hda
-rw-r--r-- 1 root root 25K Jul 17 23:39 Kconfig
[rocketmouse@archlinux ~]$ ls -hAl
/lib/modules/3.10.47-rt50-1-rt-lts/kernel/sound/pci/ice1712/
total 100K
-rw-r--r-- 1 root root 30K Jul 17 23:38 snd-ice1712.ko.gz
-rw-r--r-- 1 root root 59K Jul 17 23:38 snd-ice1724.ko.gz
-rw-r--r-- 1 root root 2.4K Jul 17 23:38 snd-ice17xx-ak4xxx.ko.gz
So I can't just rebuild the module? Do I have to build the complete
kernel?
Regards,
Ralf
3:14 p.m.
New subject: Bridging alsa and jack midi
On Wed, Oct 01, 2014 at 10:00:57AM +0200, Ralf Mardorf wrote:
On Wed, 2014-10-01 at 09:19 +0200, Tito Latini wrote:
The kernel source code is incomplete. If you have a Makefile in
ls /lib/modules/`uname -r`/build
you can follow these steps (*):
1) download the full source of your kernel
2) cd linux-...
patch -p1 < ice1712_shortname.patch
3) cd sound/pci/ice1712/
4) replace the content of the Makefile (after copy-and-paste, remember
one tab char and not spaces before "make -C") with
snd-ice1712-objs := ice1712.o delta.o hoontech.o ews.o
obj-m += snd-ice1712.o
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
5) compile the module
make
ls snd-ice1712.ko
(*) More info in linux/Documentation/kbuild/modules.txt, in particular:
NOTE: "modules_prepare" will not build Module.symvers even if
CONFIG_MODVERSIONS is set; therefore, a full kernel build needs to be
executed to make module versioning work.
diff -ur linux~/sound/pci/ice1712/ice1712.c
linux/sound/pci/ice1712/ice1712.c
Thank you :)
unfortunately I can't find the source of the driver.
[rocketmouse@archlinux ~]$ ls -hAl /usr/src/linux-3.10.47-rt50-1-rt-lts/sound/pci/
total 32K
drwxr-xr-x 2 root root 4.0K Jul 17 23:39 hda
-rw-r--r-- 1 root root 25K Jul 17 23:39 Kconfig
[rocketmouse@archlinux ~]$ ls -hAl
/lib/modules/3.10.47-rt50-1-rt-lts/kernel/sound/pci/ice1712/
total 100K
-rw-r--r-- 1 root root 30K Jul 17 23:38 snd-ice1712.ko.gz
-rw-r--r-- 1 root root 59K Jul 17 23:38 snd-ice1724.ko.gz
-rw-r--r-- 1 root root 2.4K Jul 17 23:38 snd-ice17xx-ak4xxx.ko.gz
So I can't just rebuild the module? Do I have to build the complete
kernel?
29 Sep
29 Sep
11:10 a.m.
New subject: Bridging alsa and jack midi
On Mon, 2014-09-29 at 16:25 +1300, Chris Bannister wrote:
It would seem that hw:1 and hw:2 are physically
fixed or are they named during the boot process?
Fortunately they are fixed, or the sequence randomly always was the same
when I checked it.
1:56 p.m.
New subject: Bridging alsa and jack midi
On Mon, 29 Sep 2014 11:10:34 +0200
Ralf Mardorf <ralf.mardorf(a)rocketmail.com> wrote:
On Mon, 2014-09-29 at 16:25 +1300, Chris Bannister
wrote:
As far they are no longer fixed since a couple of years. Not sure
though, I would make certain and create udev rules using unique
identifiers.
It would seem that hw:1 and hw:2 are physically
fixed or are they named during the boot process?
Fortunately they are fixed, or the sequence randomly always was the
same when I checked it. 
27 Sep
27 Sep
7:25 p.m.
New subject: Bridging alsa and jack midi
On 09/27/2014 12:45 AM, Paul Davis wrote:
the correct way to deal with this is to use the pretty-name metadata for
the ports, then you can name them however you wish. for example, here is
a qjackctl screenshot after I've a script that calls jack_property to
set pretty-name values for my RME device:
http://community.ardour.org/files/portprettynames.png
(note the complete absence of "system", "capture" and
"playback" in the
names)
of course, not much at all uses the pretty-name metadata yet, but this
is definitely the right way for us all to move forward. the screenshot
comes from a version of qjackctl that isn't even in svn yet :(
qjackctl has an client/port aliases scheme and renaming of its own, on a
preset basis, for almost a decade now.
that said, it would be awesome to merge your hack Paul.
i can vaguely remember something about that from you a year ago or so,
but i also remember you also recalled and scrapped it the next day, so
nothing was patched yet :(
is there any plans for (re)posting the "qjackctl pretty-name metadata
patch" or whatever it's called?
i'd be glad to review and possibly integrate with the old client/port
aliases and renaming option.
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
10:16 p.m.
New subject: Bridging alsa and jack midi
On Sat, Sep 27, 2014 at 1:25 PM, Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
that said, it would be awesome to merge your hack
Paul.
i can vaguely remember something about that from you a year ago or so, but
i also remember you also recalled and scrapped it the next day, so nothing
was patched yet :(
i didn't pass it on because i started to get some crashes with qjc that i
hadn' t had before.
is there any plans for (re)posting the "qjackctl pretty-name metadata
patch" or whatever it's called?
it is a pretty deep change (i threw out all support for JACK port aliases).
but i will post it at some point because i don't have time to figure out
the nature of the (very occasional) crash (yet)
jack port aliases *should* be deprecated. it is a mechanism that should
never have seen the light of day.
10:46 p.m.
New subject: Bridging alsa and jack midi
On 09/27/2014 09:16 PM, Paul Davis wrote:
On Sat, Sep 27, 2014 at 1:25 PM, Rui Nuno Capela <rncbc(a)rncbc.org
<mailto:rncbc@rncbc.org>> wrote:
that said, it would be awesome to merge your hack Paul.
i can vaguely remember something about that from you a year ago or
so, but i also remember you also recalled and scrapped it the next
day, so nothing was patched yet :(
i didn't pass it on because i started to get some crashes with qjc that
i hadn' t had before.
is there any plans for (re)posting the "qjackctl pretty-name
metadata patch" or whatever it's called?
it is a pretty deep change (i threw out all support for JACK port
aliases). but i will post it at some point because i don't have time to
figure out the nature of the (very occasional) crash (yet)
jack port aliases *should* be deprecated. it is a mechanism that should
never have seen the light of day.
there's the "jack port aliases" and there's the "qjackctl
client/port
aliases". they are two different things and orthogonal. the later is
what i believe may be integrated with the "jack pretty-name metatada"
interface.
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
10:59 p.m.
New subject: Bridging alsa and jack midi
On Sat, Sep 27, 2014 at 4:46 PM, Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
On 09/27/2014 09:16 PM, Paul Davis wrote:
http://community.ardour.org/files/qjc-pp.png
On Sat, Sep 27, 2014 at 1:25 PM, Rui Nuno Capela <rncbc(a)rncbc.org
<mailto:rncbc@rncbc.org>> wrote:
that said, it would be awesome to merge your hack Paul.
i can vaguely remember something about that from you a year ago or
so, but i also remember you also recalled and scrapped it the next
day, so nothing was patched yet :(
i didn't pass it on because i started to get some crashes with qjc that
i hadn' t had before.
is there any plans for (re)posting the "qjackctl pretty-name
metadata patch" or whatever it's called?
it is a pretty deep change (i threw out all support for JACK port
aliases). but i will post it at some point because i don't have time to
figure out the nature of the (very occasional) crash (yet)
jack port aliases *should* be deprecated. it is a mechanism that should
never have seen the light of day.
there's the "jack port aliases" and there's the "qjackctl
client/port
aliases". they are two different things and orthogonal. the later is what i
believe may be integrated with the "jack pretty-name metatada" interface.
28 Sep
28 Sep
1:59 a.m.
New subject: [Bulk] Re: Bridging alsa and jack midi
On September 27, 2014 04:59:42 PM Paul Davis wrote:
Yes! Do it!
6:08 p.m.
New subject: Bridging alsa and jack midi
On 09/27/2014 09:59 PM, Paul Davis wrote:
On Sat, Sep 27, 2014 at 4:46 PM, Rui Nuno Capela <rncbc(a)rncbc.org
<mailto:rncbc@rncbc.org>> wrote:
On 09/27/2014 09:16 PM, Paul Davis wrote:
On Sat, Sep 27, 2014 at 1:25 PM, Rui Nuno Capela
<rncbc(a)rncbc.org <mailto:rncbc@rncbc.org>
<mailto:rncbc@rncbc.org <mailto:rncbc@rncbc.org>>> wrote:
that said, it would be awesome to merge your hack Paul.
i can vaguely remember something about that from you a year
ago or
so, but i also remember you also recalled and scrapped it
the next
day, so nothing was patched yet :(
i didn't pass it on because i started to get some crashes with
qjc that
i hadn' t had before.
is there any plans for (re)posting the "qjackctl pretty-name
metadata patch" or whatever it's called?
it is a pretty deep change (i threw out all support for JACK port
aliases). but i will post it at some point because i don't have
time to figure out the nature of the (very occasional) crash (yet)
jack port aliases *should* be deprecated. it is a mechanism that
should never have seen the light of day.
there's the "jack port aliases" and there's the "qjackctl
client/port aliases". they are two different things and orthogonal.
the later is what i believe may be integrated with the "jack
pretty-name metatada" interface.
http://community.ardour.org/files/qjc-pp.png
ok. so i guess that means we are in tune :)-- drop the old deprecated
"jack port aliases" and adopt and/or adapt the even older "qjackctl
client/port aliases" as to latest "jack pretty-name metadata" interface.
may i/we look at some source code or patch anytime soon ? ;)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
3502
days inactive
3507
days old
linux-audio-user@lists.linuxaudio.org
27 comments
10 participants
participants (10)
-
Chris Bannister -
Len Ovens -
Markus Seeber -
Paul Davis -
Philipp Überbacher -
Ralf Mardorf -
Rui Nuno Capela -
Tim E. Real -
Tito Latini -
Will Godfrey