Re: [linux-audio-dev] [WIP] hdsposc

Mario Lang wrote :

(...)
> >
> > This is great. Doing this has been part of my plan for the hdsp for a
> > long time,
>
> Great, I already kind of hoped you'd take the idea that way. All arguments
> below aside, its the code duplication alone that really bugs me.
>

There shouldn't be any code duplication, hopefully.

> > 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.
>
> I am not sure that I really understand. There is a hwdep ioctl to
> receive the cuttent mixer matrix, wouldnt that kind of suffice to reconstruct
> the gui? Or am I completely missing something else here? Mind my
> situation, I have not use hdspmixer before, since I cant actually see its output.
> So I have learned from the code, mostly.
>

It's not extremely easy to describe, but I think the main point is this:
think of the output row as an additional attenuation stage. I can ask
the app to apply a -10dB attenuation on all signals routed to the
physical output 1 for example. Internally it translates to (multiple)
standard mixer calls. The problem is that the same hardware mixer state,
as kept in the driver and hardware, can be translated to different
hdspmixer states. For example in the case the hardware mixer says input
1 should be routed to output 1 with a 6dB attenuation, this could have
been generated by a hdspmixer configuration were the input is routed to
the output with no attenuation but there is a 6dB global attenuation on
this output. So the whole thing is like a set of per-physical-output
master volume controls. To use your app as a backend for hdspmixer, this
additional logic has to be implemented.

> > 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.
>
> I'd prefer if the GUI frontends would be made frontends only, to eliminate
> the duplicated code. But thats already very futuristic... :)
>

That's what I meant, roughly. What we could also do is have some form of
library that would encapsulate all this (notably the OSC code and
callbacks) and expose a simple hdsp specific api. And as far as the
daemon is concerned most of the ctl code and app logic could be directly
ripped off hdspmixer.

> > 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 ?
> Sure :-)
> > * 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)
> hdsposc already contains a prototype of a HDSP class for SC :-)
> It doesnt do much more than measuring latency with a ping right now, but hey :-)

Nice !

> > * implement a ramping mechanism in the daemon to eliminate zipper noises
> > when accessing the mixer, thus making the hw mixer usable in live
> > conditions.
> Hmm, lagtime, neat idea.
> > * 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).
> That definitely goes over my capabilities regarding alsa hackage...

This has often been requested by users. It's very easily done once the
daemon is here.

> >
> > I hope all this was more exciting than confusing,
> > Thomas
>
> I guess for now, I'll keep it simple, maybe someone can later take it
> and work on from there to complete the whole task. My problem is basically
> that I cant see the current GUIs, and it sounds like very hard work to
> work out the complete underlying model from just reading (C++, eeeek!)
> code.
>

On the model side, it's quite easy : everything seems to work as the
mixer ctl (input/playback, output, gain) except the backend applies this
last per-physical-output attenuation before actually setting the
hardware. So you just need an extra call to set or retrieve the
attenuation for a given output, and you have to keep the state of the
matrix (which is now disconnected from the hardware matrix), and the
per-output state of the attenuation stage.

Last point: I'm absolutely willing to contribute to this, as much as I
can, notably on the driver/tools side.

Thomas
Received on Thu Jun 16 12:15:10 2005