Re: [OT] ALSA userspace API complexity

Tomasz Kłoczko
2006-01-05T23:44:02Z

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2653 bytes --]

On Thu, 5 Jan 2006, Joern Nettingsmeier wrote:
[..]
> i look forward to hearing back from you, in, oh, 2015 or so?

Now we have 2006. Four years ALSA is in kernel tree.
2015 - 2006 = 9
4 < 9

Four years ago noone predisct some "temporary sound devices" like BT
headests in ALSA architecture (bt-sco was developed in 2002 and still
isn't merged in ALSA tree .. probably because module in current form can't
provide simple usage like "just plug and play").
This is not matter of any kind prediction because on market four
years ago was avalaible some "temporary sound devices". BT headsets
are real and still IIRC there is no way in current ALSA architecture point
where and how this must plugged.
Why ? Because most of soud stream routing are performed in user space
library abstraction. For handle this in current ALSA model you must
prepare EACH application for reciveing signals about for examaple
changing default soud device (for perform close old and open new). In ALSA
there is no layer where this kind of redirections can be managed outside
ALL applications in common and easy way for non-root users

Q: why Linux can't behive as it will have allways soud device with dummy
device plugged to /dev/null (if only soudcode is loaded) if there is no
soud hardware in system ? Look .. if you have loaded event module you have
virtual kbd and mouse .. but real kbd/mouse can be used only afrer load
keyboard/mouse modules.

Instead try to manage any kind of (even future) devices it will be good if
ALSA will be ready for manage only current "sound model devices" (like
mono, stereo, 5.1, 7.1 with simple way for extending set of this profiles)
but with *moved all sound routing* to kernel space with well defined
ioctl() or netlink (like in ipfilter) API for manage all configuration
details (for allow prepare for example cute GUI aplication for manage all
this for joe users). In this way also will be possible prepare some kernel
level interface for plugging additional modules (or loading external DSO
modules like in ipfilter for interract with with hardware in any other
way. Apply ipfilter way to soud subsystem can be also used for plugging
filters ..

So .. stop talking about future and start about preset problems. ALSA have
many problems with current devices (on soud subsystem *architecture level*)

kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*