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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
