Re: [RFC] hdsp plans and alsa integration

[Takashi Iwai <tiwai@suse.de>]

Hi Thomas,

again sorry for the late comments...

At Mon, 09 Feb 2004 12:58:04 +0100,
Thomas Charbonnel wrote:
> 
> Hi,
> 
> I've been thinking for some time now about allowing several applications 
> to access the hsdp matrix mixer in a cooperative way. Basically I want 
> several applications to share the current state of the matrix mixer and 
> be aware of the changes being made to it.
> The problem at the moment is that hdspmixer does not directly reflects 
> the hardware because it adds a software attenuation stage on the 
> physical outputs (the third row of faders). Any change on this row is 
> interpreted tracking back all the signals routed to the specified 
> output, applying the proper attenuation and converting this to standard 
> mixer calls. This renders the alsa ctl callback mechanism useless, 
> because if another application accesses the mixer ctl, hdspmixer will 
> have no way to interpret it properly.

well, we have now the matrix-style representation of mixer elements in
the alsa-driver, too.  can hdsp driver follow this way?
if it works, the problem of sharing the same data over control API
could be solved.

> I first thought of implementing the output attenuation stage directly in 
> the driver but I now believe it would be a very bad idea to do this in 
> kernel space (heavy computation, particularly with the new hdsp madi 
> cards).

ok, this is a different problem.  too much computation shouldn't be in
the kernel space.
instead, the 1:1 conversion of a value can be done in the application
itself, or do it in alsa-lib.

>  So I came up with the idea of writing a userspace daemon that 
> will access the card's mixer and be the keeper of this extended mixer 
> representation. I would also write a library to handle communication 
> with the daemon, and provide a callback mechanism to warn all the 
> clients of changes made to the extended mixer. The daemon could be 
> controled also from the network, which would make the whole system very 
> flexible. You could have hdspmixer running on a machine without any hdsp 
> hardware, controling the mixer of different hdsp cards on different 
> other machines on the network. You could easily control the mixer from a 
> pd patch, or a ladspa plugin, or ardour through an enhanced set of jack 
> monitoring calls. A nice point would also be to have the daemon provide 
> an optional ramping mechanism on mixer changes to avoid zipper noises 
> and make it usable in live mixing situations.

the idea using daemon looks fine for me, although i think it's
possible to implement without daemon.  but if the daemon makes your
life easier, i don't object.

> Now my question is does that fit within the scope of alsa ? Mabe the lib 
> could be integrated to alsa-lib and the daemon to alsa-tools ?

hmm, it's a good question.
if the API follows the standard ALSA API style, i.e. the daemon API
wraps the control/mixer API, we can implement it as a part of
alsa-lib.  if it becomes different, no big reason to include it in
alsa-lib, IMO.

putting the stuff into alsa-tools is no problem at all, though.
it's regarded as the place to contain card-specific applications.


Takashi


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click