In my case this is because of issue #985, but there's also the use case of being able to test without OpenMP. For example, to disable it on my system in order to test if the crash had anything to do with OpenMP, I had to manually edit `CMakeLists.txt` each time I wanted to turn it off and on again.
* FluidSynthConfigVersion.cmake is created with ${VERSION} instead of
${LIB_VERSION_INFO}
* FluidSynthConfig.cmake.in simplified: it doesn't need to include the
version file.
* Simplified BUILD_INTERFACE generator expression as suggested
The build system creates two exported targets:
- The executable FluidSynth::fluidsynth
- The library FluidSynth::libfluidsynth
A downstream project using CMake can find and link the library target
directly with cmake (without needing pkg-config) this way:
~~~
project(sample LANGUAGES C)
find_package ( FluidSynth )
if (FluidSynth_FOUND)
add_executable( sample sample.c )
target_link_libraries ( sample PRIVATE FluidSynth::libfluidsynth )
endif ()
~~~
After installing fluidsynth in a prefix like "$HOME/Fluidsynth3":
cmake -DCNAKE_PREFIX_PATH="$HOME/Fluidsynth3/;..."
Instead installing, the build directory can be used directly, for
instance:
cmake -DFluidSynth_DIR="$HOME/fluidsynth-2.2.2/build/" ...
Previously, cmake only tested for a specific version of libsndfile and then assumed, it has OGG/Vorbis support. However, libsndfile may still be compiled without OGG/Vorbis support. If this is the case, fluidsynth should refuse to load SF3 files. Otherwise the attempt to load SF3 files would fail with a bunch of error messages.
The solution of this PR proposes to lookup the private libs listed in sndfile.pc and see whether it includes "vorbis".
This driver is currently tested and verified to work on:
- Windows Vista x64 VM
- Windows 7 x64 VM
- Windows 10 1909 x64 (VM and Laptop)
- Windows 10 21296 x64 on a ThinkPad X1 Yoga 1st Gen with 3 different sound cards (Conexant CX20753/4, Scarlett Solo Gen 2, Aureon 7.1 USB)
This driver is capable of reaching very low latency in exclusive mode (~6ms on Scarlett Solo with 48kHz).
While `fopen` (used through the macro `FLUID_FOPEN`) uses UTF-8 on *nix, it's restricted to ANSI on Windows. A change to enable using paths containing non-ANSI characters was suggested before in issue #128 but was rejected due to requiring large parts of both the public API and private implementation to be modified to accommodate Windows.
This PR instead changes the macro definition for `FLUID_FOPEN` from `fopen` to a new wrapper, `fluid_fopen`. This wrapper is defined in `fluidsynth_priv.h` and defined in `fluid_sys.c` (following the pattern of `fluid_alloc`). Under Windows, it converts the `const char*` UTF-8 parameters to Unicode `wchar_t*` strings using the Windows API function `MultiByteToWideChar` and opens the file using the Windows API-specific `_wfopen`. On all other platforms, it simply calls `fopen`.
The public API is unchanged. This solution will require Windows users of the API to convert UTF-16 strings to UTF-8 (which then get converted back into UTF-16 anyway), but that's still an improvement over only being able to use ANSI paths.
This PR also adds a new test, `test_utf8_open`, which tests `FLUID_FOPEN` directly and through `fluid_is_soundfont` and `fluid_synth_sfload` using a new soundfont file, `sf2/■VintageDreamsWaves-v2■.sf2`, which is just a copy of `VintageDreamsWaves-v2.sf2` with Unicode characters in the filename.
-Werror=incompatible-pointer-types is unconditionally used since version
2.1.4 and 137a14e106. This will raise a
build failure when checking for threads on gcc 4.8:
/home/buildroot/autobuild/run/instance-3/output-1/host/bin/arm-none-linux-gnueabi-gcc --sysroot=/home/buildroot/autobuild/run/instance-3/output-1/host/arm-buildroot-linux-gnueabi/sysroot -DTESTKEYWORD=inline -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -Wall -W -Wpointer-arith -Wcast-qual -Wstrict-prototypes -Wno-unused-parameter -Wdeclaration-after-statement -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -Wbad-function-cast -Wcast-align -DNDEBUG -fPIE -o CMakeFiles/cmTC_98946.dir/CheckIncludeFile.c.o -c /home/buildroot/autobuild/run/instance-3/output-1/build/fluidsynth-2.1.4/CMakeFiles/CMakeTmp/CheckIncludeFile.c
cc1: error: -Werror=incompatible-pointer-types: no option -Wincompatible-pointer-types
Fixes:
- http://autobuild.buildroot.org/results/13cbba871db56ef8657a3d13c6ac8e1b4da0d244
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Proposing a new event queue for the sequencer, based on prior discussion:
https://lists.nongnu.org/archive/html/fluid-dev/2019-12/msg00001.html
With this change fluidsynth will require a C++98 compliant compiler.
Consider this as RFC, feedback is welcome.
The "pain-points" from the discussion:
#### 1. It is slow.
Done (thanks to heap sort), see runtime of `test_seq_event_queue_sort`.
#### 2. A meaningful ordering for events with the same tick has not been considered.
Done, see comments in `fluid_seq_queue.cpp`.
#### 3. Complicated implementation
Now uses one single event queue, which requires C++98. Implemented similarly to std::priority_queue by using heap sort.
The "queue" I use currently is of type `std::deque`. `deque` does not provide preallocation. `std::vector` does provide it. However, `std::deque` has the huge advantage that appending additional elements is cheap. For `std::vector` appending new elements would require to reallocate all the memory and copy it to the new array. So,
* either use `std::deque` with the risk that memory allocation may occur during `fluid_sequencer_send_at()`, or
* use `std::vector` with a preallocated pool of events and make `fluid_sequencer_send_at()` when the `vector` runs out of capacity.
Comments?
#### 4. Events that have been processed are deleted and gone.
After having thought about this more, this is the correct behavior. After events have been dispatched, they must be released to free underlying memory, see point 3. For the very rare case that a client (e.g. fluid_player) may require those events in the future, the client should be responsible for storing the events somewhere.
#### 5. The sequencer supports the system timer as alternative time source.
The conclusion from the mailing list was that the system timer can be removed. This has been done.
#### 6. Time Scaling
Time scaling can now be used for arbitrary tempo changes. The previous implementation was capable of that as well, however, the time-scale was limited to 1000. The only limitation for the scale is now >0, see `test_seq_scale`.
### Other Points
* `fluid_sequencer_remove_events()` turned out to be broken before, as it did not remove all events from the queue. This has been fixed, see `test_seq_event_queue_remove`.
* Consider the following code executed by `threadA`:
```c
fluid_sequencer_send_at(event0);
fluid_sequencer_set_time_scale(); // new scale
fluid_sequencer_send_at(event1);
```
The new scale will be definitely applied to `event1`. However, if another concurrently running `threadB` executes `fluid_sequencer_process()`, it was previously not clear, whether the new scale was also applied to event0. This depends on whether `event0` was still in the `preQueue`, and this depends on `event0.time` and the tick count that `fluid_sequencer_process()` is being called with. This has been changed. As of now, events are queued with their timestamp AS-IS. And only the latest call to `fluid_sequencer_set_time_scale()` is being considered during `fluid_sequencer_process()`. This makes the implementation very simple, i.e. no events need to be changed and the sequencer doesn't have to be locked down. On the other hand, it means that `fluid_sequencer_set_time_scale()` can only be used for tempo changes when called from the sequencer callback. In other words, if `threadA` executes the code above followed by `fluid_sequencer_process()`, `event0` and `event1` will be executed with the same tempo, which is the latest scale provided to the seq. Is this acceptable? The old implementation had the same limitation. And when looking through the internet, I only find users who call `fluid_sequencer_set_time_scale()` from the sequencer callback. Still, this is a point I'm raising for discussion.
Since sizeof(long) == 4 even on 64 bit Windose, big files cannot be
loaded natively via the ANSI C file API. This change makes fluidsynth's
file callback API use long long, which is guaranteed to be at least 64
bit wide.
