SF2 hangs on open (Apple) #649

Open
tresf opened this Issue Apr 26, 2014 · 22 comments

Projects

None yet

4 participants

@tresf
Member
tresf commented Apr 26, 2014

Software freezes and causes the user to "Force Quit" when opening any project with at least one soundfont .

  • This crash occurs with SF2 files as relative OR absolute paths.
  • This crash occurs with SDL OR PortAudio.
  • This crash DOES NOT occur when using Dummy Audio.

The soundfont player works if added manually, but when reopening the project, the software hangs on a dialog that says "Opening project" usually around 70-80% with the spinning wheel which never goes away.

The screenshot below (sorry, not ver descriptive) is the screen that the user will see when the freeze occurs. The default project is loaded in the background while the "Opening project" screen appears and then the pinwheel appears and the software has crashed.

screen shot 2014-04-26 at 12 25 10 pm

Possibly related: http://www.juce.com/forum/topic/coreaudio-possible-deadlock-when-moving-mavericks

Backtrace:
https://gist.github.com/tresf/230b20f083403a11a3c7

@mikobuntu
Contributor

Im not sure if this is related, but everytime i load a soundfont on linux i get this ( non fatal ) warning CRITICAL **: fluid_synth_sfont_unref: assertion `sfont_info != NULL' failedperhaps related to the fluidsynth lib files? or within LMMS itself?
anyway great job so far on getting LMMS this far forward on OSX ....
I seen from your vid that you are having a lot of trouble with the LADSPA plugins also.
thanks Mikobuntu ;)

Date: Sat, 26 Apr 2014 09:26:22 -0700
From: notifications@github.com
To: lmms@noreply.github.com
Subject: [lmms] Projects containing soundfonts hang on open (Apple) (#649)

Software freezes and causes the user to "Force Quit" when opening a project with Soundfonts.

The soundfont player works if added manually, but when reopening the project, the software hangs.


Reply to this email directly or view it on GitHub.

@tresf
Member
tresf commented Apr 26, 2014

I seen from your vid that you are having a lot of trouble with the LADSPA plugins also.

We've omitted some items for now due to some incompatible coding standards. I haven't dove too much into those messages yet.

Edit: The LADSPA stuff has since been corrected and pushed upstream to Steve Harris's GitHub repo. It was the same _init() and _fini() bug that affected the tap plugins.

@tresf
Member
tresf commented May 13, 2014

Some pthread specific information for OSX which may be useful:
http://stackoverflow.com/questions/15590865/crash-in-pthread-specific-on-mac-os-x

@tresf
Member
tresf commented Jun 5, 2014

A slightly better stacktrace containing more debug symbols:
https://gist.github.com/tresf/230b20f083403a11a3c7

@tresf tresf changed the title from Projects containing soundfonts hang on open (Apple) to SF2 hangs on open (Apple) Jul 8, 2014
@tresf tresf added the bug label Sep 8, 2014
@tresf tresf added this to the 1.2.0 milestone Sep 8, 2014
@tresf
Member
tresf commented Oct 28, 2014

@mikobuntu after some observations of outstanding SF2 bugs, I do believe this is related to the errors you are seeing. It appears something is not initializing properly but I still cannot find it. Will continue searching. :)

@tresf
Member
tresf commented Oct 28, 2014
@tresf
Member
tresf commented Oct 28, 2014

Another bug report from 2006 which claims to have been resolved with a source code update.
http://lists.puredata.info/pipermail/pd-list/2006-04/036979.html

Seems to crash on a similar mutex lock area while initializing the fluidsynth settings. Interestingly enough, I did a similar snippet with if (m_settings != NULL) and and delete_fluid_settings(m_settings) prior to the initialization and was able to crash LMMS (Linux), but it won't crash on debug, so I can't pinpoint the exact crash point/error.

@tobydox how would we go about trying out some of the upstream patches? Would this cause issues on the OSs which bundle fluidsynth (i.e. Linux)? Mostly concerned with #1238 although Mac support would be an added bonus if the bugs are related.

@tresf
Member
tresf commented Nov 7, 2014

Unfortunately, commit 240c0b2 does not fix this bug. Apple SF2 support will remain disabled on stable-1.1

@softrabbit
Member

Had a look at the backtrace (from 2014-06-05), and... why is libfluidsynth calling into CoreAudio? AFAIK it shouldn't be doing any audio output to anywhere besides LMMS.

frame #7: 0x00007fff92fb1bb6 CoreAudio`AudioObjectGetPropertyDataSize + 218
frame #8: 0x0000000109c0119c libfluidsynth.1.dylib`get_num_outputs + 76
frame #9: 0x0000000109c0135f libfluidsynth.1.dylib`fluid_core_audio_driver_settings + 303
frame #10: 0x0000000109c2891e libfluidsynth.1.dylib`fluid_audio_driver_settings + 462
frame #11: 0x0000000109c04bfb libfluidsynth.1.dylib`new_fluid_settings + 91
frame #12: 0x0000000109bc4976 libsf2player.so`sf2Instrument(this=0x0000000101b2d000, _instrument_track=<unavailable>) + 2054 at sf2_player.cpp:110
@tresf
Member
tresf commented Jan 16, 2015

