"Anthony Airon Oetzmann" airon@gmx.net wrote:
Sounds complicated to me :). I didn't figure the Winamp specs were that lax.
The API is actually somewhat reasonable, it's just that not all plug-ins may support all sample sizes.
There's supposed to be a v3 of Winamp soon. I wonder how well MAD will fit in there, given that it's supposed to be that much mroe flexible. One distinct advantage of a single plugin-doing-it-all approach, might be the portability to XMMS and so on. I'm not shure how compatible a seperate DSP module will be, when realy you're using the same amount of memory and processing time.
On the contrary, portability is usually increased when you limit the number of dependencies.
The DSP stuff can always be folded back in if there is not an equivalent place to put it in a port to another platform.
Is it possible to control a DSP plugin from inside an input plugin ? That's what I'd gathered from your idea of the "High-resolution DSP support" switch that's greyed right now.
It's possible to control the DSP plug-ins so far as to decide whether to invoke them at all, what sample size to feed them, and of course the samples themselves.
Remember that the DSP will rake in the dithering code, since all else would destroy the profit made from having 24 or 32 bit output in the first place. It's not great to dither audio twice either if you're going 16 bit out and DSP'ing it to 16 bit again after processing it perhaps in 24 or 32 bit with the DSP plugin.
Eh? I'm not suggesting to dither twice.
Here's the current picture for 16-bit output:
+-----+ +-----+ +----------------+/ | MAD | --32--> dither --16--> | DSP | --16--> | Output Plug-in |- audio +-----+ +-----+ +----------------+\
Here's what I'm proposing with the high-res DSP option:
+-----+ +-----+ +----------------+/ | MAD | --32--> | DSP | --32--> dither --16--> | Output Plug-in |- audio +-----+ +-----+ +----------------+\
In all cases "--32-->" means MAD's internal 24-bit + 3-bit headroom sample representation.
I'm not shure a modular design has that many advantages, but to provide two seperate setting controls.
While I think this is indeed probably an advantage, the other advantages are (1) I can eventually call the MAD input plug-in "finished" and concentrate on the DSP stuff independently, (2) the DSP plug-in can be used with other input sources, not just MPEG audio, (3) maybe others would be interested in contributing to the DSP plug-in, being less complex than a full-blown decoder, (4) a bug in one plug-in can be isolated from the other, (5) etc.
Cheers, -rob
On Mon, 18 Dec 2000 23:02:40 -0500, Rob Leslie wrote:
Remember that the DSP will rake in the dithering code, since all else would destroy the profit made from having 24 or 32 bit output in the first place. It's not great to dither audio twice either if you're going 16 bit out and DSP'ing it to 16 bit again after processing it perhaps in 24 or 32 bit with the DSP plugin.
Eh? I'm not suggesting to dither twice.
Here's the current picture for 16-bit output:
+-----+ +-----+ +----------------+/ | MAD | --32--> dither --16--> | DSP | --16--> | Output Plug-in |- audio +-----+ +-----+ +----------------+\
Here's what I'm proposing with the high-res DSP option:
+-----+ +-----+ +----------------+/ | MAD | --32--> | DSP | --32--> dither --16--> | Output Plug-in |- audio +-----+ +-----+ +----------------+\
In all cases "--32-->" means MAD's internal 24-bit + 3-bit headroom sample representation.
You should scrap that first approach. Processing dithered 16 bit output is bad, compared to what you get with the second signal flow. Both cases bare a slight disadvantage. In the first you'll get dithered 16-bit output, but won't have a clip correcting limiter and if you shift that in to the DSP part, NO attenuation. THe second approach requires a mandatory DSP plugin, otherwise people won't be able to do a thing with MAD's output. A check if there's a DSP plugin that turns the special 32-bit output in to a compatible output for the soundcard would fix this, so I think the second approach should be the default.
I'm not shure a modular design has that many advantages, but to provide two seperate setting controls.
While I think this is indeed probably an advantage, the other advantages are (1) I can eventually call the MAD input plug-in "finished" and concentrate on the DSP stuff independently, (2) the DSP plug-in can be used with other input sources, not just MPEG audio, (3) maybe others would be interested in contributing to the DSP plug-in, being less complex than a full-blown decoder, (4) a bug in one plug-in can be isolated from the other, (5) etc.
All the plugin authors could write 32(24+3) bit output modes for their plugins. You'd have to design a spec so that the DSP plugin can reveal its presence, so the input plugin switches to 32bit MAD mode, no?
Tony