fluid-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] Question to fluidsynth specialists - Crash in "new_fluid


From: Reinhold Hoffmann
Subject: Re: [fluid-dev] Question to fluidsynth specialists - Crash in "new_fluid_settings"
Date: Fri, 6 Nov 2015 19:31:38 +0100

Hi,

I can report that the issues are all clear now. 

All tracing and stack dumps which we received from our customers were 
successfully analysed.

The core "culprit" is the ASIO driver "JRiver Media Center 21" (see 
www.jriver.com/download.htm) from JRiver.

What happens is that the "JRiver Media Center 21" installs an ASIO driver which 
in fact is not an ASIO driver and does not comply
the the ASIO interface specification. As a result and due to a somehow weak 
design the ASIO SDK kit from Steinberg, the
portaudio/ASIO crashes with a protection error in the portaudio.dll. The crash 
was initiated because in libfluidsynth the
PA_Initialize is started in any case even in cases when only dsound is used but 
portaudio/ASIO is not even selected.

This does not only happen on Windows 10 but also on any other Windows platforms 
e.g. Windows 7. About Linux, Mac I do not know. It
happens with any app that uses portaudio/ASIO setup and not just with Notation 
Software.

We have downloaded "JRiver Media Center 21" in our lab and can reproduce and 
debug everthing in details where the crash happens.

I see 3 changes which need to be made:

- "JRiver Media Center 21" to be blacklisted as a non-ASIO driver. Report to 
JRiver, hopefully they fix the issues
- ASIO SDK from Steinberg needs to become more robust that it does not crash in 
case of faulty drivers
- libfluidsynth need to be enhanced that the drivers need to be dynamically 
selected - or at least optionally

In fact, these are good news. Going forward I will report the findings to the 
approriate organizations. Unfortuantely, we at
Notation Software have the high pressure to come up with a solution in the next 
days.

My view is that the libfluidsynth needs to be enhanced because it is the 
initiator of this scenario. Another reason is that such a
setup is really fragile that any faulty ASIO diver may cause other applications 
to totally crash. 

Regards,

Reinhold
  

