[gmpi] Re: Topic 7: Audio packaging

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

Saying that a buffer is named is no different from saying that it is in a
specific location.  If you can count on the fact that CENTER is buffers[3],
it essentially is named, yes?

What I'm saying is that within a format, the relative position/meaning of
each signal is known.  The issue of multiple 5.1 channel ordering is moot.
You don't just get 6 channels, you get 6 channels WITH KNOWN POSITION.  Does
that clarify?  I think you and I are saying the same thing.

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

Yes - this is an input/output issue - your file reader or writer or protocol
sender/receiver handles re-ordering from GMPI to something native.

> 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 

OK, this is going to seriously impact those plugins that want to do things
cross-format in a BIG way.  I don't suspect many, if any, plugins will ever
support these encodings.  You'll have your LtRt reader and that's it. :)

> 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 guess I don't REALLY care.  I'll never use it.  The vast majority of
people won't use it.  No need.  When DolbyLabs writes their LtRt plugin set,
we'll see people use it. :)

But really, isn't it more useful to say:

1) Read LtRt source
2) decode to 4 channels
3) process with ANY plugin(s)
4) encode to LtRt
5) Output LtRt


rather than:

1) Read LtRt source
2) process with LtRt plugin(s)
3) output LtRt


Tim

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