Thread: [Alsa-user] Need help with Delta44 + on-board multi setup
Brought to you by:
perex
|
From: Eric <ef...@ya...> - 2007-02-22 23:43:55
|
Hello,
I am trying to figure out how to create an .asoundrc that will allow me to use Jack in the following manner:
Use my Delta44 (ice1712) card as the primary capture/playback device. Use my on-board Intel 82801 (AudioPCI ?) as a secondary playback device, both of which I want to access through qjackctl at the same time.
I have tried many of the suggested methods using alsa "multi" but without any luck.
I am having a difficult time understanding how to properly do this.
jackd -d alsa -d playback
jackd 0.102.20
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
loading driver ..
creating alsa driver ... playback|playback|1024|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames, buffer = 2 periods
ALSA: no playback configurations available (Invalid argument)
ALSA: cannot configure capture channel
cannot load driver module alsa
no message buffer overruns
Here is some of my setup...
pcm.multi
{
type multi;
slaves.a.pcm "hw:0";
slaves.a.channels 10;
slaves.b.pcm "hw:1";
slaves.b.channels 2;
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
bindings.8.slave a;
bindings.8.channel 8
bindings.9.slave a;
bindings.9.channel 9
bindings.10.slave b;
bindings.10.channel 0;
bindings.11.slave b;
bindings.11.channel 1;
}
ctl.multi
{
type hw;
card 0;
}
pcm.playback
{
type route;
slave.pcm "multi";
ttable.0.0 1;
ttable.1.1 1;
ttable.2.2 1;
ttable.3.3 1;
ttable.4.4 1;
ttable.5.5 1;
ttable.6.6 1;
ttable.7.7 1;
ttable.8.8 1;
ttable.9.9 1;
ttable.10.10 1;
ttable.11.11 1;
}
ctl.playback
{
type hw;
card 0;
}
0 [M44 ]: ICE1712 - M Audio Delta 44
M Audio Delta 44 at 0x14c0, irq 18
1 [I82801AAICH ]: ICH - Intel 82801AA-ICH
Intel 82801AA-ICH with AD1885 at 0x2000, irq 19
2 [UM2 ]: USB-Audio - UM-2
EDIROL UM-2 at usb-0000:00:1f.2-2, full speed
2: : timer
3: : sequencer
4: [ 0- 0]: digital audio playback
5: [ 0- 0]: digital audio capture
6: [ 0] : control
7: [ 2- 0]: raw midi
8: [ 2] : control
9: [ 1- 1]: digital audio capture
10: [ 1- 0]: digital audio playback
11: [ 1- 0]: digital audio capture
12: [ 1] : control
00-00: ICE1712 multi : ICE1712 multi : playback 1 : capture 1
01-01: Intel ICH - MIC ADC : Intel 82801AA-ICH - MIC ADC : capture 1
01-00: Intel ICH : Intel 82801AA-ICH : playback 1 : capture 1
---------------------------------
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. |
|
From: Lee R. <rlr...@jo...> - 2007-02-23 00:32:03
|
On 2/22/07, Eric <ef...@ya...> wrote: > Hello, > > I am trying to figure out how to create an .asoundrc that will allow me to > use Jack in the following manner: > > Use my Delta44 (ice1712) card as the primary capture/playback device. Use my > on-board Intel 82801 (AudioPCI ?) as a secondary playback device, both of > which I want to access through qjackctl at the same time. Not really possible - the cards will drift out of sync. > > I have tried many of the suggested methods using alsa "multi" but without > any luck. > > I am having a difficult time understanding how to properly do this. > > jackd -d alsa -d playback Try "-P playback" rather than "-D playback". But even if you get jack to run, it will not work well - you will get xruns due to the lack of hardware sync between the cards. Lee |
|
From: Bill U. <un...@ph...> - 2007-02-23 00:43:55
|
On Thu, 22 Feb 2007, Lee Revell wrote: > On 2/22/07, Eric <ef...@ya...> wrote: >> Hello, >> >> I am trying to figure out how to create an .asoundrc that will allow me to >> use Jack in the following manner: >> >> Use my Delta44 (ice1712) card as the primary capture/playback device. Use my >> on-board Intel 82801 (AudioPCI ?) as a secondary playback device, both of >> which I want to access through qjackctl at the same time. > > Not really possible - the cards will drift out of sync. Just to clarify, the crystal oscillators on the different cards to not run at the same rate. Thus say one runs at 44100 and the other at 44050. That means every second, the one card will bring in 50 fewer samples than the other one. If you remove enough samples to flush the second buffer, the first will have 50 left in it at the end of the first second, 100 the second, etc. If you try to remove enough samples to flush the first, the second buffer will not have enough samples in it to deliver to you. > >> >> I have tried many of the suggested methods using alsa "multi" but without >> any luck. >> >> I am having a difficult time understanding how to properly do this. >> >> jackd -d alsa -d playback > > Try "-P playback" rather than "-D playback". But even if you get jack > to run, it will not work well - you will get xruns due to the lack of > hardware sync between the cards. You have to either run both cards off the same crystal or select your cards really really well so that not only the crystal rates are identical but the variation with temperature, voltage, etc are identical as well. Now you can apparently buy cards such that the first holds, but I suspect since you talk about your onboard card as a backup, you also want to do this cheaply. |
|
From: Chris S. <ch...@sa...> - 2007-02-23 06:31:41
|
I have an Echo Audio MiaMIDI as well as an onboard card and I also want to be able to run both cards at the same time with jack. How do you set the cards to both run off the same crystal? Thanks -- Chris Stranex rm-rf |
|
From: Jamie L. <ja...@sh...> - 2007-02-23 11:09:24
|
Bill Unruh wrote: > Just to clarify, the crystal oscillators on the different cards to not run > at the same rate. Thus say one runs at 44100 and the other at 44050. That > means every second, the one card will bring in 50 fewer samples than the > other one. If you remove enough samples to flush the second buffer, the > first will have 50 left in it at the end of the first second, 100 the > second, etc. If you try to remove enough samples to flush the first, the > second buffer will not have enough samples in it to deliver to you. Is there no mechanism in ALSA for correcting drift, either between devices, or against a global clock? Video software has to correct for drift between the video and audio outputs, naturally. So such algorithms exist. It would be possible for a program to output to two ALSA devices, keeping the outputs somewhat synchronised by adjusting samples in one or both outputs. It might be useful, I'm not sure, to have an ALSA module do that, so programs can assume the sample rates of different devices are locked, or lock a rate to a global clock (e.g. the NTP synchronised system clock). The module might have better access to timing measurements for more accurate synchronisation. -- Jamie |