[linux-audio-dev] [WIP] hdsposc

[thomas charbonnel]

> Hi.
> 
> Since I finally ordered my Multiface, I also started to write
> a small program which I am going to need since hdspconf and hdspmixer
> are both GUI only.
> 
> The idea:
> hdsposc will offer the RME mixer and the metering functionality
> via OSC.
> 
> Why do I write this mail?  I'd like to know if someone else
> could also make use of this tool.  If so, I'd like to hear
> your input what you'd want to exactly do with it.  If no one responds,
> I'll save coding time by ONLY implementing the Multiface (since thats
> what I can test) and probably not polish it much, since
> what I need is probably very basic.
> 
> Oh, and BTW, during coding of hdsposc a question arose:
> Is it recommended practice to immediately close a hwdep device
> again after performing a single operation, or would it be OK
> to leave the hwdep handle open during runtime and only close it
> again on program shutdown?

Hi Mario !

This is great. Doing this has been part of my plan for the hdsp for a
long time, but it's been delayed and delayed, and I have to admit that
there is nearly no chance that I could find time to work on this in the
next months.

I'll explain here what I had in mind with the avowed hope to push you in
this direction as I believe this is the way to go :)

Situation :
The hdsp is a great piece of hardware, and very straightforward to
handle as almost everything is done in hardware. The alsa ctls the
driver exports reflect this. But now comes the problem : if you ever
used totalmix/hdspmixer, you probably used the last row (Output row).
It is very useful, but here's how it works: every time you manipulate
this row, hdspmixer/totalmix has to calculate and apply the attenuation
coefficient to all streams routed to the specific physical output you
targeted. Why is this a problem ? Because there is some information in
hdspmixer that is not present in the hardware, and gets lost when
hdspmixer is no more available. Also this prevents different application
to access the mixer at the same time and share a common representation.
If you play with amixer and the mixer ctl while hdspmixer is running,
you'll invalidate hdspmixer's representation. And of course you can't
use the very nice alsa monitoring/callback mechanism on ctls.

So what can we do ?
Implement a daemon to hold this representation and share it with other
apps through OSC. Then rewrite the hdsp* tools to optionally use the osc
backend instead of talking directly to the card using ctls.

What are the benefits and possibilities ?
* can you imagine controlling a farm of hdsp powered machine with
hdspmixer and hdspconf running on a (possibly) hdsp-less machine on the
network ?
* have a pd or sc patch, or a ladspa plugin (automated in ardour ? :)
control the card's mixer and visualise the changes with hdspmixer (or
the opposite)
* implement a ramping mechanism in the daemon to eliminate zipper noises
when accessing the mixer, thus making the hw mixer usable in live
conditions.
* provide fake standard mixer ctls in the driver, like a "master volume"
ctl for example. The ctl does nothing in kernel space, but the daemon
has a callback registered on it and does the actual job when for example
the gnome mixer applet requests a change. (and again all this can be
visualised in hdspmixer).

I hope all this was more exciting than confusing,
Thomas