On Tue, Apr 22, 2014 at 09:57:20AM +0200, Clemens Ladisch wrote:
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
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)
Linux-audio-dev mailing list