14 Dec
2010
14 Dec
'10
10:57 a.m.
...or to load devices into specific alsa-slots (hw:0, hw:1...)
Does someone have a nice method to do one of these?
Since I knew of no other method, I tried loading the cards into specific
slots, according to this method found at planetccrma's home page:
alias snd-card-0 snd-CARD_0
options snd-card-0 index=0
options snd-CARD_0 index=0
alias snd-card-1 snd-CARD_1
options snd-card-1 index=1
options snd-CARD_1 index=1
...
alias snd-card-N snd-CARD_N
options snd-card-N index=N
options snd-CARD_N index=N
I have two m-audio delta devices and I never found a good way to
configure alsa so they would load in a specific order. There was the
problem of naming, since both cards have the same name.
I think I would prefer the pulseaudio method, which remembers the card
itself, not the alsa slot (I don't know anything about that, to be honest).
Other things to consider is:
More than 5 devices will be used, some of them usb midi (usb midi
devices also appear in alsa sound slots).
Two m-audio delta cards for audio input (8 + 4 inputs), and at least the
sound cards need to always load in the same order with jack.
Is it possible to get jack/alsa to remember the sound cards after reboot?
--
ailo
14 Dec
14 Dec
12:11 p.m.
On 12/14/2010 10:57 AM, ailo wrote:
...or to load devices into specific alsa-slots (hw:0,
hw:1...)
Does someone have a nice method to do one of these?
Since I knew of no other method, I tried loading the cards into specific
slots, according to this method found at planetccrma's home page:
alias snd-card-0 snd-CARD_0
options snd-card-0 index=0
options snd-CARD_0 index=0
alias snd-card-1 snd-CARD_1
options snd-card-1 index=1
options snd-CARD_1 index=1
...
alias snd-card-N snd-CARD_N
options snd-card-N index=N
options snd-CARD_N index=N
I have two m-audio delta devices and I never found a good way to
configure alsa so they would load in a specific order. There was the
problem of naming, since both cards have the same name.
I think I would prefer the pulseaudio method, which remembers the card
itself, not the alsa slot (I don't know anything about that, to be honest).
Other things to consider is:
More than 5 devices will be used, some of them usb midi (usb midi
devices also appear in alsa sound slots).
Two m-audio delta cards for audio input (8 + 4 inputs), and at least the
sound cards need to always load in the same order with jack.
Is it possible to get jack/alsa to remember the sound cards after reboot?
This has been discussed a couple of times on this list, search the
list-archive for details.
The idea is to refer to audio interfaces by name or device-id rather
than numeric ID.
cat /proc/asound/cards
gives you a list. - use the names between the square brackets
e.g.
jackd -R -P70 -t1000 -dalsa -d 'hw:Intel' -r48000 -p1024 -n2
HTH,
robin
12:15 p.m.
On 12/14/2010 12:11 PM, Robin Gareus wrote:
On 12/14/2010 10:57 AM, ailo wrote:
OOPS: I've just realized that two of your devices are identical.
I don't think the name will help in that case. IIRC there's away to use
a UID or BUS like /dev/snd/by-path/.. but I don't remember the details
just now.
best,
robin
...or to load devices into specific alsa-slots
(hw:0, hw:1...)
Does someone have a nice method to do one of these?
Since I knew of no other method, I tried loading the cards into specific
slots, according to this method found at planetccrma's home page:
alias snd-card-0 snd-CARD_0
options snd-card-0 index=0
options snd-CARD_0 index=0
alias snd-card-1 snd-CARD_1
options snd-card-1 index=1
options snd-CARD_1 index=1
...
alias snd-card-N snd-CARD_N
options snd-card-N index=N
options snd-CARD_N index=N
I have two m-audio delta devices and I never found a good way to
configure alsa so they would load in a specific order. There was the
problem of naming, since both cards have the same name.
I think I would prefer the pulseaudio method, which remembers the card
itself, not the alsa slot (I don't know anything about that, to be honest).
Other things to consider is:
More than 5 devices will be used, some of them usb midi (usb midi
devices also appear in alsa sound slots).
Two m-audio delta cards for audio input (8 + 4 inputs), and at least the
sound cards need to always load in the same order with jack.
Is it possible to get jack/alsa to remember the sound cards after reboot?
This has been discussed a couple of times on this list, search the
list-archive for details.
The idea is to refer to audio interfaces by name or device-id rather
than numeric ID.
cat /proc/asound/cards
gives you a list. - use the names between the square brackets
e.g.
jackd -R -P70 -t1000 -dalsa -d 'hw:Intel' -r48000 -p1024 -n2
HTH,
robin 
12:28 p.m.
Robin,
OOPS: I've just realized that two of your devices
are identical.
I don't think the name will help in that case. IIRC there's away to use
a UID or BUS like /dev/snd/by-path/.. but I don't remember the details
just now.
If the ICE-cards have serial numbers, it could be an effective solution
to add it to the card's name. RME cards are quite commonly used in
bundles, so I added this feature:
# cat /proc/asound/cards
0 [default ]: HDSPM - RME MADI_c61f8e
RME MADI S/N 0xc61f8e at 0xfdef0000, irq 16
It also allows to identify cards in the LAN. In infrastructure setups
the host no longer is the top level namespace.
Flo
--
Machines can do the work, so people have time to think.
public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net
5:44 p.m.
On 12/14/2010 12:28 PM, Florian Faber wrote:
Robin,
> OOPS: I've just realized that two of your devices are identical.
> I don't think the name will help in that case. IIRC there's away to use
> a UID or BUS like /dev/snd/by-path/.. but I don't remember the details
> just now.
Actually, the cards do have different names, now when I think of it.
It's the chip that is the same.
Still, it feels better to use an unique id. Perhaps /dev/snd/by-path is
a good way to do that. If I understand correctly, this is the path to
the actual pci-slot (which is not likely to change between boots).
If the ICE-cards have serial numbers, it could be an effective solution
to add it to the card's name. RME cards are quite commonly used in
bundles, so I added this feature:
# cat /proc/asound/cards
0 [default ]: HDSPM - RME MADI_c61f8e
RME MADI S/N 0xc61f8e at 0xfdef0000, irq 16
It also allows to identify cards in the LAN. In infrastructure setups
the host no longer is the top level namespace.
Flo
With my limited understanding the only thing I can discover here is:
0 [default ]
is usually :
0 [nameofcard ]
So, I'm afraid I can't read further into how to use the serial number to
identify the card.
Starting jack by using
jackd -d alsa -d 'hw:nameofcard'
may solve my problem.
I'm looking on how to sync the two cards, delta-1010 and delta-66.
AFAIK, no matter the method, it seems one must sync them using spdif
(don't think this is needed on Windows, but perhaps that has to do with
proprietary drivers?).
There is this method:
http://www.jrigg.co.uk/linuxaudio/ice1712multi.html
and one that I haven't tried yet is using alsa_in and alsa_out as
mentioned here:
http://trac.jackaudio.org/wiki/WalkThrough/User/AlsaInOut
If someone has some experience in using multiple cards, I won't mind a
pointer or two.
--
ailo
5:55 p.m.
On Tue, 14 Dec 2010 17:44:36 +0100
ailo <ailo.at(a)gmail.com> wrote:
I'm looking on how to sync the two cards,
delta-1010 and delta-66.
AFAIK, no matter the method, it seems one must sync them using spdif
(don't think this is needed on Windows, but perhaps that has to do with
proprietary drivers?).
If you want to use these two cards together, then syncing with SPDIF is
pretty much required. The alsa_in/out programs add latency, and as the
website said, you should not record using those programs.
I can guarantee that you'd need to sync them with SPDIF under Windows as
well as Linux, or you'll get clock drift between the cards.
There is this method:
http://www.jrigg.co.uk/linuxaudio/ice1712multi.html
If someone has some experience in using multiple cards, I won't mind a
pointer or two.
I've put up how I got it to work here: http://delta.brainiac.com/deltasync.html
I run 2 Delta 1010s synced up and it works well for me.
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
6:23 p.m.
On Tue, Dec 14, 2010 at 11:55:03AM -0500, Joe Hartley wrote:
--
torben Hohn
On Tue, 14 Dec 2010 17:44:36 +0100
ailo <ailo.at(a)gmail.com> wrote:
alsa_in/out programs can yield lower latency than jackd itself.
and i doubt, that anyone can hear the artifacts.
the website is for the version that came with jack 0.116.x
but the new algorithm is a lot better.
I'm looking on how to sync the two cards,
delta-1010 and delta-66.
AFAIK, no matter the method, it seems one must sync them using spdif
(don't think this is needed on Windows, but perhaps that has to do with
proprietary drivers?).
If you want to use these two cards together, then syncing with SPDIF is
pretty much required. The alsa_in/out programs add latency, and as the
website said, you should not record using those programs.
I can guarantee that you'd need to sync them with SPDIF under Windows as
well as Linux, or you'll get clock drift between the cards.
alsa_out tools are build to compensate the clock drift.
There is this method:
http://www.jrigg.co.uk/linuxaudio/ice1712multi.html
If someone has some experience in using multiple cards, I won't mind a
pointer or two.
I've put up how I got it to work here: http://delta.brainiac.com/deltasync.html
I run 2 Delta 1010s synced up and it works well for me.
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
6:45 p.m.
On 12/14/10 18:23, torbenh wrote:
If you use SRC you pretty much violate AES specs as you lose bit
transparency. SRC is not a solution, it is a last resort.
In a well controlled situation like this, sound cards should be synced
in hardware. All professional sound cards support this (some can even
sync their buffers). It really isn't rocket science.
Flo
--
Machines can do the work, so people have time to think.
public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net
I can
guarantee that you'd need to sync them with SPDIF under Windows as
well as Linux, or you'll get clock drift between the cards.
alsa_out tools are
build to compensate the clock drift.
7:47 p.m.
On 12/14/2010 06:45 PM, Florian Faber wrote:
--
ailo
On 12/14/10 18:23, torbenh wrote:
>> I can guarantee that you'd need to sync them with SPDIF under Windows as
>> well as Linux, or you'll get clock drift between the cards.
True. I just looked through the manual for the delta 1010, and it
clearly says one needs to connect the cards with spdif to sync them when
using more than one delta card.
Next time I'll read the manual first...
alsa_out tools
are build to compensate the clock drift.
If you use SRC you pretty much violate AES specs as you lose bit
transparency. SRC is not a solution, it is a last resort.
In a well controlled situation like this, sound cards should be synced
in hardware. All professional sound cards support this (some can even
sync their buffers). It really isn't rocket science.
Flo
6:55 p.m.
On Tue, 14 Dec 2010 18:23:47 +0100
torbenh <torbenh(a)gmx.de> wrote:
On Tue, Dec 14, 2010 at 11:55:03AM -0500, Joe Hartley
wrote:
Fairly impressive performance, then! I'm not likely to revamp my setup
(Don't fix what isn't broken!) but do you feel this is fast and stable
enough for studio use?
My skeptical side feels that a software solution to sync the cards will
always be inferior to using hardware-based master/slave clocking, but it's
entirely possible that systems are more than fast enough to handle this easily.
I'm not sure I'd want to rely on it for recording 16 channels of 24 bit/96kHz
input, though - at least on my rather aging but quiet and stable P4 based
studio system.
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
If you want to use these two cards together, then
syncing with SPDIF is
pretty much required. The alsa_in/out programs add latency, and as the
website said, you should not record using those programs.
alsa_in/out programs can yield lower latency than jackd itself.
and i doubt, that anyone can hear the artifacts.
the website is for the version that came with jack 0.116.x
but the new algorithm is a lot better.
I can guarantee that you'd need to sync them
with SPDIF under Windows as
well as Linux, or you'll get clock drift between the cards.
alsa_out tools are build to compensate the clock drift.
15 Dec
15 Dec
2:37 p.m.
On Tue, Dec 14, 2010 at 12:55:11PM -0500, Joe Hartley wrote:
On Tue, 14 Dec 2010 18:23:47 +0100
torbenh <torbenh(a)gmx.de> wrote:
the cards are not synced.
the program just compensates for the drift.
it does this by slightly resampling the stream.
if you can hardware sync your cards, then by all means do it. its
better. alsa_io will burn quite a bit of cpu.
its just normally is the easiest solution, and works without hardware
sync.
and the claim that it adds latency is wrong.
On Tue, Dec 14, 2010 at 11:55:03AM -0500, Joe
Hartley wrote:
Fairly impressive performance, then! I'm not likely to revamp my setup
(Don't fix what isn't broken!) but do you feel this is fast and stable
enough for studio use?
My skeptical side feels that a software solution to sync the cards will
always be inferior to using hardware-based master/slave clocking, but it's
entirely possible that systems are more than fast enough to handle this easily. If you want to use these two cards together, then
syncing with SPDIF is
pretty much required. The alsa_in/out programs add latency, and as the
website said, you should not record using those programs.
alsa_in/out programs can yield lower latency than jackd itself.
and i doubt, that anyone can hear the artifacts.
the website is for the version that came with jack 0.116.x
but the new algorithm is a lot better.
I can guarantee that you'd need to sync them
with SPDIF under Windows as
well as Linux, or you'll get clock drift between the cards.
alsa_out tools are build to compensate the clock drift.
I'm not sure I'd want to rely on it for recording 16 channels of 24 bit/96kHz
input, though - at least on my rather aging but quiet and stable P4 based
studio system.
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
torben Hohn
2 p.m.
New subject: Multiple sound cards
I've put up how I got it to work here:
http://delta.brainiac.com/deltasync.html
I run 2 Delta 1010s synced up and it works well for me.
I tried this setup on Puredyne 911 (based on Ubuntu Karmic, but without
pulseaudio).
I added the suggested lines in /etc/modprobe.d/alsa-base.conf to get the
m-audio cards to load first.
I added the ~/.asoundrc with the suggested content.
At least the ~./asoundrc didn't seem to work.
Perhaps on Ubuntu Karmic this needs to be done differently?
--
ailo
3:38 p.m.
New subject: Multiple sound cards
On Wed, Dec 15, 2010 at 8:00 AM, ailo <ailo.at(a)gmail.com> wrote:
as has been noted, the order of the cards matters only if you insist
on referring to them by number. refer to them by name and the problem
goes away.
I've put
up how I got it to work here:
http://delta.brainiac.com/deltasync.html
I run 2 Delta 1010s synced up and it works well for me.
I tried this setup on Puredyne 911 (based on Ubuntu Karmic, but without
pulseaudio).
I added the suggested lines in /etc/modprobe.d/alsa-base.conf to get the
m-audio cards to load first.
I added the ~/.asoundrc with the suggested content.
4:09 p.m.
New subject: Multiple sound cards
On 12/15/2010 03:38 PM, Paul Davis wrote:
On Wed, Dec 15, 2010 at 8:00 AM,
ailo<ailo.at(a)gmail.com> wrote:
as has been noted, the order of the cards matters only if you insist
on referring to them by number. refer to them by name and the problem
goes away.
In this case I'm trying to load 2 cards with a single interface as
described here: http://delta.brainiac.com/deltasync.html
I'm investigating the way the system is setup (Puredyne 911), whether
alsa reads ~/.asoundrc or not.
It seems to me that the way alsa works and is configured has changed a
bit over the years, so perhaps it will take some tweaking to get this
particular setup to work.
As a footnote, getting puredata to use multiple cards using OSS seems to
work pretty well (I suppose this is a builtin feature for puredata).
After a quick test I did not hear any clicks (don't know if my spdif
sync between the m-audio delta cards is set up right, and I have no way
to tell as of now).
--
ailo
I've
put up how I got it to work here:
http://delta.brainiac.com/deltasync.html
I run 2 Delta 1010s synced up and it works well for me.
I tried this setup on Puredyne 911 (based on Ubuntu Karmic, but without
pulseaudio).
I added the suggested lines in /etc/modprobe.d/alsa-base.conf to get the
m-audio cards to load first.
I added the ~/.asoundrc with the suggested content.
11:15 p.m.
New subject: Multiple sound cards
i think you need to post your ~/.asoundrc file.
AFAIK, any attempt to use an ALSA device, no matter whether its via
the OSS API, Pulse or JACK, will result in ~/.asoundrc being loaded
and used to define device names and other miscellania.
its entirely possible to refer to cards by name in ~/.asoundrc as well.
11:30 p.m.
New subject: Multiple sound cards
On 12/15/2010 11:15 PM, Paul Davis wrote:
i think you need to post your ~/.asoundrc file.
AFAIK, any attempt to use an ALSA device, no matter whether its via
the OSS API, Pulse or JACK, will result in ~/.asoundrc being loaded
and used to define device names and other miscellania.
its entirely possible to refer to cards by name in ~/.asoundrc as well.
I used the exact same ~/.asoundrc as here
http://delta.brainiac.com/deltasync.html.
I only have one reservation about that file. Instead of two
delta-1010's, I use one delta-1010 and one delta-66.
Both have the same chip and present the same number of inputs and
outputs, even though only a part of them are usable on the delta-66.
cat /proc/asound/cards showed this about the m-audio cards:
0 [M1010LT ]: ICE1712 - M Audio Delta 1010LT
M Audio Delta 1010LT at 0xec00, irq 19
1 [M66 ]: ICE1712 - M Audio Delta 66
M Audio Delta 66 at 0xe400, irq 18
I did try changing all instances of hw:0 to hw:M1010LT and all instances
of hw:1 to hw:M66.
This is the file:
# .asoundrc for two Delta 1010s
#
# Create virtual devices out of multiple soundcards.
# JACK will need MMAP_COMPLEX support to use this.
# ICE1712 chip has 12 capture channels and 10 playback channels.
# No. of channels in slaves must equal 12 for capture and 10 for playback
# otherwise "invalid argument" errors result.
########### Old .asoundrc config
#pcm.ice1712 {
# type hw
# card 0
#}
#
#ctl.ice1712 {
# type hw
# card 0
#}
############
pcm.multi_capture {
type multi
slaves.a.pcm hw:0
slaves.a.channels 12
slaves.b.pcm hw:1
slaves.b.channels 12
# First 8 channels of first soundcard (capture)
bindings.0.slave a
bindings.0.channel 0
bindings.1.slave a
bindings.1.channel 1
bindings.2.slave a
bindings.2.channel 2
bindings.3.slave a
bindings.3.channel 3
bindings.4.slave a
bindings.4.channel 4
bindings.5.slave a
bindings.5.channel 5
bindings.6.slave a
bindings.6.channel 6
bindings.7.slave a
bindings.7.channel 7
# First 8 channels of second soundcard (capture)
bindings.8.slave b
bindings.8.channel 0
bindings.9.slave b
bindings.9.channel 1
bindings.10.slave b
bindings.10.channel 2
bindings.11.slave b
bindings.11.channel 3
bindings.12.slave b
bindings.12.channel 4
bindings.13.slave b
bindings.13.channel 5
bindings.14.slave b
bindings.14.channel 6
bindings.15.slave b
bindings.15.channel 7
}
ctl.multi_capture {
type hw
card 0
}
pcm.multi_playback {
type multi
slaves.a.pcm hw:0
slaves.a.channels 10
slaves.b.pcm hw:1
slaves.b.channels 10
# First 8 channels of first soundcard (playback)
bindings.0.slave a
bindings.0.channel 0
bindings.1.slave a
bindings.1.channel 1
bindings.2.slave a
bindings.2.channel 2
bindings.3.slave a
bindings.3.channel 3
bindings.4.slave a
bindings.4.channel 4
bindings.5.slave a
bindings.5.channel 5
bindings.6.slave a
bindings.6.channel 6
bindings.7.slave a
bindings.7.channel 7
# First 8 channels of second soundcard (playback)
bindings.8.slave b
bindings.8.channel 0
bindings.9.slave b
bindings.9.channel 1
bindings.10.slave b
bindings.10.channel 2
bindings.11.slave b
bindings.11.channel 3
bindings.12.slave b
bindings.12.channel 4
bindings.13.slave b
bindings.13.channel 5
bindings.14.slave b
bindings.14.channel 6
bindings.15.slave b
bindings.15.channel 7
}
ctl.multi_playback {
type hw
card 0
}
--
ailo
11:35 p.m.
New subject: Multiple sound cards
On Wed, Dec 15, 2010 at 5:30 PM, ailo <ailo.at(a)gmail.com> wrote:
On 12/15/2010 11:15 PM, Paul Davis wrote:
so what is the output of:
aplay -L
and
arecord -L
i think you need to post your ~/.asoundrc file.
AFAIK, any attempt to use an ALSA device, no matter whether its via
the OSS API, Pulse or JACK, will result in ~/.asoundrc being loaded
and used to define device names and other miscellania.
its entirely possible to refer to cards by name in ~/.asoundrc as well.
I used the exact same ~/.asoundrc as here
http://delta.brainiac.com/deltasync.html.
11:52 p.m.
New subject: Multiple sound cards
Ok, so there is a third device here as well, at hw:2, which I
intentionally left out before.
aplay -L
null
Discard all samples (playback) or generate zero samples (capture)
default:CARD=M1010LT
M Audio Delta 1010LT, ICE1712 multi
Default Audio Device
front:CARD=M1010LT,DEV=0
M Audio Delta 1010LT, ICE1712 multi
Front speakers
surround40:CARD=M1010LT,DEV=0
M Audio Delta 1010LT, ICE1712 multi
4.0 Surround output to Front and Rear speakers
surround41:CARD=M1010LT,DEV=0
M Audio Delta 1010LT, ICE1712 multi
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=M1010LT,DEV=0
M Audio Delta 1010LT, ICE1712 multi
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=M1010LT,DEV=0
M Audio Delta 1010LT, ICE1712 multi
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
iec958:CARD=M1010LT,DEV=0
M Audio Delta 1010LT, ICE1712 multi
IEC958 (S/PDIF) Digital Audio Output
default:CARD=M66
M Audio Delta 66, ICE1712 multi
Default Audio Device
front:CARD=M66,DEV=0
M Audio Delta 66, ICE1712 multi
Front speakers
surround40:CARD=M66,DEV=0
M Audio Delta 66, ICE1712 multi
4.0 Surround output to Front and Rear speakers
surround41:CARD=M66,DEV=0
M Audio Delta 66, ICE1712 multi
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=M66,DEV=0
M Audio Delta 66, ICE1712 multi
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=M66,DEV=0
M Audio Delta 66, ICE1712 multi
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
iec958:CARD=M66,DEV=0
M Audio Delta 66, ICE1712 multi
IEC958 (S/PDIF) Digital Audio Output
default:CARD=NVidia
HDA NVidia, VT1708S Analog
Default Audio Device
front:CARD=NVidia,DEV=0
HDA NVidia, VT1708S Analog
Front speakers
surround40:CARD=NVidia,DEV=0
HDA NVidia, VT1708S Analog
4.0 Surround output to Front and Rear speakers
surround41:CARD=NVidia,DEV=0
HDA NVidia, VT1708S Analog
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=NVidia,DEV=0
HDA NVidia, VT1708S Analog
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=NVidia,DEV=0
HDA NVidia, VT1708S Analog
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=NVidia,DEV=0
HDA NVidia, VT1708S Analog
7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
--
ailo
16 Dec
16 Dec
12:14 a.m.
New subject: Multiple sound cards
On 12/15/2010 11:58 PM, Paul Davis wrote:
On Wed, Dec 15, 2010 at 5:52 PM,
ailo<ailo.at(a)gmail.com> wrote:
Apart from the aplay -L result at the end I got a lot of this:
...
open("/dev/snd/controlC2", O_RDWR|O_CLOEXEC) = 4
open("/dev/snd/controlC2", O_RDONLY|O_CLOEXEC) = 4
open("/dev/snd/controlC2", O_RDWR|O_CLOEXEC) = 4
...
and this
...
open("/dev/snd/controlC3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file
or directory)
open("/dev/aloadC3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
open("/dev/snd/controlC4", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file
or directory)
open("/dev/aloadC4", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
open("/dev/snd/controlC5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file
or directory)
open("/dev/aloadC5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
open("/dev/snd/controlC6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file
or directory)
open("/dev/aloadC6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
open("/dev/snd/controlC7", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file
or directory)
...
--
ailo
Ok, so there is a third device here as well, at
hw:2, which I intentionally
left out before.
aplay -L
ok, so now try:
strace -e trace=open aplay -L
12:18 a.m.
New subject: Multiple sound cards
On Wed, Dec 15, 2010 at 6:14 PM, ailo <ailo.at(a)gmail.com> wrote:
On 12/15/2010 11:58 PM, Paul Davis wrote:
that's not what we're looking for. it should open ~/.asoundrc
if it doesn't show with that command, use
strace -e trace=file aplay -L
On Wed, Dec 15, 2010 at 5:52 PM, ailo<ailo.at(a)gmail.com> Â wrote:
Apart from the aplay -L result at the end I got a lot of this:
Ok, so there is a third device here as well, at hw:2, which I
intentionally
left out before.
aplay -L
ok, so now try:
  strace -e trace=open aplay -L
12:26 a.m.
New subject: Multiple sound cards
Apart from the
aplay -L result at the end I got a lot of this:
that's not what we're looking for. it should open ~/.asoundrc
if it doesn't show with that command, use
strace -e trace=file aplay -L
1:14 a.m.
New subject: Multiple sound cards
On 12/16/2010 12:26 AM, ailo wrote:
How can I make sure editing ~/.asoundrc has any effect?
Perhaps you were looking for the result at the end of this reply?
It's exactly the same as the result from aplay -L.
null
Discard all samples (playback) or generate zero samples (capture)
default:CARD=M1010LT
M Audio Delta 1010LT, ICE1712 multi
Default Audio Device
front:CARD=M1010LT,DEV=0
M Audio Delta 1010LT, ICE1712 multi
Front speakers
surround40:CARD=M1010LT,DEV=0
M Audio Delta 1010LT, ICE1712 multi
4.0 Surround output to Front and Rear speakers
surround41:CARD=M1010LT,DEV=0
M Audio Delta 1010LT, ICE1712 multi
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=M1010LT,DEV=0
M Audio Delta 1010LT, ICE1712 multi
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=M1010LT,DEV=0
M Audio Delta 1010LT, ICE1712 multi
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
iec958:CARD=M1010LT,DEV=0
M Audio Delta 1010LT, ICE1712 multi
IEC958 (S/PDIF) Digital Audio Output
default:CARD=M66
M Audio Delta 66, ICE1712 multi
Default Audio Device
front:CARD=M66,DEV=0
M Audio Delta 66, ICE1712 multi
Front speakers
surround40:CARD=M66,DEV=0
M Audio Delta 66, ICE1712 multi
4.0 Surround output to Front and Rear speakers
surround41:CARD=M66,DEV=0
M Audio Delta 66, ICE1712 multi
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=M66,DEV=0
M Audio Delta 66, ICE1712 multi
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=M66,DEV=0
M Audio Delta 66, ICE1712 multi
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
iec958:CARD=M66,DEV=0
M Audio Delta 66, ICE1712 multi
IEC958 (S/PDIF) Digital Audio Output
default:CARD=NVidia
HDA NVidia, VT1708S Analog
Default Audio Device
front:CARD=NVidia,DEV=0
HDA NVidia, VT1708S Analog
Front speakers
surround40:CARD=NVidia,DEV=0
HDA NVidia, VT1708S Analog
4.0 Surround output to Front and Rear speakers
surround41:CARD=NVidia,DEV=0
HDA NVidia, VT1708S Analog
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=NVidia,DEV=0
HDA NVidia, VT1708S Analog
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=NVidia,DEV=0
HDA NVidia, VT1708S Analog
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=NVidia,DEV=0
HDA NVidia, VT1708S Analog
7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
--
ailo
Apart
from the aplay -L result at the end I got a lot of this:
that's not what we're looking for. it should open ~/.asoundrc
if it doesn't show with that command, use
strace -e trace=file aplay -L
2:06 a.m.
New subject: Multiple sound cards
On Wed, Dec 15, 2010 at 7:14 PM, ailo <ailo.at(a)gmail.com> wrote:
On 12/16/2010 12:26 AM, ailo wrote:
How can I make sure editing ~/.asoundrc has any effect?
that is what we were doing. what is the output of:
ls -l ~/.asoundrc
Apart
from the aplay -L result at the end I got a lot of this:
that's not what we're looking for. it should open ~/.asoundrc
if it doesn't show with that command, use
strace -e trace=file aplay -L
2:08 a.m.
New subject: Multiple sound cards
On Wed, Dec 15, 2010 at 8:06 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Wed, Dec 15, 2010 at 7:14 PM, ailo
<ailo.at(a)gmail.com> wrote:
also, check /etc/share/alsa/alsa.conf for this block of text, or
something very much like it:
@hooks [
{
func load
files [
"/etc/asound.conf"
"~/.asoundrc"
]
errors false
}
]
this is how ~/.asoundrc is loaded.
On 12/16/2010 12:26 AM, ailo wrote:
How can I make sure editing ~/.asoundrc has any effect?
that is what we were doing. what is the output of:
 ls -l ~/.asoundrc > Apart from the aplay -L result at the end I
got a lot of this:
that's not what we're looking for. it should open ~/.asoundrc
if it doesn't show with that command, use
strace -e trace=file aplay -L
2:16 a.m.
New subject: Multiple sound cards
On 12/16/2010 02:08 AM, Paul Davis wrote:
On Wed, Dec 15, 2010 at 8:06 PM, Paul
Davis<paul(a)linuxaudiosystems.com> wrote:
Yes, I checked that. I was reading up on .asoundrc on the alsa
unofficial wiki.
Alsa, I noticed that aplay -L gave me an error after I had made a typo
in .asoundrc, so it's definitely doing something.
#ls -l .asoundrc
-rw-r--r-- 1 ailo ailo 69 2010-12-16 02:01 .asoundrc
--
ailo
On Wed, Dec 15, 2010 at 7:14 PM,
ailo<ailo.at(a)gmail.com> wrote:
also, check /etc/share/alsa/alsa.conf for this block of text, or
something very much like it:
@hooks [
{
func load
files [
"/etc/asound.conf"
"~/.asoundrc"
]
errors false
}
]
this is how ~/.asoundrc is loaded. On 12/16/2010 12:26 AM, ailo wrote:
that is what we were doing. what is the output of:
ls -l ~/.asoundrc
>> Apart from the aplay -L result at the end I got a lot of this:
>
> that's not what we're looking for. it should open ~/.asoundrc
> if it doesn't show with that command, use
>
> strace -e trace=file aplay -L
How can I make sure editing ~/.asoundrc has any effect?
3:05 a.m.
New subject: Multiple sound cards
It seems that I finally woke up! Still not getting any sound, but
working on it.
I was so stuck on that multi_capture and multi_playback would show up in
qjackctl, so that I never even tried:
jackd -d alsa -C multi_capture -P multi_playback
(multi_capture and multi_playback are defined in ~/.asoundrc as stated
in a previous reply.)
Where can they be found? aplay -L doesn't seem to output these
interfaces, right?
Thanks for all your help!
--
ailo
3:40 a.m.
New subject: Multiple sound cards
On 12/16/2010 03:05 AM, ailo wrote:
It seems to work really well. I got sound now. Finally!
So, a recap:
I used the original ~/.asoundrc from
http://delta.brainiac.com/deltasync.html, but replaced the "hw:0" with
"hw:M1010LT", and "hw:1" with "hw:M66", so that I don't
have to edit the
/etc/modprobe.d/alsa-base.conf.
Also, the only method that works for me starting jack is from the
command line:
jackd -d alsa -C multi_capture -P multi_playback.
I'm also wondering about the spdif sync method. In this .asoundrc,
digital ins and outs are not dealt with. Isn't this needed in order to
sync the cards?
(This does not affect me so much, however, since I am not going to do
studio recording with this setup, at least for the time being).
Anyway, I'm satisfied here.
Again, thanks for all your help!
--
ailo
9:28 a.m.
New subject: Multiple sound cards
On Thu, 2010-12-16 at 03:40 +0100, ailo wrote:
Also, the only method that works for me starting jack
is from the
command line:
jackd -d alsa -C multi_capture -P multi_playback.
I'm also wondering about the spdif sync method. In this .asoundrc,
digital ins and outs are not dealt with. Isn't this needed in order to
sync the cards?
Qjackctl is well behaved there: although it provides device drop downs,
you can also just type the device names in.
The S/PDIF synchronisation should be provided by the card's hardware and
settings (envy24control -> Hardware Settings -> Master Clock -> S/PDIF
in, on one of the cards)
Peter.
P.S. When someone asks you to type "ls -l ~/.asoundrc", it's rather
helpful, in a remote diagnostics situation, to just do that instead of
changing it to "ls -l .asoundrc"
12:45 p.m.
New subject: Multiple sound cards
On 12/16/2010 09:28 AM, Peter Nelson wrote:
On Thu, 2010-12-16 at 03:40 +0100, ailo wrote:
I did this, using a normal audio cable. It seems to work.
At first my changed settings had no effect, since changing spdif
settings on envy24control didn't seem to work while jack was running.
Also, the only method that works for me starting
jack is from the
command line:
jackd -d alsa -C multi_capture -P multi_playback.
I'm also wondering about the spdif sync method. In this .asoundrc,
digital ins and outs are not dealt with. Isn't this needed in order to
sync the cards?
Qjackctl is well behaved there: although it provides device drop downs,
you can also just type the device names in.
The S/PDIF synchronisation should be provided by the card's hardware and
settings (envy24control -> Hardware Settings -> Master Clock -> S/PDIF
in, on one of the cards)
Peter.
P.S. When someone asks you to type "ls -l ~/.asoundrc", it's rather
helpful, in a remote diagnostics situation, to just do that instead of
changing it to "ls -l .asoundrc"
Yes, thank you. Making too many assumptions seems to be a mental disease
of mine. I do try to do things by the letter, or try the simple
solutions first for that matter :). In my defence, I am a musician first
and a Linux enthusiast second.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
ailo
17 Dec
17 Dec
2:21 a.m.
New subject: Multiple sound cards
On Wed, Dec 15, 2010 at 08:08:41PM -0500, Paul Davis wrote:
On Wed, Dec 15, 2010 at 8:06 PM, Paul Davis
<paul(a)linuxaudiosystems.com> wrote:
Hmm. There is no such file as /etc/share/alsa/alsa.conf. I think you mean
/usr/share/alsa/alsa.conf, which does indeed have this block.
-ken
On Wed, Dec 15, 2010 at 7:14 PM, ailo
<ailo.at(a)gmail.com> wrote:
also, check /etc/share/alsa/alsa.conf for this block of text, or
something very much like it:
@hooks [
{
func load
files [
"/etc/asound.conf"
"~/.asoundrc"
]
errors false
}
]
this is how ~/.asoundrc is loaded. On 12/16/2010 12:26 AM, ailo wrote:
that is what we were doing. what is the output of:
? ls -l ~/.asoundrc
>> Apart from the aplay -L result at the end I got a lot of this:
>
> that's not what we're looking for. it should open ~/.asoundrc
> if it doesn't show with that command, use
>
> strace -e trace=file aplay -L
How can I make sure editing ~/.asoundrc has any effect? 
16 Dec
16 Dec
4:15 p.m.
New subject: Multiple sound cards
On Wednesday 15 December 2010 09:38:15 Paul Davis wrote:
On Wed, Dec 15, 2010 at 8:00 AM, ailo
<ailo.at(a)gmail.com> wrote:
as has been noted, the order of the cards matters only if you insist
on referring to them by number. refer to them by name and the problem
goes away.
This only helps when they don't have the same name right? Or has that changed?
all the best,
drew
I've
put up how I got it to work here:
http://delta.brainiac.com/deltasync.html
I run 2 Delta 1010s synced up and it works well for me.
I tried this setup on Puredyne 911 (based on Ubuntu Karmic, but without
pulseaudio).
I added the suggested lines in /etc/modprobe.d/alsa-base.conf to get the
m-audio cards to load first.
I added the ~/.asoundrc with the suggested content.
4:29 p.m.
New subject: Multiple sound cards
On 12/16/2010 04:14 PM, drew Roberts wrote:
On Wednesday 15 December 2010 09:38:15 Paul Davis
wrote:
It would be interesting to know how to start the chosen card not using
neither name or id.
How does pulseaudio do it? How does any program remember the default
audio card?
On Wed, Dec 15, 2010 at 8:00 AM,
ailo<ailo.at(a)gmail.com> wrote:
as has been noted, the order of the cards matters only if you insist
on referring to them by number. refer to them by name and the problem
goes away.
This only helps when they don't have the same name right? Or has that changed?
I've
put up how I got it to work here:
http://delta.brainiac.com/deltasync.html
I run 2 Delta 1010s synced up and it works well for me.
I tried this setup on Puredyne 911 (based on Ubuntu Karmic, but without
pulseaudio).
I added the suggested lines in /etc/modprobe.d/alsa-base.conf to get the
m-audio cards to load first.
I added the ~/.asoundrc with the suggested content.
all the best,
drew
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
ailo
4:33 p.m.
New subject: Multiple sound cards
On Thu, Dec 16, 2010 at 10:29 AM, ailo <ailo.at(a)gmail.com> wrote:
How does pulseaudio do it? How does any program
remember the default audio
card?
i am not sure that *any* programs can handle this with two identical
cards. ALSA doesn't provide any way to identify <this> instance of a
Foobar-100 rather than <that> version of a Foobar-100. and ALSA
doesn't do it because a lot of hardware doesn't provide it either.
its normally just the name of the card.
4:38 p.m.
New subject: Multiple sound cards
On Thu, Dec 16, 2010 at 7:33 AM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Thu, Dec 16, 2010 at 10:29 AM, ailo
<ailo.at(a)gmail.com> wrote:
I don't know this for sure but I think Windows does that determination
based on figuring out which PCI slot a specific card is plugged into?
Is there some way to do this in a Linux script that makes sense?
- Mark
How does pulseaudio do it? How does any program
remember the default audio
card?
i am not sure that *any* programs can handle this with two identical
cards. ALSA doesn't provide any way to identify <this> instance of a
Foobar-100 rather than <that> version of a Foobar-100. and ALSA
doesn't do it because a lot of hardware doesn't provide it either.
its normally just the name of the card.
4:39 p.m.
New subject: Multiple sound cards
On 12/16/2010 04:33 PM, Paul Davis wrote:
On Thu, Dec 16, 2010 at 10:29 AM,
ailo<ailo.at(a)gmail.com> wrote:
Well, how about remembering the pci-slot for pci cards and doing
something based on that?
And doesn't usb class compliant cards have a way to be uniquely
identified? (I seem to remember something about that)
--
ailo
How does pulseaudio do it? How does any program
remember the default audio
card?
i am not sure that *any* programs can handle this with two identical
cards. ALSA doesn't provide any way to identify<this> instance of a
Foobar-100 rather than<that> version of a Foobar-100. and ALSA
doesn't do it because a lot of hardware doesn't provide it either.
its normally just the name of the card.
4:53 p.m.
New subject: Multiple sound cards
On 12/16/2010 04:39 PM, ailo wrote:
On 12/16/2010 04:33 PM, Paul Davis wrote:
If at all relevant, I was referring to this:
# modinfo -p snd-ice1724
model:Use the given board model.
enable:Enable ICE1724 soundcard.
id:ID string for ICE1724 soundcard.
index:Index value for ICE1724 soundcard.
# modinfo -p snd-usb-audio
ignore_ctl_error:Ignore errors from USB controller for mixer interfaces.
device_setup:Specific device setup (if needed).
async_unlink:Use async unlink mode.
nrpacks:Max. number of packets per URB.
pid:Product ID for the USB audio device.
vid:Vendor ID for the USB audio device.
enable:Enable USB audio adapter.
id:ID string for the USB audio adapter.
index:Index value for the USB audio adapter.
--
ailo
On Thu, Dec 16, 2010 at 10:29 AM,
ailo<ailo.at(a)gmail.com> wrote:
Well, how about remembering the pci-slot for pci cards and doing
something based on that?
And doesn't usb class compliant cards have a way to be uniquely
identified? (I seem to remember something about that)
How does pulseaudio do it? How does any program
remember the default
audio
card?
i am not sure that *any* programs can handle this with two identical
cards. ALSA doesn't provide any way to identify<this> instance of a
Foobar-100 rather than<that> version of a Foobar-100. and ALSA
doesn't do it because a lot of hardware doesn't provide it either.
its normally just the name of the card.
14 Dec
14 Dec
6:19 p.m.
On Tue, Dec 14, 2010 at 05:44:36PM +0100, ailo wrote:
On 12/14/2010 12:28 PM, Florian Faber wrote:
the wiki page on alsa_io is outdated.
see the manpage.
if you run jackd with a period size of 128... running alsa_out -d hw:1 -p 128
should give you good results with jack >= 0.118
Robin,
>OOPS: I've just realized that two of your devices are identical.
>I don't think the name will help in that case. IIRC there's away to use
>a UID or BUS like /dev/snd/by-path/.. but I don't remember the details
>just now.
Actually, the cards do have different names, now when I think of it.
It's the chip that is the same.
Still, it feels better to use an unique id. Perhaps /dev/snd/by-path
is a good way to do that. If I understand correctly, this is the
path to the actual pci-slot (which is not likely to change between
boots).
If the ICE-cards have serial numbers, it could be an effective solution
to add it to the card's name. RME cards are quite commonly used in
bundles, so I added this feature:
# cat /proc/asound/cards
0 [default ]: HDSPM - RME MADI_c61f8e
RME MADI S/N 0xc61f8e at 0xfdef0000, irq 16
It also allows to identify cards in the LAN. In infrastructure setups
the host no longer is the top level namespace.
Flo
With my limited understanding the only thing I can discover here is:
0 [default ]
is usually :
0 [nameofcard ]
So, I'm afraid I can't read further into how to use the serial
number to identify the card.
Starting jack by using
jackd -d alsa -d 'hw:nameofcard'
may solve my problem.
I'm looking on how to sync the two cards, delta-1010 and delta-66.
AFAIK, no matter the method, it seems one must sync them using spdif
(don't think this is needed on Windows, but perhaps that has to do
with proprietary drivers?).
There is this method:
http://www.jrigg.co.uk/linuxaudio/ice1712multi.html
and one that I haven't tried yet is using alsa_in and alsa_out as
mentioned here:
http://trac.jackaudio.org/wiki/WalkThrough/User/AlsaInOut
If someone has some experience in using multiple cards, I won't mind
a pointer or two.
--
ailo
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
torben Hohn
15 Dec
15 Dec
10:41 p.m.
On 12/14/2010 06:19 PM, torbenh wrote:
if you run jackd with a period size of 128... running
alsa_out -d hw:1 -p 128
should give you good results with jack>= 0.118
I tried this, but was never able to get good sound from the alsa_out
device. I put a lot of effort in making sure I used the right flags, but
there would always be a stable periodic jitter.
I tried this on two different systems: Puredyne (I compiled the latest
stable jackdmp from source) and TangoStudio (which comes with jackd
0.118). Both on amd64, if that makes any difference.
As reference, I am getting really good results using multiple devices on
puredata using OSS. No broken sound at around 5 ms.
Is there some way I can debug alsa_in/out?
--
ailo
10:48 p.m.
On Wed, Dec 15, 2010 at 4:41 PM, ailo <ailo.at(a)gmail.com> wrote:
On 12/14/2010 06:19 PM, torbenh wrote:
this isn't very useful info, mostly, because "usng OSS" on puredata
means that you're still using the same underlying drivers.
how do you tell Pd to use OSS for this ?
if you run jackd with a period size of 128... running alsa_out -d hw:1 -p
128
should give you good results with jack>= 0.118
I tried this, but was never able to get good sound from the alsa_out device.
I put a lot of effort in making sure I used the right flags, but there would
always be a stable periodic jitter.
I tried this on two different systems: Puredyne (I compiled the latest
stable jackdmp from source) and TangoStudio (which comes with jackd 0.118).
Both on amd64, if that makes any difference.
As reference, I am getting really good results using multiple devices on
puredata using OSS. No broken sound at around 5 ms.
11:05 p.m.
On 12/15/2010 10:48 PM, Paul Davis wrote:
On Wed, Dec 15, 2010 at 4:41 PM,
ailo<ailo.at(a)gmail.com> wrote:
What is underneath, I cannot say.
What I meant "as reference" was only that I get good sound doing it this
way, so at least I know it is possible to get these cards to sync.
As for how to set it up:
If you have more than one audio card and choose OSS from pd's "Media"
menu, there is a button for "multiple devices".
This expands the choices so that you can choose which cards are used for
input and which cards are used for output, as well as how many channels
are used for each input and output on each card.
--
ailo
On 12/14/2010 06:19 PM, torbenh wrote:
this isn't very useful info, mostly, because "usng OSS" on puredata
means that you're still using the same underlying drivers.
how do you tell Pd to use OSS for this ?
if you run jackd with a period size of 128... running alsa_out -d hw:1 -p
128
should give you good results with jack>= 0.118
I tried this, but was never able to get good sound from the alsa_out device.
I put a lot of effort in making sure I used the right flags, but there would
always be a stable periodic jitter.
I tried this on two different systems: Puredyne (I compiled the latest
stable jackdmp from source) and TangoStudio (which comes with jackd 0.118).
Both on amd64, if that makes any difference.
As reference, I am getting really good results using multiple devices on
puredata using OSS. No broken sound at around 5 ms.
1:50 p.m.
Ok, back to the original topic.
The setup is:
Three pci audio cards and a bunch of usb midi devices connected to my
computer.
Problem:
After booting the computer and doing cat /proc/asound/cards I find most
of the pci audio cards and usb midi devices listed.
I say most, because one or more of the devices is missing.
Quite often a midi usb device will be listed as the first choice.
This is not supposed to happen, right?
--
ailo
10:31 p.m.
On 12/15/2010 01:49 PM, ailo wrote:
Ok, back to the original topic.
The setup is:
Three pci audio cards and a bunch of usb midi devices connected to my
computer.
Problem:
After booting the computer and doing cat /proc/asound/cards I find most
of the pci audio cards and usb midi devices listed.
I say most, because one or more of the devices is missing.
Quite often a midi usb device will be listed as the first choice.
This is not supposed to happen, right?
So, this was just the result of me editing the
/etc/modprobe.d/alsa-base.conf.
After adding..
alias snd-card-0 snd-ice1712
options snd-ice1712 index=0
alias snd-card-1 snd-ice1712
options snd-ice1712 index=1
..these cards would not load if something else was loaded into those
indexes.
I suppose I could add all devices that are to be used (3 audio cards +
some usb devices) into this file, but I'm giving up this for now.
Anyway, I was only doing this in order to be able to write the
~/.asoundrc that would turn these two cards into one interface.
As stated in another reply it didn't work for me, even if the ice1712
cards were loaded into hw:0 and hw:1.
--
ailo
5080
days inactive
5083
days old
linux-audio-user@lists.linuxaudio.org
42 comments
10 participants
participants (10)
-
ailo -
drew Roberts -
Florian Faber -
Joe Hartley -
Ken Restivo -
Mark Knecht -
Paul Davis -
Peter Nelson -
Robin Gareus -
torbenh