Ardour + "el-cheapo" multichannel Soundcards

Getting Stuff Done How do I .... ?
#1

Hi all,

first of all: Many thanks to Paul for this -absolutely- great piece of Software :slight_smile:

I´m currently set-up the so called “el-cheapo” multitrack device using Alsa and Jackd using five SB128 (module ens-1371) under SL 10.0 with the Jacklab-RT-Kernel and mmap_access patched and manually compiled 0.100.7). It works, but i only hear the “merged” output signal when input monitoring is active (even the Ladspa-Plugins work in “realtime”). Internal signal routing inside Ardour between the input channels and master out doesn´t work. The master channel gets only active, when i choose a “direct” ALSA input for the master channel.

So my question goes to there, where the difference is between “input monitoring” / even active Ladspa Plugins within Ardour and the routing between channel-out/Master in (i see no activity within the Peak-Meter of the Master channel). I know that Paul said that this sort of multichannel device doesn´t work, but i´d like to know why. As the Inet says, do RME Hammerfalls and Delta1010´s work with this method and even the input monitoring works for -me-. The Ladspa Plugins also know to handle the streams in realtime and even Ardour show its activity on the channel peak-meters, so i ask myself, why it won´t work, when Input monitoring is inactive (playback while recording won´t also work, even with -D in jackd). When i record then all inputs simultaneously, Ardour captures all channels without problems, but without realtime output to the playback/output device.

I use the following command to start Jackd (where hw:1-4 is used for capture, hw:0 is playback):

jackd -R -v -dalsa -Cmulti -Phw:0 -r44100 -p1024

.asoundrc:

pcm.multi {
type multi
slaves.a.pcm hw:1
slaves.a.channels 2
slaves.b.pcm hw:2
slaves.b.channels 2
slaves.c.pcm hw:3
slaves.c.channels 2
slaves.d.pcm hw:4
slaves.d.channels 2

    bindings.0.slave a
    bindings.0.channel 0
    bindings.1.slave a
    bindings.1.channel 1
    bindings.2.slave b
    bindings.2.channel 0
    bindings.3.slave b
    bindings.3.channel 1
    bindings.4.slave c
    bindings.4.channel 0
    bindings.5.slave c
    bindings.5.channel 1
    bindings.6.slave d
    bindings.6.channel 0
    bindings.7.slave d
    bindings.7.channel 1

}

ctl.multi {
type hw
card 1
}

Interleave capture channels

pcm.ttable {
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
}

ctl.ttable {
type hw
card 1
}

Using a .asoundrc-“playback” device, even the usage of the “ttable”-device doesn´t work, Jackd will come up with messages “cannot configure hardware device blahblah for capture / playback”…

Many thanks for your help :slight_smile:

Greetings

Stef

#2

Problem solved, Hardware monitoring was active. Works through software monitoring without problems :slight_smile:

Greetings + many thanks!

Stef

#3

I’ve often wondered similar things… The real problem is clock-drift.

Also many (not all) consumer level cards are either a) noisy b) poor latency or c) have bad hardware mixers.

I tried (and for a short time only) getting a SB Audigy2 (snd-sblive) and some projects to allow for programming the DSP and making routes for more than two inputs. ARG, not easy and poor overall “experience”.

I upgraded to a M-Audio Delta 1010LT and boy, what an improvement. I actually think/thought it is/was more stable at 96kHz, however I updated the system and it works solid at 48kHz (looped a multi-channel [4-tracks] passage @ 128 frames/period w/ 3 periods/buffer [48Khz 24bits], for approximately 10 hours and no xruns under recent Ardour2 and Jack – that is really low latency and peaked load percent of ~6.5%). Can get away with 64 frames/period, but the system is more sensitive to background hickups, get occational xruns.

In the long run, any of the sound cards with word clock should be concidered more solid.

Also word-clocking and slaving these cards together means no clock-drift! I’ve been interested in how to do that (or if anybody has).

I would love to have some automated way of stress testing the sound hardware and then the disk I/O as a tool companion for Ardour. Always trying to find the best balance (can get in some setups, under 1ms latency).

–Doug