* Re: [RFC] hdsp plans and alsa integration
2004-02-09 11:58 [RFC] hdsp plans and alsa integration Thomas Charbonnel
@ 2004-02-17 15:48 ` Takashi Iwai
0 siblings, 0 replies; 2+ messages in thread
From: Takashi Iwai @ 2004-02-17 15:48 UTC (permalink / raw)
To: Thomas Charbonnel; +Cc: ALSA development
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
^ permalink raw reply [flat|nested] 2+ messages in thread