Well, I'm not explicitly linking against any CoreAudio files in the bundle, so I think it's a problem with a mutex lock, but I'm not very good with debugging these things...

The closest thing I could find for an explanation is here:
http://stackoverflow.com/a/8472145/1466873

I don't know if it matters, but this doesn't crash every time if the instrument is added manually. I can get the instrument to add to a track and get SF2 playback about 50% of the time.

However on project load, it crashes each time.

Also, if I change the output device to DummyAudio, it doesn't crash either.

-Tres

@softrabbit
Member

This looks like an identical crash: http://www.juce.com/forum/topic/coreaudio-possible-deadlock-when-moving-mavericks

So, SDL or PortAudio uses CoreAudio, and when libfluidsynth goes about using it as well, a deadlock happens if the timing is right. I'm leaning strongly towards this being a libfluidsynth bug.

Think I'll file an issue for this over at SF.net and see what the Fluid people have to say on the subject.

@diizy
Contributor
diizy commented Jan 16, 2015

On 01/16/2015 08:12 PM, Raine M. Ekman wrote:

This looks like an identical crash:
http://www.juce.com/forum/topic/coreaudio-possible-deadlock-when-moving-mavericks

So, SDL or PortAudio uses CoreAudio, and when libfluidsynth goes about
using it as well, a deadlock happens if the timing is right. I'm
leaning strongly towards this being a libfluidsynth bug.

Hm... yet another reason to roll our own soundfont player?

@tresf
Member
tresf commented Jan 16, 2015

This looks like an identical crash: http://www.juce.com/forum/topic/coreaudio-possible-deadlock-when-moving-mavericks

Hey!... That same bug is in my original post. :)

@softrabbit
Member

Hey!... That same bug is in my original post. :)

Right, must've been a case of scrolling blindness on my part.

@tresf
Member
tresf commented Jan 16, 2015

Right, must've been a case of scrolling blindness on my part.

or TL;DR on my part 🍰

@tresf tresf modified the milestone: 1.3.0, 1.2.0 Mar 8, 2015
@softrabbit
Member

@tresf, I never got around to filing an issue, but revisiting this now I have an idea. Could you try adding a line:

fluid_settings_setstr(m_settings, "audio.driver", "file");

right after new_fluid_settings() in the constructor for the sf2Instrument ? That should prevent Fluid from defaulting to CoreAudio.

https://sourceforge.net/p/fluidsynth/wiki/FluidSettings/

@tresf
Member
tresf commented Jun 12, 2015

👍

screen shot 2015-06-11 at 11 55 43 pm

@tresf
Member
tresf commented Jun 12, 2015

Ok.. I took the line back out and it's not crashing... I'm not sure how conclusive these findings are now. 😿

Edit: I installed on native hardware and the bug still exists with the recommended patch, still hangs at 83%. Not sure why the Lion VM doesn't encounter this crash (I would suspect it's sound driver related). Also, adding the instrument manually seems to be stable, it's project load that is causing the reproducible crash.

screen shot 2015-06-12 at 12 25 56 am

@softrabbit
Member

Not sure why the Lion VM doesn't encounter this crash (I would suspect it's sound driver related).

Me too. And that's the direction the earlier backtraces point as well.

Also, adding the instrument manually seems to be stable, it's project load that is causing the reproducible crash.

Can you load a project containing only one SF2 track or does that crash too?

@tresf
Member
tresf commented Jun 12, 2015

That crashes too. It's technically an "infinite hang" symptom that occurs and it happens regardless of whether or not an actual SF2 file is loaded into the instrument or not.

image

@tresf
Member
tresf commented Oct 22, 2015

Think I'll file an issue for this over at SF.net and see what the Fluid people have to say on the subject.

@softrabbit do you think this is still worth an upstream bug report? If this is an upstream issue, I'm a bit confused that other people aren't experiencing it too.

Edit: Interesting mailing list conversation here, but appears to be an unrelated 32-bit lib problem: https://lists.nongnu.org/archive/html/fluid-dev/2013-08/msg00024.html

@tresf
Member
tresf commented Oct 23, 2015

Out of curiosity, I changed the modality of the progress dialog that appears when the track loads, and the frees occurs at 20% instead of 83%.

This is a shot in the dark, but is there a chance that fluidsynth is honoring some unorthodox blocking somewhere (such as on the GUI thread?). This is such a strange bug. Many of the older fixed bug reports mentioned issues with glib threads (which AFAIK we don't use), so the plugin makes some null thread reference internally to prevent deadlocks. Not sure if there's something correlated here, but the fact that is freezes 100% of the time on project load, but only occasionally after load makes me wonder if the lock is actually occurring somewhere else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment