WavPack support

[sezero]

This is initial WavPack support for SDL_mixer.

@dbry: Can you browse it briefly for any possible gotchas, please ?

NOTES:

• Tested on i686-linux, against wavpack library versions 4.60 and 5.6.0.

• libwavpack 5.x functions are used if they are found, with fallback to libwavpack 4.x functions (which cannot handle large files.)

• libwavpack.so is always versioned as libwavpack.so.1, regardless of version 4.x or 5.x, therefore the v4.x fallback is necessary.

• For simplicity, audio data is sent to SDL_AudioStream as AUDIO_S32SYS or AUDIO_F32SYS: SDL is responsible for conversion.

• See down below for correction file loading limitations

TODO:

• Handle DSD WavPack files: @dbry: I may need help with that.

• Cmake integration: I only did autotools, won't cmake myself. (@madebr to rescue.)

• Visual Studio and Xcode project file updates will be needed later.

• Channel mapping for wavpack files with more than 2 chs: More like a job for @icculus and/or @slouken (i.e.: won't do myself.)

• There are official windows builds of wavpack dll which however is not named libwavpack.dll or libwavpack-1.dll, but actually is named wavpackdll.dll: I didn't handle such dll use in autotools or the source code, so it should be handled if so needed (I won't do that myself.)

How to test: Apart from running wavpack on existing wav files, there is a wavpack test suite (174MB) with several wavpack files which is useful: http://www.rarewares.org/wavpack/test_suite.zip

Closes: https://github.com/libsdl-org/SDL_mixer/issues/382

[madebr]

We need to create a wavpack fork in the libsdl-org organization, and keep it to date with upstream. Once that's done, I'll handle the cmake bits.

[sezero]

We need to create a wavpack fork in the libsdl-org organization, and keep it to date with upstream. Once that's done, I'll handle the cmake bits.

WavPack fork created, with a 5.6.0-sdl branch.

[sezero]

Implemented correction file loading as of commit 8b34106c34fd6b06bfd9f975b52e798bea326f3c. Limitations are, as noted in the commit message:

• The file must be loaded with Mix_LoadMUS, not Mix_LoadMUS_RW.

• Mix_Init must be called with MIX_INIT_WAVPACK flag beforehand.

Another solution would be adding a wavpack-specific loader function to the api, which I don't like.

If anyone has a better solution, I am all ears. On the other hand, the files I tried sounded pretty fair without their correction file present, but I'm not an audiophile either.

[sezero]

As it is now, I think I did all I could with this: We can merge, preferably after cmake work is done.

Remaining stuff are the TODO items listed at top of the PR. In particular, DSD loading is disabled for now - I need help with it. Adding OPEN_DSD_AS_PCM to WavpackOpenFileInputEx64 flags will work, but the result will be accompanied with an unacceptable hiss. Can be done after merge, I guess, unless someone does it here.

[madebr]

I need to push a little fix to wavpack's cmake script, but don't have push access rights.

[sezero]

I need to push a little fix to wavpack's cmake script, but don't have push access rights.

You should have admin rights now along with all @libsdl-org/a-team members

[sezero]

Waiting for any further reviews. If nothing shows up, I can merge after about two days.

[sezero]

@madebr: One minor thing which seems to be missing in cmake: In autotools, I check for <wavpack.h> and define HAVE_WAVPACK_H if it's found. It affects how wavpack.h is included, i.e. <wavpack/wavpack.h> vs <wavpack.h>. I don't think there are any new installations without wavpack/ include subdirectory, but I did it anyway. (And we can live without it in cmake, but wanted to mention anyway..)

[madebr]

@madebr: One minor thing which seems to be missing in cmake: In autotools, I check for <wavpack.h> and define HAVE_WAVPACK_H if it's found. It affects how wavpack.h is included, i.e. <wavpack/wavpack.h> vs <wavpack.h>. I don't think there are any new installations without wavpack/ include subdirectory, but I did it anyway. (And we can live without it in cmake, but wanted to mention anyway..)

I made Findwavpack.cmake such that it returned the folder containing wavpack.h, so you could always do #include <wavpack.h>. But it looks like an installed wavpack-config.cmake required #include <wavpack/wavpack.h>. Thus now a vendored wavpack needs #include <wavpack.h> and a system one #include <wavpack/wavpack.h>.

[sezero]

I made Findwavpack.cmake such that it returned the folder containing wavpack.h, so you could always do #include <wavpack.h>. But it looks like an installed wavpack-config.cmake required #include <wavpack/wavpack.h>. Thus now a vendored wavpack needs #include <wavpack.h> and a system one #include <wavpack/wavpack.h>.

OK, that's good.

[sezero]

This is now in.