In more serious news, we might get some better Wine support soon by directly talking to Linux audio drivers rather than Wine's emulation layers, which should allow for lower-latency playback on all Wine-supported platforms.
This sounds like some kind of magic, because I don't know how is this possible.
It will be done in rather the same way as Wine itself implements most Windows APIs, i.e. use Wine development tools to build a Wine DLL (roughly speaking a hybrid library that can be loaded by Win32 code running on Wine, which then itself can load and call any native library on the host system).
Work-in-progress screenshot (this will almost certainly not be in 1.26.01 though):
Anyway, dealing with linux audio drivers through wine is not a good idea. It seems that you are trying to use this strange thing called "winelib" which can generate a native binary file after the build.
Winelib is related as this is the environment the Wine DLL we build will use.
Wine wiki authors named this process " Good fluck with MFC code in wine".
Well, I'm not trying to compile OpenMPT and MFC against winelib, but just a small wrapper that deals with audio APIs. MFC may be possible, but it will be just too much work and almost certainly not worth the effort (would probably require porting OpenMPT to an even earlier MFC than VS2008, like e.g. VC6, and then fixing VC6 MFC to build against winelib) (and I think the resulting binary would not be legally distributable).
So, I still want to see a multi-platform module editor library with ability to export to files, I think it's the true future of OpenMPT.
A module editor library is possibly what might come out of an effort to split GUI from non-GUI tracker parts, which would be required for porting OpenMPT to a GUI framework other than MFC anyway. It's roughly guessing even 80% of the work that needs to be done there. Anyway, this is waaaay future work. I opened a bug at the issue tracker which lists all the issues that AT THE VERY LEAST need resolving before any of this will happen:
https://bugs.openmpt.org/view.php?id=783PROTIP: in linux, use alsa instead of pulseaudio, PA is the worst sort of crap.
Well, I politely beg to differ, as this is just FUD.
On any modern Linux desktop (this means at the very least all of Debian, Ubuntu, Suse, RedHat and all derivatives since about 10 years ago), PulseAudio is installed and correctly set up by default. What WILL cause problems in this situation, is using the ALSA emulation layer to talk to PulseAudio. Additionally, PulseAudio is the only viable solution that allows seamless switching between output devices (i.e. disconnecting your USB soundcard and continue using the internal one or even switching from ALSA to Bluetooth audio).
Supporting PulseAudio natively to provide a better out-of-the-box experience than with any Wine driver (although, since they merged wine-pulseaudio in Wine-1.8 or Wine-1.6-ubuntu, things have gotten way better than before) is the one single major goal behind the effort implementing the Wine wrapper at all.
Having said that, we will probably also support anything supported by the PortAudio library on Linux, because we are already using PortAudio on Windows for WDM-KS, WASAPI and WaveRT backends. Basically this means direct ALSA support (through PortAudio).
JACK support will be very difficult though, as the strict scheduling requirements imposed (and enforced) by jack (no blocking whatsoever in the audio callback thread) are difficult to meet in the Wine Wrapper and in OpenMPT running on Wine itself.
All of this wlll be, in the first iteration at least, Linux-only and VERY EXPERIMENTAL. FreeBSD will probably follow (because it will be rather simple).
If someone wants to buy me a somewhat modern MacMini, I'll also try implementing OSX support
.
