Hello Brad, The -a option specifies the audio driver to use. The "-a file" option uses the file driver, which can write to different audio formats. So yes, it is the same data that would be rendered to the DAC if such a driver was being used (depending on the format of the audio driver and file output - more on this below).
Looking at the code, the file driver will use libsndfile if it is built with support for it which offers up several options for file types, formats, etc (see "-o audio.file.*" options, you can get a list with "-o help"). If you don't build it with libsndfile support, then it just writes raw 16 bit audio. With libsndfile, the audio is rendered as floating point data using fluid_synth_write_float() and then written using libsndfile's sf_writef_float which probably does it's own dithering when writing to non floating point formats. If no libsndfile support is available, then fluid_synth_write_s16() is used with dithering. FluidSynth was primarily designed with speed in mind, so yeah, there are many cases where it favors optimization at the cost of memory. The interpolation tables are another example. Yes, interpolation is done before dithering. Dithering is only performed when rendering to 16 bit with fluid_synth_write_s16(). Interpolation is done per voice and is driven by the rendering functions. Please note, I'm just one of many authors of FluidSynth and hardly the primary one. My replies are based on some familiarity with FluidSynth, but a lot of this I'm just gleaning from the code by looking at it, since even stuff I have contributed has been long forgotten and needs some refreshing at this point. Best regards, Element On Mon, Jan 4, 2016 at 7:18 PM, Brad Stewart <brads...@fastmail.us> wrote: > One more question. Am I correct in assuming the interpolation is done > prior to dithering? > Brad > > > > On Mon, Jan 4, 2016, at 06:16 PM, Brad Stewart wrote: > > Thanks for the added into. The "before it's rendered" means before it's > sent to the DAC for rendering. > When using the "-a file" option, does it store the results after > fluid_synth_write_s16? > > The clue may be the dither. If you recall the scope diagrams I sent last > week, the "clean" sine-wave uses interp 1, and the "dirty" one with the > staircase is with interp 0. Now linear-interpolation can't possibly yield > a "clean" sine-wave. The best it can do is round out the edges at each > staircase transitions, but it hardly makes any kind of audible > difference--still sounds awful on my system. > > I see you have a fairly large value for DITHER and it takes up a > substantial amount of memory (48000*2 floating values in rand_table) That > eats up a lot of an embedded Flash. I think I can do it with using a > simple pseudo-random generator and int16_t or possibly modulate the audio > out clock. But I'll need to study the FluidSynth code more carefully. > > I do have the post filter set to max, and reverb/chorus disabled. > > --Brad > > > On Sun, Jan 3, 2016, at 05:52 PM, Element Green wrote: > > FluidSynth currently only supports 16 bit audio sample data, such as in > the SF2 format. > > There are several functions which are used for synthesizing the output, in > particular: > fluid_synth_nwrite_float > fluid_synth_process > fluid_synth_write_float > fluid_synth_write_s16 > > The last one in particular outputs 16 bit audio and performs dithering > when converting to signed 16 bit values. I'm not sure if that is what you > are observing or not though. FluidSynth does have a low pass filter, > reverb and chorus effects, so perhaps that is affecting the output you are > seeing? I would turn off the reverb and chorus affects at least and > perhaps disable the filter by setting the cutoff frequency to its highest > value and the Q value to the lowest value for the instrument you are > testing and make sure there is no modulation of the filter cutoff occurring > with the envelope or oscillators. > > As far as rendering the audio to a file, you could use the "-a file" > option for "real time" rendering or the -F option for faster than realtime > rendering of a MIDI file with the fluidsynth shell. Not sure if that will > get you want you want though, since I don't fully understand what you mean > by "before it's rendered". > > Element > > > On Sun, Jan 3, 2016 at 4:23 PM, Brad Stewart <brads...@fastmail.us> wrote: > > Regarding the previous post... > > It seems this is done in the function *fluid_rvoice_buffers_mix *in the > file "fluid_rvoice.c." > The output is buf[] and is also type fluid_real_t. > So I'm assuming the rendering engine can accept floating point values. > I'm still trying to see how the linear interpolation is able to remove > most of the low frequency artifacts. none of the simulations and > experiments don't result in the output I'm seeing from FluidSynth. > Perhaps the audio h/w has additional filtering functions. > > Is there a way I can save an output wave to a file? I want to look at the > audio data before it's rendered. > > Thanks, > Brad > > > > On 01/03/2016 01:27 PM, Brad Stewart wrote: > > The interpolation routines place the processed data into dsp_buf[] of type > fluid_real_t. > I'm assuming you eventually convert this to int16 for rendering. > Can you point me to the section of the code that does the conversion? > Are you doing anything else, such as a moving-averaging filter? > Thanks, > Brad > > > > _______________________________________________ > fluid-dev mailing list > fluid-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/fluid-dev > > > *_______________________________________________* > fluid-dev mailing list > fluid-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/fluid-dev > > > -- > Brad Stewart > brads...@fastmail.us > > > > > -- > Brad Stewart > brads...@fastmail.us > > > > _______________________________________________ > fluid-dev mailing list > fluid-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/fluid-dev > >
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
