New PortAudio Driver

[DaAwesomeP]

Once again, after upgrading my LMMS, I had to fix the portaudio DLL to prevent it from crashing at start. Every time, I replace it with the one from here: https://code.google.com/p/portaudiosharp/.
This page says:

These bindings provide a PortAudio class which maps directly the PortAudio.dll methods, and a simplified higher-level Audio class.

This library requires .NET 2.0 or the latest version of Mono and doesn't use "unsafe" code. Should work on any platform supported by .NET or Mono, including Windows, Linux and Mac OS X.

So, why not use it? After searching this repository and Google, I find that I am not the only one with this problem. They provide the source, a debugging setup, and a pre-built DLL. The Windows compiled binary is compatible with ASIO, DS (Direct Sound), and MME (Multimedia Extensions), which is all that is really needed.

I am using Windows 8 Pro 32-bit with a horrible Sigmatel integrated laptop sound card but using Microsoft's standard "High Definition Audio" drivers. The Sigmatel ones from Dell don't work with Windows 8. I think that it is sad that LMMS does not work with the standard and most up-to-date audio drivers from Microsoft. Every other DAW program I have works fine with all three major audio drivers (ASIO, DS, and MME).

[Sti2nd]

I don't think you can use it, cause it might break something on linux, but it is worth trying perhaps? I am on Windows too, and portaudio don't work for me either, and that is why I think most Windows users use SDL.

[Sti2nd]

Are every other DAW you have also free and driven by people on their spare time? :) If you can code, it would be great with more supported audio drivers.

[tresf]

Why not use it? There are a few reasons.... 1. The license is incompatible with ours (GPL vs MIT), 2. It uses Mono/.NET which is x86-only and much different from the qt framework we use today.

It adds an unnecessary .NET/Mono requirement into our distribution (our installer would have to check for the presence of this prior to installing).

That said, if it fixes problems, terrific! Feel free to recommend it to others. There are a few tools like this that we may want to consider linking to, but they would come directly from the 3rd party site with no support from us.

The problems you are having should be fixed in our code though. These temp DLL fixes are great, but they don't address the actual problem with our code, which is the only valid part of this bug report.

[DaAwesomeP]

I now use SDL, but I cannot even launch LMMS without crashing at startup with the bad portaudio driver installed. This is mainly why I wanted it replaced.

Maybe, in Windows, at the first startup there would be a dialog asking for the audio driver of choice. It would then and only the. Load the portaudio DLL. When LMMS starts up any time after that, it would only load the required DLL (SDL in my case) when it starts to prevent crashing.

On Sep 26, 2014, at 2:10 PM, "Tres Finocchiaro" notifications@github.com wrote:

Why not use it? There are a few reasons.... 1. The license is incompatible with ours (GPL vs MIT), 2. It uses Mono/.NET which is x86-only and much different from the qt framework we use today.

It adds an unnecessary .NET/Mono requirement into our distribution (our installer would have to check for the presence of this prior to installing).

The said, if it fixes problems, terrific! Feel free to recommend it to others. There are a few tools like this the we may want to consider linking to, but they would come dorectly from the 3rd party site with no support from us.

The problems you are having should be fixed in our code though. These fixes are great, but they don't address the actual problem with our code.

—
Reply to this email directly or view it on GitHub.

[Umcaruje]

@DaAwesomeP I think the problem might be in what setting are you using in PortAudio. For example, MME never worked for me, and WASAPI worked only sometimes, not always. I too used a different portaudio DLL inside LMMS (With ASIO support in it) and ASIO was the best way to use LMMS. But the biggest problem is that it was 32bit only.

Also IIRC @tobydox compiled an ASIO suppored PortAudio a long time ago, but it couldn't be included in LMMS due to legal issues.

[DaAwesomeP]

Well, the problem is that with the included portaudio DLL, LMMS crashes at start. Even when I switch to SDL or the dummy driver, it is still loaded at startup and crashes LMMS. What I am saying now is this:

1. At the first run, a prompt will appear (before the rest of LMMS and the portaudio DLL load) asking for the audio preferences.
2. At that launch and at any launch after it, rather than loading all of the DLLs, it will just load the one specified in the preference. So, if I select SDL, it will not load the portaudio DLL as well and crash my LMMS. This also might save a miniscule amount of RAM and maybe CPU during the program start.

Lastly, is having instructions posting a link to the download page of the alternative DLL against the code license? I know that Mozilla wanted H.264 for Firefox, so the first time the codec is needed, it is downloaded from Cisco's servers and not Mozilla's (therefore not voiding the license). At startup, there could be a detection of a crash on the last launch and ask to try to download and install the alternative one.

[Sti2nd]

1. and 2, I think LMMS does that already, and that is exactly why it crashed for you. You chose portaudio the first time, and now it always loads portaudio.
   I totally understand your frustration and worry, but luckily, SDL is the (new) default chosen driver on Windows, so the new LMMS will not crash for new users :)

[tresf]

If a user cannot use the software due to an optional library, it is most certainly a bug (one we should consider major). The OP is correct, we need to handle this better. I've no idea how to debug this on Windows though.

[DaAwesomeP]

Well, I did see a screenshot that somebody had which said the actual DLL and more info in the crash message, but I'm not sure how that happened. This bug is quite popular, as I saw it numerous times.

[tresf]

This bug is quite popular

Yes, but on the contrary, debugging Windows crashes via non-Microsoft compilers is not very popular. Furthermore, the software is compiled on Linux making the debug process tricky when the bug only affects Windows.

In the case of this popular bug, it is likely to be a specific device driver causing the crash. If we had the specific information about this we may be able to isolate the cause and provide a fix. Without that info, the best we can do is have better recovery when the crash does occur.

[DaAwesomeP]

I am using Microsoft's standard "High Definition Audio Driver." I do not have a driver from Dell for Windows 8 because Sigmatel went out of buissness a while ago. So, I am forced to use the default. I wonder if using WINE tweaked to the right settings could replicate the issue as well. I would be happy to experiment with that when I have time.

-------- Original message --------

From: Tres Finocchiaro notifications@github.com

Date:09/28/2014 9:32 PM (GMT-06:00)

To: LMMS/lmms lmms@noreply.github.com

Cc: P THE AWESOME p2kwolfgang@live.com

Subject: Re: [lmms] New PortAudio Driver (#1173)

This bug is quite popular

Yes, but on the contrary, debugging Windows crashes via non-Microsoft compilers is not very popular. Furthermore, the software is compiled on Linux making the debug process tricky when the bug only affects Windows.

In the case of this popular bug, it is likely to be a specific device driver causing the crash. If we had the specific information about this we may be able to isolate the cause and provide a fix. Without that info, the best we can do is have better recovery when the crash does occur.

—
Reply to this email directly or view it on GitHub.

[tresf]

I am using Microsoft's standard "High Definition Audio Driver." I do not have a driver from Dell for Windows 8 because Sigmatel went out of buissness a while ago. So, I am forced to use the default. I wonder if using WINE tweaked to the right settings could replicate the issue as well. I would be happy to experiment with that when I have time

When I had similar issues, it was actually the vendor supplied driver that caused it, not the Microsoft supplied none.

Interestingly enough wine allows DLL overrides, so this may be very well reproducible on wine. Anything you can do to help debug this issue would be of value.

[tresf]

I'm tagging this as an enhancement because I think the underlying problem -- better hardware and driver compatibility -- is something we have some room to improve on...

Edit: Cross-link: #1865 (comment)