On Sat, Mar 07, 2015 at 05:18:41PM +0000, Will Godfrey wrote: > I've just been reading the ALSA Programming HOWTO by Matthias Nagorni and one > detail caught my attention immediately. This is the idea of using plughw > instead > of directly addressing your soundcard. > > On the face of it this seems *much* easier, but there surely must be a catch. > Can anyone explain what the downside of doing this might be?
That HOWTO must be at least ten years old now. It is not 'much easier', the API is the still the same. The difference is that the plug layer will try to hide the real configuration space of your HW, allowing you to use almost any combination of sample rate, sample format, period size, etc. The downside is that you have no control over what is really happening. It also seems to interfere with the strict timing that low-latency period-synchronous systems such as Jack more or less require. In theory it should be possible to stack or combine the various ALSA 'plugins' in arbitrary ways. In practice most combinations do not work very well or at all. IMHO this part of ALSA is a failure. If the ALSA API seems too much too handle, use a library such as zita-alsa-pcmi to take care of the complexity, and use it with a hw: device, not a plughw: one. All my apps that provide access to ALSA directly (rather than via Jack) use it - it replaces around a thousand lines of code in each of them and provides a very easy to use interface. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
