Re: [fluid-dev] Re: Changes checked into CVS

[Mihail Zenkov]

On Thu, 23 Nov 2006 19:13:37 +0000
Josh Green <address@hidden> wrote:

> Hello Mihail Zenkov,
> 
> Question to others on the list: Anyone have an application using a
> new_fluid_*_audio_driver2() call?
> 
> On Wed, 2006-11-22 at 02:57 +0200, Mihail Zenkov wrote:
> > But it have big overhead: many buffers, many purposeless copy of memory.
> > 
> 
> Yes you are right and I wanted to axe it myself.  Not sure what the
> original author, Peter Hanappe, had in mind when he added that.  I would
> guess it is to allow applications using FluidSynth to get their fingers
> on the audio data and do other processing before it goes out to the
> device.  I suppose the other option is to make it to where if the
> new_fluid_*_audio_driver2 functions are used they could do the extra
> copy and if the regular new_fluid_*_audio_driver calls are used then the
> more efficient single conversion could be done.  Therefore backwards
> compatibility would be preserved and the normal case would be more
> efficient.
> 
Good. And imho better if fluid_synth_write_s16 will work with one
buffer without negotiator. I do it in avidemux in dither16(), it use
single buffer for in (float) and out (int16_t). This buffer one for all
audio chain, only pointer transmit between function.

http://svn.berlios.de/wsvn/avidemux/branches/avidemux_2.3_branch/avidemux/ADM_audiofilter/audioencoder.cpp?op=file&rev=2597&sc=0

> > > - I removed the roundf calls since they seem to require a special
> > > -std=c99 compiler switch, which makes me doubt it works in Windows.
> > 
> > Without roundf() 0.5f (or 0.9f) = 0.
> > We can do dithering without roundf():
> > - d = rand() / (float)RAND_MAX - 0.5f;
> > +d = rand() / (float)RAND_MAX * 2.0f - 1.0f;
> > but it have worse THD.
> 
> Not sure I quite understand your argument there (I'm OK at math, but not
> great :)  I'm ready to take your word for it, but..
> 
> >From what I can see:  The random table contains values between -0.5 and
> 0.5 (well actually its the difference between a new random value and the
> previous, which seems weird to me, since the numbers are supposed to be
> random anyways).

Read more about triangle dithering. If we add just random - we have
noise modulated by signal. It bad.
Difference between new and old random value prevent this.

>These are then added to the floating point sample
> values of the audio.  roundf() would round the value to the nearest
> integer away from 0, whereas an integer assignment would just truncate
> it.  Adding 0.5 and then truncating the fractional result would be the
> same as rounding though, correct? (Except it wouldn't be always away
> from 0, but instead to the lower integer).

Yes you right, but in case without roundf we have two time bigger
amplitude and imho bigger THD (i see it when compare spectrum in
audacity). See attach to more undersend.
 
> Anyways, if we can find a solution that works across Windows/Linux and
> Mac OSX I'd be happy :)

I add dither with roundf to avidemux-2.3 and Mean (main developer) copy
this to new branch-2.4 ... Avidemux work on linux/win/mac/freebsd. But
not shure if he (or someone else) test it on all platforms. If you want
i can ask him.

> > > I did discover another bug in the process.  There seems to be a rather
> > > explosive audio problem with some instruments played at very high notes.
> > > I suspect a filter issue (there were several similar issues in the
> > > past).  Not sure at this point how to fix it though.
> > 
> > I try reproduce this tomorrow. Can you describe way to reproduce this
> > (sound font - better link to download, instrument, other settings)?
> > 
> 
> Yeah, I'll throw together some example.  Its not related to your patch
> though.  If you wanted to check it out though, I'd be happy to provide
> an example case.

I interested in better sound quality. If i can help - i try.

test.c
Description: Binary data