Although it is good to see activity on the fluidsynth mailing list, the state of the bug tracker is not as promising. We normally get fluidsynth from repos, so yes. Do we wait until fixed versions are released? My question was really hoping for a threaded work-around. Whether or not it SHOULD be talking to CoreAudio is an architectural question about the library - one I'm not going to tackle. From everything I'm reading as well as previous bug-hunting on Mac, this is a threading problem causing the crash. Repeating the same words over and over without explaining why doesn't help. The plug-in should not call any audio driver.
#How safe are sf2 files code
In the WebRTC code base they have this code: Ĭan someone point me in the right direction? Does this need to be fixed inside AudioPortAudio.cpp or PortAudio itself? Where can I look to handle the SF2's plugin initialization in a thread-safe manner? Many places, not all of them on the audio thread. However, currently we call AudioObjectPropertyData in Which will hopefully ensure it has to fire callbacks in a concurrency safeĪnother option might be to set the run loop to the one used by theĪudio thread. KAudioHardwarePropertyRunLoop to NULL tells OSX to manage its own thread, Seems OSX might be expecting us to only make AudioObjectPropertyDataĬalls on the same thread as listener callbacks are fired on.
Tell OSX to manage its own property listener callback thread. I don't believe Chrome ever fixed the problem, they just removed the feature from Mac. The description is identical to what's the the backtrace. The problems seems to stem from a lock on CoreAudio ( CoreAudio HALB_Mutex::Lock()).Ĭhromium suffered a similar problem here. Finally found the JUCE commit that addressed this lock 2682871#diff-80c212bebcf9de54a837d1e31270ca70R371
0 kommentar(er)
