21 Apr
2014
21 Apr
'14
9:44 p.m.
For the N-th time I've set aside a day to try and read
some of the ALSA documentation. For the N-th time I've
completely lost my way in a web consisting of
* The complete lack of any documentation that
explains the concepts, the big picture, and
the terminology.
* Completely useless docs, of the form:
function xxx_set_yyy (parm_zzz)
sets the yyy of xxx to zzz.
or similar, in other words something generated
automagically and completely uninformative and
redundant. In particalur if it's impossible to
find out what yyy is supposed to be or do in
the first place.
* Uncomprehensible English.
* When trying to learn something from actual
source code or examples, layer upon layer of
syntactic sugar making it virtually impossible
to understand what's going on.
All this more than ten years after ALSA was
announced. I *do* understand those hardware
manufactureres who just refuse to try and
write an ALSA driver.
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.
If someone knows the answer to that question
and can also explain it I'll commend him/her
in my prayers.
--
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)
21 Apr
21 Apr
10:59 p.m.
On Mon, Apr 21, 2014 at 3:44 PM, Fons Adriaensen <fons(a)linuxaudio.org>wrote;wrote:
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.
This is what PulseAudio does, and its code should probably be considered
canonical for this purpose.
22 Apr
22 Apr
12:32 a.m.
On 4/21/2014 4:59 PM, Paul Davis wrote:
On Mon, Apr 21, 2014 at 3:44 PM, Fons Adriaensen <fons(a)linuxaudio.org
<mailto:fons@linuxaudio.org>> wrote:
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.
This is what PulseAudio does, and its code should probably be considered
canonical for this purpose.
And it does it quite well.
9:57 a.m.
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.)
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.
Regards,
Clemens
2:29 p.m.
On Tue, Apr 22, 2014 at 09:57:20AM +0200, Clemens Ladisch wrote:
Fons Adriaensen 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.
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.) 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)
12:03 p.m.
On Tue, April 22, 2014 5:44 am, Fons Adriaensen wrote:
For the N-th time I've set aside a day to try and
read
some of the ALSA documentation. For the N-th time I've
completely lost my way in a web consisting of
* The complete lack of any documentation that
explains the concepts, the big picture, and
the terminology.
* Completely useless docs, of the form:
function xxx_set_yyy (parm_zzz)
sets the yyy of xxx to zzz.
or similar, in other words something generated
automagically and completely uninformative and
redundant. In particalur if it's impossible to
find out what yyy is supposed to be or do in
the first place.
* Uncomprehensible English.
* When trying to learn something from actual
source code or examples, layer upon layer of
syntactic sugar making it virtually impossible
to understand what's going on.
Cleaning up this stuff would make a good project for some students to get
involved with. I wonder if there are any university professors who could
organise such a project?
Otherwise we (LAD) could pitch it to SUSE/Ubuntu/redhat/etc... or the
Linux Foundation as something that needs some funding support.
All this more than ten years after ALSA was
announced. I *do* understand those hardware
manufactureres who just refuse to try and
write an ALSA driver.
Alsa-devel is a very heavy traffic list. There are a lot of companies
providing support but they seem to be mostly mobile chipset drivers.
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.
If someone knows the answer to that question
and can also explain it I'll commend him/her
in my prayers.
--
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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
Patrick Shirkey
Boost Hardware Ltd
3650
days inactive
3651
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
5 participants
participants (5)
-
Clemens Ladisch -
David Santamauro -
Fons Adriaensen -
Patrick Shirkey -
Paul Davis