31 Jan
2012
31 Jan
'12
5:40 a.m.
Hi,
I have two M-Audio Delta1010LT cards on Ubuntustudio 10.04 with FalkTx's
repos. I double checked, this is happening also on Kubuntu 11.10. Also
it's not a matter of the kernel, currently using 2.6.33-29-realtime.
I use Jack2, where can I find the exact version?
Only thing I know, it's jackdmp 1.9.7.
The cards are hardware synced via S-PDIF.
In envy24control, a mixer program that knows about these features, hw:0
is set to internal clock and hw:1 is set to S-PDIF.
I know of three options to get both cards working simultaneously, but
none is working quite perfectly.
a)use .asoundrc
I have a .asoundrc from the web.
After a few seconds, it crashes saying this:
Unknown request 4294967295
Destination port in attempted (dis)connection of system:monitor_6 and
system:monitor_6 is not an input port
Unknown request 4294967295
Unknown request 0
Unknown request 0
Unknown request 0
Unknown request 4294967295
Unknown request 0
Unknown request 4294967295
Unknown request 4294967295
jackd: ../common/JackGraphManager.cpp:45: void
Jack::JackGraphManager::AssertPort(jack_port_id_t): Assertion
`port_index < fPortMax' failed.
While running, it produces tons of xruns, each of them with -v option
generates a message like
Jack: fPollTable i = 1 fd = 11
Jack: JackRequest::Notification
Jack: JackEngine::NotifyClient: no callback for event = 3
Jack: JackEngine::NotifyClient: no callback for event = 3
The last thing I get before crashing is:
Jack: JackRequest::ConnectPorts
Jack: fPollTable i = 1 fd = 11
Jack: fPollTable i = 1 fd = 11
Jack: fPollTable i = 1 fd = 11
Jack: fPollTable i = 1 fd = 11
Jack: JackRequest::ConnectPorts
Jack: JackEngine::PortConnect src = -1 dst = 3
Jack: JackGraphManager::AssertPort port_index = 4294967295
But there is no delay of the second card.
b) use jack_load
this is working best atm, only it introduces a delay to the channels of
the second card when recording with ardour. I measured the delay... it's
exactly (periods/buffer)*(frames/period) frames.
However, I'm not able to delay the first card with the -O or -I options.
Probably the second is delayed as well, or this option is not working.
In ardour I can move the regions to be in sync, but it gets quite
confusing in bigger sessions.
Btw does jack_load resample?
c)use alsa_in
produces the same delay but additionally uses a lot of cpu. Resampling
is not what I want, and also shouldn't be necessary.
Does anyone have an idea on how to fix this?
I'd prefer a solution without resampling, as these cards are already
synced. Also there should be no delay and it should keep running for hours.
Thx!
Any help is appreciated.
/mn0
1 Feb
1 Feb
7:56 p.m.
Hi, I've been using 2 Delta 1010s together for a while, I hope I can
help a bit here. I've tried to put most of what I've learned on the
web at http://delta.brainiac.com/deltasync.html
On Tue, 31 Jan 2012 05:40:35 +0100 mn0 <mn0(a)fukked-up.de> wrote:
I use Jack2, where can I find the exact version?
Only thing I know, it's jackdmp 1.9.7.
That should be fine, it's what I use as well.
The cards are hardware synced via S-PDIF.
In envy24control, a mixer program that knows about these features, hw:0
is set to internal clock and hw:1 is set to S-PDIF.
So far, so good. I'll assume you're using a real S-PDIF cable and not
just an audio RCA cable.
a)use .asoundrc
I have a .asoundrc from the web.
After a few seconds, it crashes saying this:
Unknown request 4294967295
Destination port in attempted (dis)connection of system:monitor_6 and
system:monitor_6 is not an input port
Unknown request 4294967295
Unknown request 0
Unknown request 0
[ snip ]
Using the .asoundrc file to combine the cards into one logical device is
what I consider to be the "correct" way of doing this, so I'll focus on
that. Assumptions I'm making here:
- the Deltas are the only 2 sound devices in the system. This can be
verified by the command "cat /proc/asound/cards". On my system, this
is the output I see:
[jh@xtc ~]$ cat /proc/asound/cards
0 [M1010 ]: ICE1712 - M Audio Delta 1010
M Audio Delta 1010 at 0xdf80, irq 21
1 [M1010_1 ]: ICE1712 - M Audio Delta 1010
M Audio Delta 1010 at 0xdf40, irq 20
If you have a motherboard that has an integrated sound chip, you might
find your zero device is not a Delta, which is a problem. I had to disable
my onboard sound card in my motherboard's BIOS settings.
- You have hw:0 and hw:1 identified correctly. Unfortunately, sometimes
Linux has an issue with being able to consistently identify 2 identical
soundcards. I've had this happen in the past and it gets annoying. I
found it most liable to happen if I've made some other hardware change
to the machine, otherwise it's usually stable across reboots. It's
easily tested by using hw:0 to start jack and verifying that it
addresses the ports on the card you believe to be hw:0.
- You've got the right cards set as master clock and S/PDIF slave and that
the correct ports on each are connected. I've gotten this incorrect on
at least 2 occasions, so it's worth re-checking!
- The 2 1010LT's are not sharing any IRQs with other devices. "lsmod -v"
command will show you the IRQs of all the PCI devices. The Deltas should
have IRQs all to themselves. Here's my output edited to show just the
Deltas. IRQs 20 and 21 are not shared with any other device.
02:09.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 [Envy24] PCI
Multi-Channel I/O Controller (rev 02)
Subsystem: VIA Technologies Inc. M-Audio Delta 1010
Flags: bus master, medium devsel, latency 64, IRQ 21
I/O ports at df80 [size=32]
I/O ports at dfa0 [size=16]
I/O ports at df60 [size=16]
I/O ports at df00 [size=64]
Capabilities: <access denied>
Kernel driver in use: ICE1712
Kernel modules: snd-ice1712
02:0c.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 [Envy24] PCI
Multi-Channel I/O Controller (rev 02)
Subsystem: VIA Technologies Inc. M-Audio Delta 1010
Flags: bus master, medium devsel, latency 64, IRQ 20
I/O ports at df40 [size=32]
I/O ports at ded0 [size=16]
I/O ports at dec0 [size=16]
I/O ports at de80 [size=64]
Capabilities: <access denied>
Kernel driver in use: ICE1712
Kernel modules: snd-ice1712
If the hardware's setup is verified as OK, look at how you're starting
Jack. You didn't post the command used to start jack, so I can't say if
it's starting the way you expect. If you use QJackCtl to start jack,
the command that starts jack can be found by looking at the .jackdrc
file.
Hope this helps, or at least gives you a starting point for troubleshooting.
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
9:48 p.m.
Am 01.02.2012 19:56, schrieb Joe Hartley:
Yep.
Already is disabled.
Hi, I've been using 2 Delta 1010s together for a
while, I hope I can
help a bit here. I've tried to put most of what I've learned on the
web at http://delta.brainiac.com/deltasync.html
On Tue, 31 Jan 2012 05:40:35 +0100 mn0 <mn0(a)fukked-up.de> wrote:
compiled jack 1.9.8 yesterday - didn't help. Now back on 1.9.7.
I use Jack2, where can I find the exact version?
Only thing I know, it's jackdmp 1.9.7.
That should be fine, it's what I use as well. The cards are
hardware synced via S-PDIF.
In envy24control, a mixer program that knows about these features, hw:0
is set to internal clock and hw:1 is set to S-PDIF.
So far, so good. I'll assume you're using a real S-PDIF cable and not
just an audio RCA cable. a)use
.asoundrc
I have a .asoundrc from the web.
After a few seconds, it crashes saying this:
Unknown request 4294967295
Destination port in attempted (dis)connection of system:monitor_6 and
system:monitor_6 is not an input port
Unknown request 4294967295
Unknown request 0
Unknown request 0
[ snip ]
Using the .asoundrc file to combine the cards into one logical device is
what I consider to be the "correct" way of doing this, so I'll focus on
that. Assumptions I'm making here:
- the Deltas are the only 2 sound devices in the system. This can be
verified by the command "cat /proc/asound/cards". On my system, this
is the output I see:
[jh@xtc ~]$ cat /proc/asound/cards
0 [M1010 ]: ICE1712 - M Audio Delta 1010
M Audio Delta 1010 at 0xdf80, irq 21
1 [M1010_1 ]: ICE1712 - M Audio Delta 1010
M Audio Delta 1010 at 0xdf40, irq 20
If you have a motherboard that has an integrated sound chip, you might
find your zero device is not a Delta, which is a problem. I had to disable
my onboard sound card in my motherboard's BIOS settings.
- You have hw:0 and hw:1 identified correctly. Unfortunately, sometimes
Linux has an issue with being able to consistently identify 2 identical
soundcards. I've had this happen in the past and it gets annoying. I
found it most liable to happen if I've made some other hardware change
to the machine, otherwise it's usually stable across reboots. It's
easily tested by using hw:0 to start jack and verifying that it
addresses the ports on the card you believe to be hw:0.
Already done. They're both recognized and I know which hardware card
belongs to which device (always wondering after some time, so I check
that, first).
- You've got the right cards set as master clock and S/PDIF slave and that
the correct ports on each are connected. I've gotten this incorrect on
at least 2 occasions, so it's worth re-checking!
Already checked, now re-checked, it's ok.
- The 2 1010LT's are not sharing any IRQs with
other devices. "lsmod -v"
command will show you the IRQs of all the PCI devices. The Deltas should
have IRQs all to themselves. Here's my output edited to show just the
Deltas. IRQs 20 and 21 are not shared with any other device.
You mean "lspci -v". There seems to be a silly situation:
lspci -v | grep IRQ -B2 output(shortened to relevant IRQs):
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI
Controller #3 (rev 01)
Subsystem: Foxconn International, Inc. Device 0c7e
Flags: bus master, medium devsel, latency 0, IRQ 18
--
00:1f.2 IDE interface: Intel Corporation N10/ICH7 Family SATA IDE
Controller (rev 01) (prog-if 8f [Master SecP SecO PriP PriO])
Subsystem: Foxconn International, Inc. Device 0c7e
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 18
--
04:01.0 Multimedia audio controller: VIA Technologies Inc. ICE1712
[Envy24] PCI Multi-Channel I/O Controller (rev 02)
Subsystem: VIA Technologies Inc. Device d63b
Flags: bus master, medium devsel, latency 64, IRQ 22
--
04:05.0 Multimedia audio controller: VIA Technologies Inc. ICE1712
[Envy24] PCI Multi-Channel I/O Controller (rev 02)
Subsystem: VIA Technologies Inc. Device d63b
Flags: bus master, medium devsel, latency 64, IRQ 18
So...SATA, USB and ICE1712 share one interrupt.
How can I change the interrupt of the devices, except by moving them to
another slot? Though I'd really like to get rid of this, I can't
imagine, this is responsible for
Jack: JackGraphManager::AssertPort port_index = 4294967295
Looks like a dangling or uninitialized pointer to me.
02:09.0 Multimedia audio controller: VIA Technologies
Inc. ICE1712 [Envy24] PCI Multi-Channel I/O Controller (rev 02)
Subsystem: VIA Technologies Inc. M-Audio Delta 1010
Flags: bus master, medium devsel, latency 64, IRQ 21
I/O ports at df80 [size=32]
I/O ports at dfa0 [size=16]
I/O ports at df60 [size=16]
I/O ports at df00 [size=64]
Capabilities: <access denied>
Kernel driver in use: ICE1712
Kernel modules: snd-ice1712
02:0c.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 [Envy24] PCI
Multi-Channel I/O Controller (rev 02)
Subsystem: VIA Technologies Inc. M-Audio Delta 1010
Flags: bus master, medium devsel, latency 64, IRQ 20
I/O ports at df40 [size=32]
I/O ports at ded0 [size=16]
I/O ports at dec0 [size=16]
I/O ports at de80 [size=64]
Capabilities: <access denied>
Kernel driver in use: ICE1712
Kernel modules: snd-ice1712
If the hardware's setup is verified as OK, look at how you're starting
Jack. You didn't post the command used to start jack, so I can't say if
it's starting the way you expect. If you use QJackCtl to start jack,
the command that starts jack can be found by looking at the .jackdrc
file.
I normally use QJackCtl, except for debugging this. QJackCtl froze and I
wasn't able to read the output. The command normally is:
/usr/bin/jackd -P89 -v -dalsa -r48000 -p256 -n4 -m -D -Cmulti_capture
-Pmulti_playback
but other frames/period, Priority etc. settings don't help.
I tried the settings from your page but without success.
Hope this helps, or at least gives you a starting point for troubleshooting.
Oh
yes, I found the shared IRQs and I know for certain, it's possible to
use jack 1.9.7 with .asoundrc and two ICE1712.
Thank you!
/mn0
10:24 p.m.
Just compiled jack1 but conflicts with jack2.
Won't checkinstall...
tried make install
and it installs but doesn't work -
undefined symbols.
Doesn't overwrite all libs, as it seems.
would have been good to test, if it's a jack2 specific problem.
/mn0
Am 01.02.2012 21:48, schrieb mn0:
Am 01.02.2012 19:56, schrieb Joe Hartley:
Yep.
Already is disabled.
Hi, I've been using 2 Delta 1010s together
for a while, I hope I can
help a bit here. I've tried to put most of what I've learned on the
web at http://delta.brainiac.com/deltasync.html
On Tue, 31 Jan 2012 05:40:35 +0100 mn0 <mn0(a)fukked-up.de> wrote:
compiled jack 1.9.8 yesterday - didn't help. Now back on 1.9.7.
I use Jack2, where can I find the exact version?
Only thing I know, it's jackdmp 1.9.7.
That should be fine, it's what I use as well. The cards
are hardware synced via S-PDIF.
In envy24control, a mixer program that knows about these features, hw:0
is set to internal clock and hw:1 is set to S-PDIF.
So far, so good. I'll assume you're using a real S-PDIF cable and not
just an audio RCA cable. a)use
.asoundrc
I have a .asoundrc from the web.
After a few seconds, it crashes saying this:
Unknown request 4294967295
Destination port in attempted (dis)connection of system:monitor_6 and
system:monitor_6 is not an input port
Unknown request 4294967295
Unknown request 0
Unknown request 0
[ snip ]
Using the .asoundrc file to combine the cards into one logical device is
what I consider to be the "correct" way of doing this, so I'll focus on
that. Assumptions I'm making here:
- the Deltas are the only 2 sound devices in the system. This can be
verified by the command "cat /proc/asound/cards". On my system, this
is the output I see:
[jh@xtc ~]$ cat /proc/asound/cards
0 [M1010 ]: ICE1712 - M Audio Delta 1010
M Audio Delta 1010 at 0xdf80, irq 21
1 [M1010_1 ]: ICE1712 - M Audio Delta 1010
M Audio Delta 1010 at 0xdf40, irq 20
If you have a motherboard that has an integrated sound chip, you might
find your zero device is not a Delta, which is a problem. I had to disable
my onboard sound card in my motherboard's BIOS settings.
- You have hw:0 and hw:1 identified correctly. Unfortunately, sometimes
Linux has an issue with being able to consistently identify 2 identical
soundcards. I've had this happen in the past and it gets annoying. I
found it most liable to happen if I've made some other hardware change
to the machine, otherwise it's usually stable across reboots. It's
easily tested by using hw:0 to start jack and verifying that it
addresses the ports on the card you believe to be hw:0.
Already done. They're both recognized and I know which hardware card
belongs to which device (always wondering after some time, so I check
that, first).
- You've got the right cards set as master clock and S/PDIF slave and that
the correct ports on each are connected. I've gotten this incorrect on
at least 2 occasions, so it's worth re-checking!
Already checked, now re-checked, it's ok.
- The 2 1010LT's are not sharing any IRQs
with other devices. "lsmod -v"
command will show you the IRQs of all the PCI devices. The Deltas should
have IRQs all to themselves. Here's my output edited to show just the
Deltas. IRQs 20 and 21 are not shared with any other device.
You mean "lspci -v". There seems to be a silly situation:
lspci -v | grep IRQ -B2 output(shortened to relevant IRQs):
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI
Controller #3 (rev 01)
Subsystem: Foxconn International, Inc. Device 0c7e
Flags: bus master, medium devsel, latency 0, IRQ 18
--
00:1f.2 IDE interface: Intel Corporation N10/ICH7 Family SATA IDE
Controller (rev 01) (prog-if 8f [Master SecP SecO PriP PriO])
Subsystem: Foxconn International, Inc. Device 0c7e
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 18
--
04:01.0 Multimedia audio controller: VIA Technologies Inc. ICE1712
[Envy24] PCI Multi-Channel I/O Controller (rev 02)
Subsystem: VIA Technologies Inc. Device d63b
Flags: bus master, medium devsel, latency 64, IRQ 22
--
04:05.0 Multimedia audio controller: VIA Technologies Inc. ICE1712
[Envy24] PCI Multi-Channel I/O Controller (rev 02)
Subsystem: VIA Technologies Inc. Device d63b
Flags: bus master, medium devsel, latency 64, IRQ 18
So...SATA, USB and ICE1712 share one interrupt.
How can I change the interrupt of the devices, except by moving them to
another slot? Though I'd really like to get rid of this, I can't
imagine, this is responsible for
Jack: JackGraphManager::AssertPort port_index = 4294967295
Looks like a dangling or uninitialized pointer to me.
02:09.0 Multimedia audio controller: VIA
Technologies Inc. ICE1712 [Envy24] PCI Multi-Channel I/O Controller (rev 02)
Subsystem: VIA Technologies Inc. M-Audio Delta 1010
Flags: bus master, medium devsel, latency 64, IRQ 21
I/O ports at df80 [size=32]
I/O ports at dfa0 [size=16]
I/O ports at df60 [size=16]
I/O ports at df00 [size=64]
Capabilities: <access denied>
Kernel driver in use: ICE1712
Kernel modules: snd-ice1712
02:0c.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 [Envy24] PCI
Multi-Channel I/O Controller (rev 02)
Subsystem: VIA Technologies Inc. M-Audio Delta 1010
Flags: bus master, medium devsel, latency 64, IRQ 20
I/O ports at df40 [size=32]
I/O ports at ded0 [size=16]
I/O ports at dec0 [size=16]
I/O ports at de80 [size=64]
Capabilities: <access denied>
Kernel driver in use: ICE1712
Kernel modules: snd-ice1712
If the hardware's setup is verified as OK, look at how you're starting
Jack. You didn't post the command used to start jack, so I can't say if
it's starting the way you expect. If you use QJackCtl to start jack,
the command that starts jack can be found by looking at the .jackdrc
file.
I normally use QJackCtl, except for debugging this. QJackCtl froze and I
wasn't able to read the output. The command normally is:
/usr/bin/jackd -P89 -v -dalsa -r48000 -p256 -n4 -m -D -Cmulti_capture
-Pmulti_playback
but other frames/period, Priority etc. settings don't help.
I tried the settings from your page but without success.
Hope this helps, or at least gives you a starting point for troubleshooting.
Oh
yes, I found the shared IRQs and I know for certain, it's possible to
use jack 1.9.7 with .asoundrc and two ICE1712.
Thank you!
/mn0
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
10:27 p.m.
No idea if this helps or not, but FWIW, I had two 1010's working in my
studio for years without problems. I blogged about how I got em' to work.
Link below:
http://www.ilovemyjournal.com/?action=view_entry&eid=4773
--Jason
www.advancedbudgetstudios.com
On Wed, Feb 1, 2012 at 2:24 PM, mn0 <mn0(a)fukked-up.de> wrote:
Just compiled jack1 but conflicts with jack2.
Won't checkinstall...
tried make install
and it installs but doesn't work -
undefined symbols.
Doesn't overwrite all libs, as it seems.
would have been good to test, if it's a jack2 specific problem.
/mn0
Am 01.02.2012 21:48, schrieb mn0:
identical
that
-v"
[Envy24]
PCI Multi-Channel I/O Controller (rev 02)
troubleshooting.
Am 01.02.2012 19:56, schrieb Joe Hartley:
Yep.
>> a)use .asoundrc
>> I have a .asoundrc from the web.
>> After a few seconds, it crashes saying this:
>>
>> Unknown request 4294967295
>> Destination port in attempted (dis)connection of system:monitor_6 and
>> system:monitor_6 is not an input port
>> Unknown request 4294967295
>> Unknown request 0
>> Unknown request 0
> [ snip ]
>
> Using the .asoundrc file to combine the cards into one logical device is
> what I consider to be the "correct" way of doing this, so I'll focus
on
> that. Assumptions I'm making here:
> - the Deltas are the only 2 sound devices in the system. This can be
> verified by the command "cat /proc/asound/cards". On my system, this
> is the output I see:
>
> [jh@xtc ~]$ cat /proc/asound/cards
> 0 [M1010 ]: ICE1712 - M Audio Delta 1010
> M Audio Delta 1010 at 0xdf80, irq 21
> 1 [M1010_1 ]: ICE1712 - M Audio Delta 1010
> M Audio Delta 1010 at 0xdf40, irq 20
>
> If you have a motherboard that has an integrated sound chip, you might
> find your zero device is not a Delta, which is a problem. I had to
disable
Hi, I've been using 2 Delta 1010s together
for a while, I hope I can
help a bit here. I've tried to put most of what I've learned on the
web at http://delta.brainiac.com/deltasync.html
On Tue, 31 Jan 2012 05:40:35 +0100 mn0 <mn0(a)fukked-up.de> wrote:
compiled jack 1.9.8 yesterday - didn't help. Now back on 1.9.7.
I use Jack2, where can I find the exact version?
Only thing I know, it's jackdmp 1.9.7.
That should be fine, it's what I use as well. The cards
are hardware synced via S-PDIF.
In envy24control, a mixer program that knows about these features, hw:0
is set to internal clock and hw:1 is set to S-PDIF.
So far, so good. I'll assume you're using a real S-PDIF cable and not
just an audio RCA cable. my
onboard sound card in my motherboard's BIOS settings.
Already is disabled.
>
> - You have hw:0 and hw:1 identified correctly. Unfortunately, sometimes
> Linux has an issue with being able to consistently identify 2
soundcards. I've had this happen in the past and it gets annoying. I
found it most liable to happen if I've made some other hardware change
to the machine, otherwise it's usually stable across reboots. It's
easily tested by using hw:0 to start jack and verifying that it
addresses the ports on the card you believe to be hw:0.
Already done. They're both recognized and I know which hardware card
belongs to which device (always wondering after some time, so I check
that, first).
>
> - You've got the right cards set as master clock and S/PDIF slave and > the correct ports on each are connected.
I've gotten this incorrect
on
at
least 2 occasions, so it's worth re-checking!
Already checked, now re-checked, it's ok.
> - The 2 1010LT's are not sharing any IRQs with other devices. "lsmod > command will show you the IRQs of all the
PCI devices. The Deltas
should
have
IRQs all to themselves. Here's my output edited to show just the
Deltas. IRQs 20 and 21 are not shared with any other device.
You mean "lspci -v". There seems to be a silly situation:
lspci -v | grep IRQ -B2 output(shortened to relevant IRQs):
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI
Controller #3 (rev 01)
Subsystem: Foxconn International, Inc. Device 0c7e
Flags: bus master, medium devsel, latency 0, IRQ 18
--
00:1f.2 IDE interface: Intel Corporation N10/ICH7 Family SATA IDE
Controller (rev 01) (prog-if 8f [Master SecP SecO PriP PriO])
Subsystem: Foxconn International, Inc. Device 0c7e
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 18
--
04:01.0 Multimedia audio controller: VIA Technologies Inc. ICE1712
[Envy24] PCI Multi-Channel I/O Controller (rev 02)
Subsystem: VIA Technologies Inc. Device d63b
Flags: bus master, medium devsel, latency 64, IRQ 22
--
04:05.0 Multimedia audio controller: VIA Technologies Inc. ICE1712
[Envy24] PCI Multi-Channel I/O Controller (rev 02)
Subsystem: VIA Technologies Inc. Device d63b
Flags: bus master, medium devsel, latency 64, IRQ 18
So...SATA, USB and ICE1712 share one interrupt.
How can I change the interrupt of the devices, except by moving them to
another slot? Though I'd really like to get rid of this, I can't
imagine, this is responsible for
Jack: JackGraphManager::AssertPort port_index = 4294967295
Looks like a dangling or uninitialized pointer to me.
> 02:09.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 > Subsystem: VIA Technologies Inc.
M-Audio Delta 1010
> Flags: bus master, medium devsel, latency 64, IRQ 21
> I/O ports at df80 [size=32]
> I/O ports at dfa0 [size=16]
> I/O ports at df60 [size=16]
> I/O ports at df00 [size=64]
> Capabilities: <access denied>
> Kernel driver in use: ICE1712
> Kernel modules: snd-ice1712
>
> 02:0c.0 Multimedia audio controller: VIA Technologies Inc. ICE1712
[Envy24]
PCI Multi-Channel I/O Controller (rev 02)
Subsystem: VIA Technologies Inc. M-Audio Delta 1010
Flags: bus master, medium devsel, latency 64, IRQ 20
I/O ports at df40 [size=32]
I/O ports at ded0 [size=16]
I/O ports at dec0 [size=16]
I/O ports at de80 [size=64]
Capabilities: <access denied>
Kernel driver in use: ICE1712
Kernel modules: snd-ice1712
If the hardware's setup is verified as OK, look at how you're starting
Jack. You didn't post the command used to start jack, so I can't say if
it's starting the way you expect. If you use QJackCtl to start jack,
the command that starts jack can be found by looking at the .jackdrc
file.
I normally use QJackCtl, except for debugging this. QJackCtl froze and I
wasn't able to read the output. The command normally is:
/usr/bin/jackd -P89 -v -dalsa -r48000 -p256 -n4 -m -D -Cmulti_capture
-Pmulti_playback
but other frames/period, Priority etc. settings don't help.
I tried the settings from your page but without success.
>
> Hope this helps, or at least gives you a starting point for Oh yes, I found the shared IRQs and I know for
certain, it's possible to
use jack 1.9.7 with .asoundrc and two ICE1712.
Thank you!
/mn0
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
10:32 p.m.
On Wed, Feb 1, 2012 at 4:24 PM, mn0 <mn0(a)fukked-up.de> wrote:
Just compiled jack1 but conflicts with jack2.
Won't checkinstall...
tried make install
and it installs but doesn't work -
undefined symbols.
Doesn't overwrite all libs, as it seems.
correct. you must clear out $libdir/libjack* and also $libdir/jack
before doing an "overlay" install.
10:46 p.m.
Am 01.02.2012 22:32, schrieb Paul Davis:
On Wed, Feb 1, 2012 at 4:24 PM, mn0
<mn0(a)fukked-up.de> wrote:
You mean by rm or by package manager (would remove tons of programs)?
Just compiled jack1 but conflicts with jack2.
Won't checkinstall...
tried make install
and it installs but doesn't work -
undefined symbols.
Doesn't overwrite all libs, as it seems.
correct. you must clear out $libdir/libjack* and also $libdir/jack
before doing an "overlay" install.
10:55 p.m.
On Wed, 01 Feb 2012 22:46:21 +0100
mn0 <mn0(a)fukked-up.de> wrote:
Am 01.02.2012 22:32, schrieb Paul Davis:
An rm would do it, but that still leaves the package manager thinking
that the package is still installed. There's likely to be an option
that will force the removal of a package without checking its
dependencies. I am not familiar enough with Ubuntu to say what it is,
though.
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
correct. you must clear out $libdir/libjack* and
also $libdir/jack
before doing an "overlay" install.
You mean by rm or by package manager (would remove tons of programs)? 
2 Feb
2 Feb
7:39 a.m.
2012/2/1 Joe Hartley <jh(a)brainiac.com>
On Wed, 01 Feb 2012 22:46:21 +0100
mn0 <mn0(a)fukked-up.de> wrote:
# aptitude purge <package-name>
-r
--
*L'unica speranza di catarsi, ammesso che ne esista una, resta affidata
all'istinto di ribellione, alla rivolta non isterilita in progetti, alla
protesta violenta e viscerale.*
Am 01.02.2012 22:32, schrieb Paul Davis:
correct. you must clear out $libdir/libjack* and
also $libdir/jack
before doing an "overlay" install.
You mean by rm or by package manager (would remove tons of programs)?
1 Feb
1 Feb
10:31 p.m.
On Wed, 01 Feb 2012 21:48:16 +0100
mn0 <mn0(a)fukked-up.de> wrote:
While I agree that the Jack: JackGraphManager::AssertPort error would seem
to be some sort of pointer issue, odd things happen when the hardware
configuration is less-than-stable. Sharing an IRQ with both a SATA and
a USB controller sets up a situation where I can odd things happening.
Changing slots is one wat of getting a different IRQ; your motherboard
may also have a way of setting or reserving IRQs in its BIOS. I recall
having to try a few different slots before the cards got unique IRQs.
I did some searching, and found that you're not the only one with a
similar issue. This user had different hardware but very similar
errors: http://ubuntuforums.org/showthread.php?t=1580566
One last thing to check, based on my searches - the AssertPort error
has been associated with some plugins. You haven't mentioned a client
program, so I'm not sure if jack dies before you can start one, or if
there's a correlation here. If the errors actually happen after you
start something like Ardour, I'd see what happens if you disable the
plugins. There are some that will absolutely hammer my system every
time I try to use them. They might be from the C* set, but I really
can't remember off the top of my head.
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
Hope this
helps, or at least gives you a starting point for troubleshooting.
Oh yes, I found
the shared IRQs and I know for certain, it's possible to
use jack 1.9.7 with .asoundrc and two ICE1712.
10:55 p.m.
Am 01.02.2012 22:31, schrieb Joe Hartley:
On Wed, 01 Feb 2012 21:48:16 +0100
mn0 <mn0(a)fukked-up.de> wrote:
While I agree that the Jack: JackGraphManager::AssertPort error would seem
to be some sort of pointer issue, odd things happen when the hardware
configuration is less-than-stable. Sharing an IRQ with both a SATA and
a USB controller sets up a situation where I can odd things happening.
Changing slots is one wat of getting a different IRQ; your motherboard
may also have a way of setting or reserving IRQs in its BIOS. I recall
having to try a few different slots before the cards got unique IRQs.
I did some searching, and found that you're not the only one with a
similar issue. This user had different hardware but very similar
errors: http://ubuntuforums.org/showthread.php?t=1580566
One last thing to check, based on my searches - the AssertPort error
has been associated with some plugins. You haven't mentioned a client
program, so I'm not sure if jack dies before you can start one, or if
there's a correlation here. If the errors actually happen after you
start something like Ardour, I'd see what happens if you disable the
plugins. There are some that will absolutely hammer my system every
time I try to use them. They might be from the C* set, but I really
can't remember off the top of my head.
I know others have similar problems but found none with a solution so
far. I have exactly this tab already opened.
It crashes without clients.
Will now try jack1, if it doesn't help change slots until I have IRQs
fixed. My BIOS allows to reserve IRQs I just don't understand how that's
supposed to work:
I can choose either "PCI" or "reserved" per IRQ-number.
So...what's happening if I reserve let's say #15 ?
Anyway I'd have to check out which device is hw:0 and hw:1 again etc.
That's why I'll test jack1 first.
/mn0
Hope this
helps, or at least gives you a starting point for troubleshooting.
Oh yes, I found
the shared IRQs and I know for certain, it's possible to
use jack 1.9.7 with .asoundrc and two ICE1712.
11:39 p.m.
Just to let you know, I moved the jack2 .sos somewhere safe and
installed jack1. Edited limits.conf.
Doesn't crash. I need a lot of samples/period to avoid xruns. Atm it
shows 0 but the number besides is growing steadily at about 10/second.
So I have 0(1500) xruns. What does the number mean?
I have 1500 xruns that are too short to count as a real one?
Anyway, I'll get my IRQs fixed, now.
/mn0
Am 01.02.2012 21:48, schrieb mn0:
Am 01.02.2012 19:56, schrieb Joe Hartley:
Yep.
Already is disabled.
Hi, I've been using 2 Delta 1010s together
for a while, I hope I can
help a bit here. I've tried to put most of what I've learned on the
web at http://delta.brainiac.com/deltasync.html
On Tue, 31 Jan 2012 05:40:35 +0100 mn0 <mn0(a)fukked-up.de> wrote:
compiled jack 1.9.8 yesterday - didn't help. Now back on 1.9.7.
I use Jack2, where can I find the exact version?
Only thing I know, it's jackdmp 1.9.7.
That should be fine, it's what I use as well. The cards
are hardware synced via S-PDIF.
In envy24control, a mixer program that knows about these features, hw:0
is set to internal clock and hw:1 is set to S-PDIF.
So far, so good. I'll assume you're using a real S-PDIF cable and not
just an audio RCA cable. a)use
.asoundrc
I have a .asoundrc from the web.
After a few seconds, it crashes saying this:
Unknown request 4294967295
Destination port in attempted (dis)connection of system:monitor_6 and
system:monitor_6 is not an input port
Unknown request 4294967295
Unknown request 0
Unknown request 0
[ snip ]
Using the .asoundrc file to combine the cards into one logical device is
what I consider to be the "correct" way of doing this, so I'll focus on
that. Assumptions I'm making here:
- the Deltas are the only 2 sound devices in the system. This can be
verified by the command "cat /proc/asound/cards". On my system, this
is the output I see:
[jh@xtc ~]$ cat /proc/asound/cards
0 [M1010 ]: ICE1712 - M Audio Delta 1010
M Audio Delta 1010 at 0xdf80, irq 21
1 [M1010_1 ]: ICE1712 - M Audio Delta 1010
M Audio Delta 1010 at 0xdf40, irq 20
If you have a motherboard that has an integrated sound chip, you might
find your zero device is not a Delta, which is a problem. I had to disable
my onboard sound card in my motherboard's BIOS settings.
- You have hw:0 and hw:1 identified correctly. Unfortunately, sometimes
Linux has an issue with being able to consistently identify 2 identical
soundcards. I've had this happen in the past and it gets annoying. I
found it most liable to happen if I've made some other hardware change
to the machine, otherwise it's usually stable across reboots. It's
easily tested by using hw:0 to start jack and verifying that it
addresses the ports on the card you believe to be hw:0.
Already done. They're both recognized and I know which hardware card
belongs to which device (always wondering after some time, so I check
that, first).
- You've got the right cards set as master clock and S/PDIF slave and that
the correct ports on each are connected. I've gotten this incorrect on
at least 2 occasions, so it's worth re-checking!
Already checked, now re-checked, it's ok.
- The 2 1010LT's are not sharing any IRQs
with other devices. "lsmod -v"
command will show you the IRQs of all the PCI devices. The Deltas should
have IRQs all to themselves. Here's my output edited to show just the
Deltas. IRQs 20 and 21 are not shared with any other device.
You mean "lspci -v". There seems to be a silly situation:
lspci -v | grep IRQ -B2 output(shortened to relevant IRQs):
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI
Controller #3 (rev 01)
Subsystem: Foxconn International, Inc. Device 0c7e
Flags: bus master, medium devsel, latency 0, IRQ 18
--
00:1f.2 IDE interface: Intel Corporation N10/ICH7 Family SATA IDE
Controller (rev 01) (prog-if 8f [Master SecP SecO PriP PriO])
Subsystem: Foxconn International, Inc. Device 0c7e
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 18
--
04:01.0 Multimedia audio controller: VIA Technologies Inc. ICE1712
[Envy24] PCI Multi-Channel I/O Controller (rev 02)
Subsystem: VIA Technologies Inc. Device d63b
Flags: bus master, medium devsel, latency 64, IRQ 22
--
04:05.0 Multimedia audio controller: VIA Technologies Inc. ICE1712
[Envy24] PCI Multi-Channel I/O Controller (rev 02)
Subsystem: VIA Technologies Inc. Device d63b
Flags: bus master, medium devsel, latency 64, IRQ 18
So...SATA, USB and ICE1712 share one interrupt.
How can I change the interrupt of the devices, except by moving them to
another slot? Though I'd really like to get rid of this, I can't
imagine, this is responsible for
Jack: JackGraphManager::AssertPort port_index = 4294967295
Looks like a dangling or uninitialized pointer to me.
02:09.0 Multimedia audio controller: VIA
Technologies Inc. ICE1712 [Envy24] PCI Multi-Channel I/O Controller (rev 02)
Subsystem: VIA Technologies Inc. M-Audio Delta 1010
Flags: bus master, medium devsel, latency 64, IRQ 21
I/O ports at df80 [size=32]
I/O ports at dfa0 [size=16]
I/O ports at df60 [size=16]
I/O ports at df00 [size=64]
Capabilities: <access denied>
Kernel driver in use: ICE1712
Kernel modules: snd-ice1712
02:0c.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 [Envy24] PCI
Multi-Channel I/O Controller (rev 02)
Subsystem: VIA Technologies Inc. M-Audio Delta 1010
Flags: bus master, medium devsel, latency 64, IRQ 20
I/O ports at df40 [size=32]
I/O ports at ded0 [size=16]
I/O ports at dec0 [size=16]
I/O ports at de80 [size=64]
Capabilities: <access denied>
Kernel driver in use: ICE1712
Kernel modules: snd-ice1712
If the hardware's setup is verified as OK, look at how you're starting
Jack. You didn't post the command used to start jack, so I can't say if
it's starting the way you expect. If you use QJackCtl to start jack,
the command that starts jack can be found by looking at the .jackdrc
file.
I normally use QJackCtl, except for debugging this. QJackCtl froze and I
wasn't able to read the output. The command normally is:
/usr/bin/jackd -P89 -v -dalsa -r48000 -p256 -n4 -m -D -Cmulti_capture
-Pmulti_playback
but other frames/period, Priority etc. settings don't help.
I tried the settings from your page but without success.
Hope this helps, or at least gives you a starting point for troubleshooting.
Oh
yes, I found the shared IRQs and I know for certain, it's possible to
use jack 1.9.7 with .asoundrc and two ICE1712.
Thank you!
/mn0
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
2 Feb
2 Feb
11:47 p.m.
New subject: Multiple ICE1712 cards setup with jack2 -> get rid of xruns
As we know now, the shared IRQs were not causing the xruns.
Just to make sure, everyone's up to date:
-using 2 Delta 1010s together.
-Core2duo E4500
-Ubuntustudio 10.04
-kxstudio repos
-jackdmp 1.9.9. from svn
-The cards are hardware synced via S-PDIF.
In envy24control, a mixer program that knows about these features, hw:0
is set to internal clock and hw:1 is set to S-PDIF.
-using a real S-PDIF cable and not
just an audio RCA cable.
-use .asoundrc.
-cat /proc/asound/cards finds both.
-onboard sound card disabled.
-I know which device represents which hardware card. Thus S-PDIF
direction is correct (re-checked 5 min ago).
-use QJackCtl: /usr/bin/jackd -P89 -v -dalsa -r48000 -p256 -n4 -m -D
-Cmulti_capture -Pmulti_playback
-other frames/period, Priority etc. settings don't help.
-tried on 2.6.33.xx-realtime and 2.6.31.yy-rt kernels.
-in QjackCtl xruns=x(y);
y is growing rapidly (~300/gui update).
I found out, that y represents the xruns reported by jack api, while x
is scraped from the logs. So y are real xruns.
-jack is running with rt priority.
-in limits.conf audio group has unlimited memory, is -20 nice and has 89
rtprio.
interesting side effect:
on 2.6.32-27-generic, the xruns don't occur so often.
with-p512 there's even no xruns.
What's going on there?
Kernel issue?
-p512 is a little too much latency.
Why is a generic kernel xrunning less than a realtime or rt?
jack 1.9.9 compatibility issue?
/mn0
3 Feb
3 Feb
1:43 a.m.
New subject: Multiple ICE1712 cards setup with jack2 -> get rid of xruns
Am 02.02.2012 23:47, schrieb mn0:
As we know now, the shared IRQs were not causing the
xruns.
Just to make sure, everyone's up to date:
-using 2 Delta 1010s together.
-Core2duo E4500
-Ubuntustudio 10.04
-kxstudio repos
-jackdmp 1.9.9. from svn
-The cards are hardware synced via S-PDIF.
In envy24control, a mixer program that knows about these features, hw:0
is set to internal clock and hw:1 is set to S-PDIF.
-using a real S-PDIF cable and not
just an audio RCA cable.
-use .asoundrc.
-cat /proc/asound/cards finds both.
-onboard sound card disabled.
-I know which device represents which hardware card. Thus S-PDIF
direction is correct (re-checked 5 min ago).
-use QJackCtl: /usr/bin/jackd -P89 -v -dalsa -r48000 -p256 -n4 -m -D
-Cmulti_capture -Pmulti_playback
-other frames/period, Priority etc. settings don't help.
-tried on 2.6.33.xx-realtime and 2.6.31.yy-rt kernels.
-in QjackCtl xruns=x(y);
y is growing rapidly (~300/gui update).
I found out, that y represents the xruns reported by jack api, while x
is scraped from the logs. So y are real xruns.
-jack is running with rt priority.
-in limits.conf audio group has unlimited memory, is -20 nice and has 89
rtprio.
interesting side effect:
on 2.6.32-27-generic, the xruns don't occur so often.
with-p512 there's even no xruns.
What's going on there?
Kernel issue?
-p512 is a little too much latency.
Why is a generic kernel xrunning less than a realtime or rt?
jack 1.9.9 compatibility issue?
/mn0
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
Just in case you want to know, how I fixed it...
Thought, maybe kernels from the early stone age are bad...
installed 2.6.38 lowlatency.
Didn't help...
but when attempting to start jack, it complained a certain pid was using
the soundcard.
ps alx said it was - guess what - pulseaudio...
created ~/.pulse/client.conf with the following content:
autospawn = no
pulseaudio -k
start jack
smile.
Now running without xruns at
/usr/bin/jackd -P89 -v -dalsa -r48000 -p128 -n4 -m -D
-Cmulti_capture -Pmulti_playback
and very few on -n3
So I'm sorry for making such a noise on the list and happy it's now
working as supposed to.
/mn0
3:49 a.m.
New subject: Multiple ICE1712 cards setup with jack2 -> get rid of xruns
On Fri, 03 Feb 2012 01:43:31 +0100
mn0 <mn0(a)fukked-up.de> wrote:
but when attempting to start jack, it complained a
certain pid was using
the soundcard.
ps alx said it was - guess what - pulseaudio...
It was only because I have spent a lot of time in a naval town that I
have the vocabulary to say how very much I hate pulseaudio.
Even though I've been a big fan of the Fedora/PlanetCCRMA work over
the years, I ended up moving to ArchLinux to get away from the deep
embedding of PU.. I mean PA into Fedora.
I'm really happy to hear that it got solved, and even though the
IRQ conflict wasn't the big problem, your system's ultimately going
to be even more stable with the Deltas on their own IRQs.
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
8:31 p.m.
New subject: Multiple ICE1712 cards setup with jack2 -> get rid of xruns
but when
attempting to start jack, it complained a certain pid was using
the soundcard.
ps alx said it was - guess what - pulseaudio...
It was only because I have spent a lot of time in a naval town that I
have the vocabulary to say how very much I hate pulseaudio.
10:06 p.m.
New subject: Multiple ICE1712 cards setup with jack2 -> get rid of xruns
Am 03.02.2012 20:29, schrieb fred:
OTOH, maybe you could try
http://www.rncbc.org/jack/rtirq-20111007.tar.gz
I'll check that out
You're supposed, AFAIK, to have something like the
highest priority is the
RT clock, then the hardware, then ALSA, than Jack, then Ardour.
As you may have noticed, I have no clue how things are supposed to work,
regarding linux audio, so that's valuable info.
Am 03.02.2012 03:49, schrieb Joe Hartley:
your system's ultimately going
to be even more stable with the Deltas on their own IRQs.
I hope so, too. I'm
glad I got them fixed. And though interrupts are
quick, there's heavy use of soundcard and hdd while recording 16 track.
/mn0
4474
days inactive
4477
days old
linux-audio-user@lists.linuxaudio.org
16 comments
6 participants
participants (6)
-
fred -
Jason Jones -
Joe Hartley -
mn0 -
Paul Davis -
Raffaele Morelli