[RFC] hdsp plans and alsa integration

[RFC] hdsp plans and alsa integration

[Thomas Charbonnel]

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.
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). 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.

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 ?
Any comment on this is welcome.

Thomas




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: [RFC] hdsp plans and alsa integration

[Takashi Iwai]

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