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 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
