[LAD] ALSA frustration

Fons Adriaensen fons at linuxaudio.org
Tue Apr 22 12:29:07 UTC 2014

On Tue, Apr 22, 2014 at 09:57:20AM +0200, Clemens Ladisch wrote:
> Fons Adriaensen wrote:
> > In this case my very humble endeavour was just
> > to find out if or not it would be possible to
> > create something similar to the alsa_jack plugin
> > that would actually present itself as a sound
> > card, so that (badly written) apps would be
> > prepared to use it.
> In theory, plugins like alsa_jack already _are_
> presented as a sound card.  (From alsa-lib's point
> of view, there is not difference between the hw and
> the alsa_jack plugins.)

There is some difference. Snd_aloop is listed by e.g. 
aplay -l, while the alsa-jack plugin isn't. 

If, as you say, there is no difference between the two
from alsa-lib's POV, it should be possible to make the
alsa-jack plugin appear as being a real soundcard, even
if all the data transfer happens in user space. Maybe
be creating some dummy device nodes and a dummy driver
using them, and associating those with the plugin. Or
alsa-lib faking whatever is required to make an app
believe it's talking to a sound card. Since the ALSA
API hides the hardware from the apps, that should in
fact be simple. 

In fact there would be no reason at all why two types
of interface should exist at all.
> If your badly written apps insist on using a hardware
> card (i.e., on the hw plugin), then you need to have
> an actual kernel driver for that card.  There is the
> loopback driver, snd-aloop, but you'd need to write
> a tool that bridges that to Jack.

Which can be done with e.g. zita-ajbridge. But that 
involves an adaptive resampling step which shouldn't be
there at all. It is necessary only because the aloop 
device imposes its own period timing to both endpoints.

What would be required is something like snd_aloop but
having an assymetrical interface: one end being presented
as a sound card, while the other could be a pair of fifos,
a socket, or whatever. The key difference would be that the
period timing as seen at the sound card end is determined
by the number of frames read or written by the other end 
instead of by a timer. Which means that no resampling (or
optionally only a fixed-rate one) is required.


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)

More information about the Linux-audio-dev mailing list