7 Mar
2015
7 Mar
'15
8 p.m.
On Sat, 7 Mar 2015 17:46:12 +0000
Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Sat, Mar 07, 2015 at 05:18:41PM +0000, Will Godfrey
wrote:
That was fast :)
Thanks for the info. Just tried the examples. They certainly seem to be
lightweight.
... they also proved that I was 'doing it wrong' and a KA6 USB card is
accessible!
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
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,