[gmpi] Re: Topic 7: Audio packaging

  • From: Bill Gardner <billg@xxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 21 May 2003 19:38:45 -0400

General comment: this is one area where I think we can be pretty simple. In my experience, the complexity of say, DirectX buffer objects has caused only headaches without any advantage over say, VST's simplicity, except for the ability to support both F32 and I16 formats (but nobody uses I16 anymore).

1.  How should multichannel audio streams be represented, interleaved or
not?

Non-interleaved.

2. What audio sample data types should be supported?

F32 rules, but we do need it to be an arbitrary type negotiated with the host. I can see some uses for integer sample formats in the case of hardware proxies, and perhaps F64 if the plugs are unit generators in a recursive loop. But the main reason to support extensibility is dealing with non-PCM formats.

The connection negotiation should be simple. The plug presents is capabilities to the host, and then a legal connection is made.

3. How are audio data buffers allocated?

By the host. This is trivial when the format is PCM and the number of samples doesn't change from in to out. Sample rate conversion, time scale modification, codecs, and the like will require more complicated buffer management, but I think the data buffers should always be managed by the host.

4. Are audio data buffers timestamped?

I prefer the timestamp to accompany the buffer in a container struct, or passed as an arg, but yes in general.

5. Are compressed formats like MP3 permitted?

I think version 1 should focus on PCM formats only.

6.  Should data be packaged as objects a la DirectX, or as raw buffers a la
VST?

Raw works just fine for PCM. I suppose objects are better for managing other media formats, but I would prefer to avoid them.

(7: Paul's question about FFT blocks)

Same as 5.

(8: Are data blocks passed along down the stream and reused where
possible, or effectively owned by a single i/o connection pair? Is it
legal to expect a plug to use the same buffer for input and output and
pass it on?)

I like having both input and output pointers, so the plug does a copy if they point to different addresses, but if they point to the same address the plug operates in-place (and the spec would mandate this). In-place would only be permitted in cases where the input and output formats and number of channels were identical.

Bill

At 01:43 PM 5/21/03 -0400, you wrote: 
1.  How should multichannel audio streams be represented, interleaved or
not?

2. What audio sample data types should be supported?

3. How are audio data buffers allocated?

4. Are audio data buffers timestamped?

5. Are compressed formats like MP3 permitted?

6.  Should data be packaged as objects a la DirectX, or as raw buffers a la
VST?


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


----------------------
Bill Gardner
Wave Arts, Inc.
99 Mass. Ave., Arlington, MA 02474
Tel: 781-646-3794   Fax: 781-646-7190
billg@xxxxxxxxxxxx


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