[LAU] performance tradeoffs of using ALSA dshare plugin for "envy24" soundcards?

Assuming one just wants to route audio output directly to external
mixers or soundsystems, are there any performance advantages, or
disadvantages, to using ALSA's "dshare" plugin to treat multichannel
soundcards as a bunch of individual devices. See ~/.asoundrc (
http://nielsmayer.com/npm/ice1724-dshare-asoundrc.txt ) below which
creates five stereo alsa "devices" from a single Delta 66: 66ch12
66ch34 66ch56 66ch78 66spdif .

What is the processing load and latency-implications of such a setup,
versus the jack-equivalent (which is certainly more convenient for
patching different connections together, as well as setting up
connections not supported by the 1-to-1 alsa style connections)?

I just set this up and was playing around with it on a Delta-66, where
the ice1724 soundchips' digital mixer allows the various ALSA outputs
to be mixed directly and then sent to "mains" output that's been
patched over to the digital mixer in "envy24control". In a way,
envy24control is a substitute for jack that uses the soundcard's DSP
as digital mixer and patchbay. Wouldn't such a setup give fractionally
lower latencies for, say, monitoring a vocalist or performer, over the
jack equivalent? (more importantly, w/o jackd runninng, it's one less
thing that has to "work in realtime" allowing your softsynths and
samplers to "carburate freely" and/or each hog their own CPU.) leaving
the ice1712 to render the results w/o further intervention....

The downside is that "dshare plugin" and its "buffer_size 256 //
period_size 128" is now having the kernel copy bits, instead of jack.
Is that a good or a bad thing if you're looking for audio performance
in realtime? Does this mean formerly you could get away with just
jackd running with realtime priority? ; whereas you'd need a realtime
kernel to do the "dshare" trick reliably??

...........................
##
## Useful suggestion from
http://alsa.opensrc.org/index.php/1712_.asoundrc#2005-09-18 allowing
## M66 card to be accessed as separate devices. using dshare plugin
## ( http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html#pcm_plugins_dshare
)
## PCMOUT1&2: gst123 -a alsa=66ch12 http://64.12.61.1:80/stream/1046
## PCMOUT3&4: gst123 -a alsa=66ch34 http://64.12.61.1:80/stream/1046
## PCMOUT5&6: gst123 -a alsa=66ch56 http://64.12.61.1:80/stream/1046
## PCMOUT7&8: gst123 -a alsa=66ch78 http://64.12.61.1:80/stream/1046
## SPDIFOUT : gst123 -a alsa=66spdif http://64.12.61.1:80/stream/1046
##
pcm_slave.66_slave {
    pcm "hw:M66,0"
    channels 10
    rate 44100
    buffer_size 256
    period_size 128
}

pcm.66ch12_dshare {
    type dshare
    ipc_key 18273645
    slave 66_slave
    bindings.0 0
    bindings.1 1
}

pcm.66ch12 {
    type plug
    slave.pcm "66ch12_dshare"
}

pcm.66ch34_dshare {
    type dshare
    ipc_key 18273645
    slave 66_slave
    bindings.0 2
    bindings.1 3
}

pcm.66ch34 {
    type plug
    slave.pcm "66ch34_dshare"
}

pcm.66ch56_dshare {
    type dshare
    ipc_key 18273645
    slave 66_slave
    bindings.0 4
    bindings.1 5
}

pcm.66ch56 {
    type plug
    slave.pcm "66ch56_dshare"
}

pcm.66ch78_dshare {
    type dshare
    ipc_key 18273645
    slave 66_slave
    bindings.0 6
    bindings.1 7
}

pcm.66ch78 {
    type plug
    slave.pcm "66ch78_dshare"
}

pcm.66spdif_dshare {
    type dshare
    ipc_key 18273645
    slave 66_slave
    bindings.0 8
    bindings.1 9
}

pcm.66spdif {
    type plug
    slave.pcm "66spdif_dshare"
}
...........................

Niels
http://nielsmayer.com
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Mon Jul 12 00:15:03 2010