-----Ursprüngliche Nachricht-----
Von: David Henningsson [mailto:address@hidden 
Gesendet: Donnerstag, 5. November 2015 15:28
An: address@hidden; 'FluidSynth mailing list'; address@hidden
Betreff: Re: AW: [fluid-dev] Question to fluidsynth specialists - Crash in 
"new_fluid_settings"

I'm not saying it's a good workaround - more of a quick'n'dirty hacky fix while 
we figure out what to do - but you can compile and
ship two versions of the same library. One with and one without portaudio 
support; and only load the second library in case the
customer selects portaudio in your UI.

// David

On 2015-11-05 15:13, Reinhold Hoffmann wrote:
> Hi David, hi "sqweek",
>
> Thanks for the immediate response. That was fast.
>
> Definitely, a fix of "portaudio/ASIO" and all those faulty "card 
> drivers" would be better :-) Of course, the trade-off has made sense 
> up-to-date but might be reconsidered now (??).
>
> Common to all cases (incl. those links from sqweek) is that the Pa_Initialize 
> in Portaudio fails with a crash on Win10.
> Common to all of those 3 cases which our customer report is a special used HW 
> (ASUS card, AVVID box, Cakewalk device) and Win10.
>
> We have now built a trial package for our customers which include the 
> verbose logging of libfluidsynth and of portaudio. Our customers are 
> committed to help in any way to find the issue. I expect
their logs soon.
>
> The issue which we face is, that we have customers all over the world 
> using any hardware that is possible. If a special HW driver won't 
> work, OK. But from our perspective it does not make sense that a complete 
> application crashes upon startup mostly with a
protection failure because of a niche feature which is used very rarely. (most 
just use "dsound" and are happy with that).
>
> As soon as I have feedback from our customers I will let you know, 
> potentially report a cause also in the portaudio forum.
>
> Again, thanks for the immediate feedback.
>
> Regards,
>
> Reinhold
>
>
> -----Ursprüngliche Nachricht-----
> Von: David Henningsson [mailto:address@hidden
> Gesendet: Donnerstag, 5. November 2015 11:58
> An: address@hidden; FluidSynth mailing list
> Betreff: Re: [fluid-dev] Question to fluidsynth specialists - Crash in 
> "new_fluid_settings"
>
>
>
> On 2015-11-05 10:52, Reinhold Hoffmann wrote:
>> Hi fluid-dev team,
>> We at Notation Software (see www.notation.com
>> <http://www.notation.com>) use libfluidsynth under the LGPL license.
>
> Hi Reinhold!
>
>> We have created the libfluidsynth dll libraries for "dsound" and 
>> "portaudio" where we use the Steinberg's ASIO underneath.
>> Our default setting is with the "dsound" configuration. The customer 
>> can optionally select the portaudio/ASIO settings for e.g. realtime 
>> recording.
>> We have a customer error report where the software crashes at the 
>> very first fluidsynth statement "settings = new_fluid_settings();"
>> An investigation showed that the customer uses an exotic audio card 
>> where the initialzation of the portaudio/ASIO/card driver software 
>> causes a crash for whatever reason.
>
> Certainly the better fix would be to fix portaudio/ASIO/card driver 
> then :-)
>
>> When using a libfluidsynth library  w/o portaudio support all works fine.
>> Issue:
>> =====
>> Even when only "dsound" is used, the portaudio software is started by 
>> "new_fluid_settings()" and causes that crash.
>> When the libs are statically built with #define PORTAUDIO_SUPPORT, in 
>> any case the call of "new_fluid_settings()" performs an 
>> initialization of the portaudio/ASIO/sound card through 
>> "fluid_settings_add_option (settings, "audio.driver", "portaudio")".
>
> The reason PortAudio initializes even in a call to new_fluid_settings, 
> is to fill in proper options for audio.portaudio.device. This enables the 
> user to pick from a list of devices before instantiating
the portaudio driver.
>
> This seems like a trade-off: on one side, it feels a bit unnecessary 
> to initialize portaudio (through the Pa_Initialize call) if you're not going 
> to use it, OTOH, it seems useful to have a list of
portaudio devices to choose from.
> Trying to fill that list of devices only when you have set 
> audio.driver to "portaudio" should be doable, but would require some 
> coding and I'm not sure whether or not this is a good idea, given that other 
> software using libfluidsynth might expect the values
to be filled in as they are now.
>
> What do other people think?
>
>> Solution:
>> =======
>> A fault tolerant solution should activate "fluid_settings_add_option 
>> (settings, "audio.driver", "*portaudio*")"  ONLY when portaudio is 
>> actively selected and not by default when the libs are statically 
>> built at th beginning.
>> Question:
>> =======
>> As I have not found anything in any forum whether an option exist, is 
>> there a possibility to dynamically set the "portaudio" initialization?
>> Such a solution is trivial but as mentioned we use libfluidsynth 
>> under the LGPL license and want to keep the software unchanged.
>> Does anybody can provide an advice what would be the best way to 
>> address this issue?
>> Any helpful advice is highly appreciated.
>> Best regards,
>> Reinhold
>>
>> ______________________________
>>
>>
>> *Notation Software Germany UG *
>>
>> Dr. Reinhold Hoffmann
>>
>> CEO and President
>>
>>      Eduard-Thoeny-Str. 6
>>
>> D-86919 Utting am Ammersee
>>
>> Germany
>>
>> phone +49 8806 333 9800
>>
>>    fax             +49 8806 333 9805
>>
>> mobile        +49 171 3036175
>>
>>        e-mail address@hidden <mailto:address@hidden>
>>
>> web www.notation.com <http://www.notation.com/>
>>
>> facebookwww.facebook.com/notationsoftware
>> <https://www.facebook.com/notationsoftware>
>>
>>
>>
>> _______________________________________________
>> fluid-dev mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/fluid-dev
>>
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]