[LONG] Mixers - suggestions needed

[Gildas Bazin]

On Sunday 17 March 2002 21:08, Loïc Minier wrote:
>
> So I thought of writing a small mixer in Gtk. In that way, one can
>adjust the gains as he likes them, at runtime. Following an advice
>of sam, I made a generic code to display a n-channel mixer, probably
>reusable for the audio output or for some other gain adjustments.
>
> . Problem
>
> Now I have to integrate that thing in vlc, and I'm having troubles
>imaginating for the following :
>- the place where I will store current gain values
>- the way of keeping these values while a decoder respawn (when you
>  change audio channel for example, the decoder is respawned)
>- the way of having multiple time the same decoder with different gains
>
> Point 2 is because you don't want to loose your gain settings after
>you've selected another audio channel.
>
> Point 3 is either a "be-generic" behavior I'd like to have (thinking of
>the day vlc will be a multi-input, multi-intf, no-segfault player).

I think the gain values should be initialized on startup from the 
configuration file, that will allow us to set a prefered value that will be 
kept from sessions to sessions. But we also need to be able to modify them 
at run-time.
So what I propose is:
- have an array of gain values (channel<->gain association) stored in 
p_main. I know this doesn't solve the "multi-intf" problem as we surely 
would like to have a different gain array for each interface, but it would 
just be a matter of moving this array to a new place when we finally decide 
to support "mutli-intf".
Obviously we would also have to set a maximum limit to the number of 
channels supported by vlc.
- this gain array would be initialized on startup from a config file option.
- the audio output thread would use this array to adjust the gain of the 
channels.
- the interface plugins would be able to modify the values in this array.

>
> . Solution attempt
>
> So the only current way I see now is following :
>- have a gtk-plugin value keeping count of the number of mixer we're
>  looking at, destroy the window when 0, incremented when we want to
>  create a new mixer view (for example when a decoder plugin starts);
>- have the audio decoders call a "register new mixer" function so they
>  make the gtkplugin clear where he could alter the gain, return a
>  handle;
>- pass an identifier for that decoder when registering so that a respawn
>  gets the same settings.
>
> So the actual gain value would be stored in the decoder, the preferred
>one would be stored in the gtk plugin, when the decoder is in the
>registered state the gtk-plugins alter both and shows the mixer, else it
>just grays off the mixer.
>

I don't really see any reason why we should make this mixer dependant on 
the interface plugin. All the interface plugin should do is... well... 
provide an interface to modify the gain array. Well, we could make it just 
a little bit more clever and tell it how many channels are being played, so 
we can gray out or not display the unused channels.

As you suggested in another mail, the mixer should be plugged at the audio 
output level and not at the decoder level. You won't be able to make a 
generic mixer if you need to hook each decoder.

I think the way to go should be to enhance the audio output thread so it 
can handle "multi-channels fifos". The decoders would then be able to 
decode directly their mutli-channels output into the audio output fifos, 
and the audio output thread would take care of the necessary conversions 
before sending the audio data to the output plugins.
That would basically make the mixer and downmix code just audio filter 
plugins ( but useful filters... heho sam ;-)

This will surely simplify the overall architecture, but we may also loose 
some performance. This will be the case (I think) with liba52 because it 
uses a few tricks to speed up downmixing that we won't be able to use 
ourselves if we separate the decoding and downmixing stages.
But why not provide the option in the a52 plugin to let liba52 do the 
downmixing itself? The only thing that would change for us is that as far 
as our audio output thread would be concerned, the output of the audio 
decoder would be stereo only.

To summarize the situation, I think your idea is great loïc but if you 
really want something clean and generic, you will have to first re-work the 
audio output architecture of vlc (which would be a good thing IMHO).

Cheers,

--
Gildas

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>