Re: [fluid-dev] File output with FluidSynth API

[Felix Krause]

On 04.03.2010, at 09:21, David Henningsson wrote:

> Felix Krause wrote:
>>>> fluidsynth -a file -i -n -T wav -o audio.file.name=output.wav
>>>> soundfont.sf2 midifile.mid
>>>> 
>>>> This just creates a 4KB file. Is it possible that this is a FS bug?
>>> 
>>> I finally got some time to look at this issue. When I tried to run your
>>> command I got a crash/backtrace. I committed a fix (to trunk) that fixes
>>> the crash I found, and I think that it will fix your issue as well.
>>> 
>>> The fix is here:
>>> 
>>> http://fluidsynth.resonance.org/trac/changeset/284/trunk/fluidsynth/src/fluid_midi.c
>> 
>> Thanks for your effort. I checked out revision 284 and compiled it,
>> but the problem is still the same. As I didn't have any crashes with 1.1.1,
>> I don't notice any change of behaviour with the new code.
> 
> So the FS command (fluidsynth -a file -i -n -T wav -o
> audio.file.name=output.wav soundfont.sf2 midifile.mid) still just
> produces a 4 KB file? It works here.

Yes, I still get a 4KB file.

>> I should mention that I usually don't load midi files, but work with
>> noteon / noteoff from the API, and tried playing midi files just for
>> debugging. So it's unlikely that my problem lies in fluid_midi.
> 
> Hmm. Since I don't really know how to reproduce that issue here, can you
> do some debugging for me? The file driver should create a thread that
> calls fluid_synth_one_block every few milliseconds (via
> fluid_file_renderer_process_block). This is not working for some reason.
> 
> Can you see if the thread is created correctly, and whether
> fluid_file_audio_run_s16 (in fluid_aufile.c) calls
> fluid_file_renderer_process_block periodically?
> 
> // David

I'm not familiar with C debugging. The Activity Monitor tells me that fluidsynth
has a total of 3 threads running when writing to a file - it has 4 threads when
using the CoreAudio driver, which works perfectly.

Here is a sample of the running fluidsynth process; I don't really understand 
how
to read this, but those "cerror"s don't look that good. If you could point me 
to some
debugging tool / method, I might be of more help.


Sampling process 8515 for 1 seconds with 1 millisecond of run time between 
samples
Sampling completed, processing symbols...
Analysis of sampling fluidsynth (pid 8515) every 1 millisecond
Call graph:
    873 Thread_65218   DispatchQueue_1: com.apple.main-thread  (serial)
      873 usleep$UNIX2003
        866 nanosleep$UNIX2003
          866 __semwait_signal
        7 cerror
          5 cerror
          2 cthread_set_errno_self
    873 Thread_65221
      873 0x1
        873 fluid_synth_return_event_process_thread
          873 pthread_cond_wait
            873 _pthread_cond_wait
              873 semaphore_wait_signal_trap
    873 Thread_65222
      873 fluid_file_audio_run_s16
        873 fluid_timer_run
          873 g_usleep
            873 nanosleep
              873 mach_wait_until

Total number in stack (recursive counted multiple, when >=5):

Sort by top of stack, same collapsed (when >= 5):
        mach_wait_until        873
        semaphore_wait_signal_trap        873
        __semwait_signal        866
        cerror        5
Sample analysis of process 8515 written to file /dev/stdout