Re: [OT] ALSA userspace API complexity

["Tomasz Kłoczko" <kloczek@rudy.mif.pg.gda.pl>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2604 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*