Re: [LAD] ALSA frustration

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.

-- 
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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev