[gmpi] Re: Topic 7: Audio packaging

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 21 May 2003 16:08:47 -0700

Sebastien wrote:

Hi Tim & all :)

Tim Hockin wrote:

For XAp we did this:  The plugin hints each channel with common hints (LEFT,
RIGHT, MONO, LFE, etc).  The host can then automatically connect a LEFT
output to a LEFT input.  If there is confusion, the host might need to ask
the user.  This gives us an infinitely flexible way to handle multi-channel
audio.  We don't need to code 5.1, 6.1, 7.1, etc into the spec except as
hints.

This seems quite dangerous to me as there are special mixing rules for sourround sound, and all channels are not equally treated, particularly when you submix 5.1 to quad or stereo, or program effects that contain strong panning informations (autopan is a simple one).
It is not at all easy to come up with a good solution for this but multichannel audio is sure to become a recurent subject in the very near future. I don't thing hints are enough and I'd advocate for a more direct definition of the type of channels we get fed with.

Each audio channel may have multiple hints, too.  For example, a plug that
can do 5.1 or stereo or mono:

1: MONO, LEFT, FRONT-LEFT
2: RIGHT, FRONT-RIGHT
3: CENTER
4: REAR-LEFT
5: REAR-RIGHT
6: LFE

This seems strange to me: center and mono look much more like the same thing than mono and left (left and front left is ok). You can be sure that such a vague definition will break quite soon :). You will need to defined eveything from mono to 9.1 (with multiple LFEs) to ambisonics... In the end you're probably better set with directly informing the plugins and hosts about the real channel semantics you want to use: mono, stereo, quad, 5.1, 7.1, 9.1, ambisonic, M/S couple... And make a channel map ready for each type.

my 0.02 euros

Sebastien

I agree with Sebastien, the semantics of multichannel audio formats are more complicated than the hinting approach alone is able to account for. We need to find a way for a plug to advertise to the host what multichannel formats it supports, directly in terms like mono, stereo, quad, 5.1, 7.1, 9.1, ambisonic, M/S, etc. While there could be a role for hinting within each of those worlds, it seems like matching hint tags is unnecessary -- why not just have per-format rules, e.g. in 5.1 buffer 0 is LF, 1 is CF, 2 is RF, 3 is LR, 4 is RR, 5 is Sub? This is efficient and unambiguous.

Once such an approach is chosen, the advantages of the multiple-channels-per-pin approach become more apparent. The pin has a property for its multichannel audio format (again mono, stereo, quad, 5.1, 7.1, 9.1, ambisonic, M/S, etc.), and truly these are each a naturally different/unique audio stream type. This allows the host to easily identify compatible plug ins & outs, and make connections of like formats. Otherwise how is a plug supposed to be able to tell the difference between a stereo stream, an LtRt stream, and an M-S stream? They're all two channels, after all, but they're not interoperable.

Yes, it's inconvenient for an experienced mono/stereo plug-in developer to have to deal with the complications of multichannel formats, but if the API is carefully designed we can minimize the complications for people who still only care about mono & stereo. Think of it as being like the transition from ASCII to Unicode -- an unpleasant transition, but a brief one. Inside, the plug still gets ptrs to buffers and iterates across them, no essential difference.

-- Chris

----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts:

  1. Home
  2. gmpi
  3. Archive
  4. 05-2003