Re: [OT] ALSA userspace API complexity

From: Tomasz Kłoczko
Date: Thu Jan 05 2006 - 18:42:56 EST


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@xxxxxxxxxxxxxxxxxx*