[gmpi] Re: Reqs TODO
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 26 Nov 2003 17:27:00 +0100
On Wednesday 26 November 2003 15.25, Paul Davis wrote:
> >I would like to see GMPI just do one audio sample format, and I
> > would like it to be 64-bit float.
> ><<<
> >
> >I strongly disagree... sort of.<g>
> >
> >I would like GMPI to do a single audio sample format, and it
> > should be called "sample_t". If we wind up designing the notion
> > of plugin profiles, then one profile can have sample_t be float,
> > and another can have it be double.
> >
> >I object to double as the preferred or nominal format because of
> > memory bandwidth considerations. Mundane DSP can get pretty
> > expensive when you start requiring each audio data buffer to be
> > twice as big as necessary. Double is important for internal state
> > of DSP (such as coeffs in a biquad, for example), but for
> > connecting objects float seems pretty robust.
>
> i'm with ron on this one. one sample
> format. platform-specific. recompile your plugin with a different
> platform header (and presumably a suitable compiler) and it runs on
> a different platform.
"Me too."
> might be 64, might be 32. you don't know, and
> you probably shouldn't care.
That might work for FP formats, though I think there are exceptions.
For example, there might be cases where you have to use your own
temporary buffers with float, but could use the output buffers
directly if they're in double format.
So, "you don't know" would effectively mean "you should never use
sample_t [or rather GMPI_sample, since *_t is reserved... :-/] for
anything but I/O".
Anyway, there's no avoiding being aware of the exact sample format if
it's an integer/fixed point format. The 0 dB level scales with the
sample size, and pretty much any DSP code is affected in more or less
mysterious ways. :-)
> i see 2 issues though:
>
> first, the arrival of the usual marketing BS, whereby host Foo
> proclaims across the pages of Mix, EQ, Sound on Sound, EM and
> others "now with 64 bit internal audio data path", instantly
> labelling all 32 bit plugins for that "platform" as "inferior". the
> host would simply have used a new platform file ... not good.
Well, the correct way would be to have that host support multiple
profiles, I think. We can't prevent people from screwing things up
this way, if they really want to...
> secondly, if you're writing DSP code, there's a good chance that
> the way you handle a 64 bit unit will differ from the way you
> handle a 32 bit one. most ANSI C stuff is double-clean, but at the
> assembly level, i am not familiar enough to know the impact ...
I don't think it matters much whether you're doing it in C or
assembly, except that you have to be explicit about the datatypes
when accessing the buffers in assembly language.
Anyway, I guess there might be a risk of accidental GMPI_sample
dependencies in algorithms that look at I/O buffers at various points
along the signal path. For example, casting from float to double
could be done later than you expect in an expression, if there are no
explicit double arguments involved.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
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:
