[FFmpeg-devel] [PATCH] Add libavsequencer.

[Sebastian Vater]

Michael Niedermayer a ?crit :
> On Wed, Aug 18, 2010 at 10:21:28PM +0200, Sebastian Vater wrote:
> [...]
>   
>> Regardings to pluggable mixing API, I summarize the discussion I had
>> recently with Stefano about this.
>>
>> The point is we were discussing about OPL2/3 and such special stuff, but
>> the actual point is way much simpler and closer (10l to me for that).
>>
>> We were discussing only pure software mixing engines (like low / high
>> quality mixers), but totally missed out the point (blame me for this,
>> not remembering this although I did knew/know this perfectly), that
>> there are a lot of hardware mixing capabilities.
>>
>> I remembered it when I discussed the features of original DOS Cublic
>> Player (the most famous MOD player in that time) and it's move to open
>> source today known as OpenCubicPlayer (look at a package named ocp in
>> your Linux repository) which supported not only basic software mixing
>> (null, lq, hq and floating point mixer) but also hardware capable mixing
>> (in the DOS time there was an GUS mixer, a SB AWE 32/64 EMU8000 chip
>> mixer, etc.).
>>
>> Now, of course, we don't work with old Gravis UltraSound cards and/or SB
>> AWE 32/64, but today we have:
>> DirectSound mixing API (which uses hardware mixing of modern soundcards
>> if availble), or OpenAL (same for Linux, etc.) API.
>>
>> Since practically every soundcard today supports hardware mixing, it
>> would pose up the question: "Why not use HW mixing as only option then?".
>>
>> Well the answer is. Hardware mixers are very different in its features /
>> capabilities, esp. maximum number of channels, volume stuff and output
>> sampling rate.
>>
>> The craziest one is probably the GUS regarding this, the more maximum
>> number of channels you did allocate, the lesser the maximum sampling
>> rate allowed was (this is independent of how much channels are actually
>> being played).
>>
>> Such limitations still apply to most hardware mixers today (very often
>> we have a limit of 64 channels, panning also (often no surround), volume
>> ranges, etc.)
>>
>> Now you remember the point, I told already, that you can "chain" mixers
>> as I planned and posted them here as patch (see my copying channels from
>> lq to null mixer and back in the exact seek discussion).
>>
>> This is, where FFmpeg again can kick ass, if we manage it to offer an
>> mixer API which a) utilizes hardware mixing devices and b) software
>> mixing devices...we can combine THEM!
>>     
>
> i think the problem we have is to get a single mixer and the surrounding
> code reviewed, understood and into svn currently.
> More mixers and a mixer selection api isnt going to help here.
> we are a bit short on reviewing man power for module related code
>
>   

Hmm, thinking more on this, what about this idea?

Instead of posting a null mixer, I could post a 8-bit mono input samples
mixer only which is even 100% sufficient for the 10 TCM files I sent you?

It would not show only basic mixing stuff, would only be a few lines
longer and showing also actual sample mixing?