[gmpi] Re: Topic 7: Audio packaging

At the risk of making people think that I'm only interested in opposing ideas...

At 11:36 AM 5/28/03 -0700, you wrote: 
At that level, ordering doesn't matter - the streams are not interleaved (we
have agreed on this, right?).  Withing a format definition, the streams are
named.  Order matters not.

OK, I was assuming there were no names. I agree that names solve all ordering issues.

Hm, I don't think there's been an agreement that there would be names. All my examples have been based on known buffer ordering/indexes, and that seems to me like the better way from an implementation simplicity POV. Remember, by ordering all we mean is the order of the buffer ptrs as presented to the plug (maybe in an array), the buffers themselves can each be anywhere in memory.

So what's the downside to agreed-upon ordering / what's the use case for arbitrary channel ordering? Bill, when you said that there are currently different channel orders for 5.1, what was the context (1394 wire, USB wire, IAC, etc.), and if it's only in stream transport protocols, then couldn't that be adapted to GMPI a single convention at the GMPI graph boundary? Seems like that'd remove the need to handle arbitrary ordering within GMPI multichannel audio connections?


> Encoding information (like matrix info, M/S, binaural, noise reduction
info) would be nice to have, but I think it should be optional.

I don't see any use in this at all - these are tricks to make various bits of

Sorry, I disagree here. There's all sorts of important reasons to annotate streams with meta-information. Think of all the stuff an engineer will write on a tape label. Again, strictly optional, but it would be nice if a plug could obtain additional information about the stream encoding and tailor its processing to suit. Perhaps we need another mechanism for sending meta-data related to a stream.

I don't have a specific solution to propose, but from a requirements POV I have to support Bill on this. Encodings are -not- limited to tricks to fit more channels into less channels, and even when they are, they come with a boatload of strings attached that need to be honored, else all hell breaks loose. For example, it doesn't fit the shape of the problem space to say that a 2-channel LtRt line should be encoded as four lines, because you can express things in four lines that can't be represented in LtRt. Or (sorry to keep with the Dolby examples, they just seem to pop into my head first) a 6-channel Dolby SR-encoded stream (as could be used if you were using ProTools as a film mastering recorder for preparing an analog print master) is inherently a different kind of signal from an unencoded 6-channel stream, and if a user inserts a compressor or EQ or even a fader in-line, the encoding thoroughly fails. I think at a minimum, we want to give those (perhaps few) hosts that care about these things a fighting chance to alert the user that they're about to do something very stooopid that will break the content, and likely be very, very expensive to fix later.

I suppose ideally this could/should be handled with some sort of, as Bill suggests, user-extensible metadata tagging scheme. But given the difficulty we've had so far on Topic 7, I really wonder how to proceed on this.

-- 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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: