Recent Posts

Pages: 1 ... 8 9 [10]
91
Compatibility with different Wine versions should in fact not be a problem.
However, there are a couple of other problems:
  • The way we use 2 libraries (which is absolutely required to keep the code maintainable and extendible) requires hard-coding the library path of the .so in the .dll. That path is user-specific and even runtime dependent on environment variables.
  • Providing binaries would require different binaries for different system setups. In the past, you often stated that you do not want PulseAudio on your system. If we provided binaries, these would drag in PulseAudio (and PortAudio and DBus) as a dependency for you OR we would have to implement dynamic on-demand loading for these libraries which would increase the maintenance overhead considerably.
Thus, the effort to make binaries would require: #distributions (because of different settings in the distribution default C++ ABI used by the native .so library) * #configurations * #platforms. The distributions amount to about 2 stable Debian versions, Debian testing, 2 stable Ubuntu LTS versions, the latest Ubuntu non-LTS, latest Fedora, latest OpenSuse, probably latest Arch and Gentoo, which amounts to about 10 systems I would have to maintain to actually build those, let alone actually test them. There are about 2^3 configurations and 3 platforms (i568, i686+SSE2, x86-64). This results in 10*8*3 = 240 packages. I wont do that. Ever.
Also consider that we only have about 5% users on Wine (of which (I am guessing here because we do not have these numbers) about 50% are using Linux) of which (even more guessing) at best 10% would even be using the Wine integration feature at all. Providing packages for about 0.25% of the users is not worth the effort.

Also, what aspect of building the libraries is difficult?
We only require packages in the stock distribution repository.
Installing binary packages would require users either to setup an additional package repository in their package manager or install the OpenMPT Wine integration packages by hand.
92
It's not really feasible to provide pre-built binaries for the n different Linux distributions times m different Wine versions out there. If you have problems with the feature (if so, please post them), those would most likely also exist with pre-built binaries.

Such wine libraries should be compatible with different wine versions (ex. wineasio works well). The process of building a wine library is very complicated for users.
That's why we should have built-in binaries.
93
It's not really feasible to provide pre-built binaries for the n different Linux distributions times m different Wine versions out there. If you have problems with the feature (if so, please post them), those would most likely also exist with pre-built binaries.
94
We also need prebuilt binaries.  ;)
95
What?

As kind of a for-fun project, I implemented native sound output for OpenMPT when running on Wine on Linux. The first version to have it is 1.27.00.34 r7701 as of 2017-02-26. It has only been tested on the following system setups so far:
  • Debian 8, x86-64, wine 1.6.2 (wine, wine32-tools)
  • Debian 8, x86-64, wine-development 1.7.29 (wine-development, wine64-development-tools)
  • Ubuntu 14.04 x86-64, wine 1.6.2 (wine, wine-1.6-dev)
  • Ubuntu 16.04 i686, wine-development 1.9.6 (wine-development, libwine-development-dev)
This means, that OpenMPT can now, as an EXPERIMENTAL feature, completely bypass the emulation of Windows sound drivers as implemented in Wine, and instead talk to the native Linux APIs directly.
In its current form, only support for PulseAudio and PortAudio is implemented.
Support for PulseAudio currently still uses the "Simple API" which is suboptimal for the features that OpenMPT wants to use. This will be improved to use the full API in a later OpenMPT version.
Support for PortAudio is probably final in its current form and is no high priority. PortAudio itself can, in particular, talk to ALSA devices directly. PortAudio can also talk to JACK, but this has not been tested at all in OpenMPT and very probably does not work correctly yet.
In addition to using native Linux sound APIs, OpenMPT can now also boost the thread priority, which was not possible at all when using the standard Windows APIs as emulated by Wine. OpenMPT can use both, Linux Realtime Scheduling priorities directly as well as setting system-defined priorities through RealtimeKit. The way OpenMPT chooses between these 2 ways is the way recommended by the Linux Audio Developers community.


How?

Using Wine integration in OpenMPT has various requirements on the host system:
  • OpenMPT bitness must be the same as host system bitness, i.e. use OpenMPT 32bit on i686 and OpenMPT 64bit on x86-64.
  • On Debian or Ubuntu (and derivates), the following packages must be installed: coreutils dialog make pkg-config cpp gcc g++ binutils ccache xterm.
  • Additionally, the Wine developments headers and tools must also be installed. These are called completely different but similarly looking names on various distributions. See the list of tested systems for hints on what package names to look out for.
  • The following packages need optionally be installed: libpulse-dev (for PulseAudio), libjack-jackd2-dev and portaudio19-dev (for PortAudio), libdbus-1-dev (for RealtimeKit)
  • Other distributions should also work, but you have to figure out the required packages yourself.

In order to enable Wine integration, go to the Wine options tab (the tab is only shown if OpenMPT actually detected Wine), check the checkbox and restart OpenMPT. Additional settings are available under Advanced settings in the WineSupport section. For most of these settings, you need to restart OpenMPT for them to take effect.


If OpenMPT Wine integration is enabled, OpenMPT will compile the required library adapters for your system on startup itself. It will spawn a terminal window and show a progress bar while doing so. Please do not be scared or surprised when you see the terminal window popping up. Starting native host applications from within a Windows application running on Wine is officially supported behaviour of Wine. If all works fine, native sound devices will be listed in the Sound Card settings.



Technical Details

2 shared libraries are compiled by OpenMPT. The required source code is distributed with OpenMPT in the file openmpt-wine-support.zip and must match the OpenMPT version exactly.


openmpt_wine_support.dll gets placed below AppData/ in the Wine environment. This is a Wine DLL, which will be loaded by OpenMPT and used as a proxy to call to the system native library libopenmpt_native_support.so.
libopenmpt_native_support.so gets placed below $XDG_DATA_HOME/ on the host system. The shared library is a host-native library that implements the OpenMPT sound device API on top of the PulseAudio or PortAudio libraries provided by the host system.

OpenMPT will recompile these libraries as required and cache the result such that starting the exact same version of OpenMPT again does not require recompiling.
96
Development Corner / Re: GIT mirror and SVN repository cleanup
« Last post by manx on February 24, 2017, 22:27:21 »
GIT mirror is up and running with automated updates at https://github.com/OpenMPT/openmpt.

Warning: This repository may still get its history rewritten without any further notice while we are setting up the mirroring infrastructure. Be sure to rebase often in case you clone or fork it.

Building from git is also not yet supported (in particular, at least, the version number will be inaccurate).
97
Updated statistics as of 2017-02-21:

Windows versions:

      Windows 98    0 %   #
      Windows ME    0 %   

     Windows NT4    0 %   

    Windows 2000    0 %   #
      Windows XP    3 %   #####
  Windows XP x64    0 %   #

   Windows Vista    1 %   ##
       Windows 7   30 %   ##############################################
       Windows 8    1 %   ##
     Windows 8.1    7 %   ###########

      Windows 10   55 %   ##################################################################################

            Wine    3 %   ######

Wine versions broken down:

    wine-unknown    2 %   ####

      wine-1.0.0    0 %   #

      wine-1.4.0    0 %   #

      wine-1.6.1    2 %   ###
      wine-1.6.2   34 %   ####################################################

      wine-1.7.0    0 %   #
     wine-1.7.37    1 %   ##
     wine-1.7.39    0 %   #
     wine-1.7.46    0 %   #
     wine-1.7.49    0 %   #
     wine-1.7.52    0 %   #
     wine-1.7.55    1 %   ##
      wine-1.8.0    4 %   #######
      wine-1.8.1    0 %   #
      wine-1.8.3    1 %   ##
      wine-1.8.4    2 %   ####
      wine-1.8.5    4 %   #######
      wine-1.8.6    4 %   ######

      wine-1.9.0    0 %   #
     wine-1.9.11    0 %   #
     wine-1.9.16    1 %   ##
     wine-1.9.17    0 %   #
     wine-1.9.18    2 %   ####
     wine-1.9.19    0 %   #
     wine-1.9.20    2 %   ###
     wine-1.9.21    2 %   ####
     wine-1.9.22    1 %   ##
     wine-1.9.23    5 %   #########
     wine-1.9.24    4 %   #######
     wine-2.0-rc    0 %   #
    wine-2.0-rc4    0 %   #
        wine-2.0    0 %   #
      wine-2.0.0   19 %   #############################

      wine-2.1.0    3 %   #####

The numbers are rounded half up, and the bars are rounded up (thus even a single user will always display a tiny bar).
Statistics account for systems we have seen over the last 3 month period.
98
It's worth mentioning that most relevant Linux desktop distributions ship with Wine 1.6 these days, and the Wine project also offers their own, always up-to-date repository for many distributions.
99
Testing on an ancient Ubuntu 12.04 system with Wine 1.4 revealed that binaries compiled with Visual Studio 2015 actually do not work on Wine 1.4. Thus, contrary to the original plan, OpenMPT 1.27 will also remove support for Wine 1.4 and Wine 1.5.
The original post has been modified accordingly.
100
Help and Questions / Re: Passing midi messages from one vst to another
« Last post by Exhale on February 20, 2017, 19:20:47 »
Epic, thank you on behalf of anyone else who will be using it too, amazing response.
Pages: 1 ... 8 9 [10]