[LONG] Mixers - suggestions needed

[Loïc Minier]

On Mon, Mar 18, 2002, Gildas Bazin wrote:
> - 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".

 Multi-intf is not really a problem, it's just that for now the mixer
only exists in a gtk interface.
 But you're right, it's not a good idea to store anything else than the
number of opened windows in the gtk part. This number or an equivalent
is required because the windows have to be kept, not destroyed.

> 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.

 I don't know, it really seems ugly to store each conversion setting.
I'm thinking here of the different number of channels we have to handle,
we would then have 2 settings for a 2 channel stream, 4 more for a 4
channel stream etc. That sums up to 18 settings to keep.

 Are you imaginating a new MODULE_CONFIG_-type ? Like a
MODULE_CONFIG_GAINS[] ?
 I like the idea, but practically it would be relatively heavy, don't
you think ?

> - 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.

 I think it's the right way to handle the problem.

> 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 ;-)

 Geee ! You're having the same idea sam tried to explain me ! Where do
you get them ?

> 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.

 Michel "walken" LESPINASSE told me the downmixing was taking less than
10% of the decoding time, so speed isn't really a good deal here.

> 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.

 I didn't get everything here, I don't see where you want the downmix
and decoding be actually done.

> you will have to first re-work the audio output architecture of vlc

 Hmmm, I hope I'm capable of that   :^/

 This is what I've understood/thought for a mixer-compatible arch :


                        input
                          |
                      AC3 parser                             parser
                          |
      _______________________________________
      x              x                      x
spdif decoder   ac3 decoder              liba52              decoder
      |              |                      |
      |              |              ________________
      |              |              x              x
      |            mixer          mixer            |         filter
      |              |              |              |
      |           downmix        downmix           |         filter
      |              |              |              |
 spdif aout     dsp esd alsa   dsp esd alsa   dsp esd alsa   output


 Of course a lot of other combinations are possible, this was just to
show how I'd like to organize the different parts.

-- 
Loïc Minier <lool at via.ecp.fr>

-- 
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>