7 Mar
2015
7 Mar
'15
6:18 p.m.
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?
--
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.
7 Mar
7 Mar
6:46 p.m.
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)
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,
8:28 p.m.
On Sat, Mar 07, 2015 at 07:01:16PM +0000, Will Godfrey wrote:
Just let me know if you need more info on the API.
In general, anyhing that works with Jack via ALSA should
work with alsa-pcmi as well, if not I will fix it.
--
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)
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.
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!
3545
days inactive
3545
days old
linux-audio-dev@lists.linuxaudio.org
3 comments
2 participants
participants (2)
-
Fons Adriaensen -
Will Godfrey