Commit graph

2455 commits

Author SHA1 Message Date
jjceresa
b5da68393c
Fix minor bug in windows audio driver (#680) 2020-10-04 12:39:54 +02:00
jjceresa
b55884b273
Make winmidi driver multi devices capable. (#677) 2020-09-27 14:22:56 +02:00
KO Myung-Hun
83394ab286 Define FLUIDSYNTH_API on OS/2
Previously, CMake on OS/2 exported all the symbols unconditionally. Now
it exports necessary symbols only. As a result, it's necessary to
define FLUIDSYNTH_API correctly.

Addresses #678
2020-09-24 17:59:05 +02:00
David Runge
1cc492fdb5 Set the systemd unit target to default.target
fluidsynth.service.in:
The [Install] section [1] in systemd unit declares in which target the
service will be started.
The `multi-user.target` [2] - managed by the systemd _system_ service
manager - is used in the `fluidsynth.service`.
However, as it is a _user_ unit it needs to be pulled in by the
`default.target` [3] instead, which is the main target for the user
session (as started by `user@.service` [4]).

[1] https://www.freedesktop.org/software/systemd/man/systemd.unit.html#%5BInstall%5D%20Section%20Options
[2] https://www.freedesktop.org/software/systemd/man/systemd.special.html#multi-user.target
[3] https://www.freedesktop.org/software/systemd/man/systemd.special.html#default.target1
[4] https://www.freedesktop.org/software/systemd/man/user@.service.html
2020-09-22 16:53:20 +02:00
derselbst
90ba627794 Remove a FIXME 2020-09-13 13:38:38 +02:00
derselbst
e48e48121b Remove a FIXME
Not aware of any problems caused by the old glib thread API. It will be removed sooner or later anyway.
2020-09-13 13:38:38 +02:00
derselbst
f6038ea194 Add comment into empty block 2020-09-13 13:38:38 +02:00
derselbst
dceb6e9835 Remove a FIXME
I have no clue what it refers to or what it's meant by that.
2020-09-13 13:38:38 +02:00
derselbst
c94ccdfed1 Remove a FIXME
I don't see any 'allocation' of preset. And ALL public synth functions have a mutex lock which might potentially block when called from synth context, but only then if the client app pessimizes this situation by extensively calling the synth from outside the synth context.
2020-09-13 13:38:38 +02:00
derselbst
0b8fa2e386 Remove a FIXME
I don't see any problem calling fluid_channel_init() from within synth context
2020-09-13 13:38:38 +02:00
derselbst
18fdafe37f Fix another NULL dereference
Access to field 'zone' results in a dereference of a null pointer (loaded from variable 'pr'), if size is negative. However, size should be unsigned.
2020-09-13 13:38:38 +02:00
derselbst
c4cd8bfc24 Fix a NULL dereference
Access to field 'zone' results in a dereference of a null pointer (loaded from variable 'prev_preset'), if `size` is negative. Problem is: Parameter `size` is `chunk.size` and should be unsigned.
2020-09-13 13:38:38 +02:00
derselbst
ec74ed905b Fix an impossible NULL deref 2020-09-13 13:38:38 +02:00
derselbst
7ff98227c6 Remove dead code 2020-09-13 13:38:38 +02:00
Tom M
4c1292d8ab
Remove fluid_event_any_control_change() from public API (#674)
Originally, I have only marked it deprecated. But since we have an SOVERSION bump next release and because this function was only meant for internal usage, I think it's safe to remove it right now.
2020-09-12 10:40:57 +02:00
derselbst
6776569abe Deprecate fluid_event_any_control_change() 2020-09-11 22:22:35 +02:00
Tom M
b8bd00539a
Add SonarQube and LGTM badges to README 2020-09-08 16:33:57 +02:00
Tom M
565002f34f
Add SonarQube static code analysis (#671) 2020-09-06 23:43:18 +02:00
derselbst
23b270c08b Merge branch '2.1.x' into master 2020-09-06 14:54:26 +02:00
derselbst
ff7c72c80f Bump to 2.1.5 2020-09-06 11:52:39 +02:00
jjceresa
f94cee0a50
Add multi channels support for audio driver. (#667)
This PR addresses #665.

1) Add new functions for multi channels support: `fluid_synth_write_float_channels()`, `fluid_synth_write_s16_channels()`
2) `dsound` and `waveout` driver make use of this support. tested on 2 audio devices: 
    - creative SB Live! (6 channels).
    - Realtek: ALC889A (8 channels).
2020-09-02 21:31:50 +02:00
jjceresa
57af8803f2
Mapping of fx unit output to dry buffers in mix mode. (#668)
Currently, all fx unit output (in mix mode) are mapped to the `first buffer`.
This is not appropriate for synth.audio-groups > 1

This PR allows the mapping of fx output based on `fx unit index` and `synth.audio-groups` value.
This allows us to get the `fx output `mixed to the respective  `buffer` on which a `MIDI channel` is mapped.
For example: with `synth.audio-groups = 3` and  `synth.effect-groups = 3`:
- MIDI chan 0 (dry + fx0) is mapped to buf 0
- MIDI chan 1 (dry + fx1) is mapped to buf 1
- MIDI chan 2 (dry + fx2) is mapped to buf 2
2020-09-02 21:10:31 +02:00
jjceresa
7834c4eb62 Add a chart about voice mixing and rendering 2020-09-02 20:54:05 +02:00
Tom M
aea6644324
Use a runtime check to detect version of libinstpatch (#666)
It could be that during runtime an older version of libinstpatch is used than the one fluidsynth was compiled against. In this case, libinstpatch will fail to load DLS fonts, because libinstpatch's initialization semantics don't match those compiled into fluidsynth.
2020-08-31 20:35:21 +02:00
jjceresa
c76949e6d3
Limiting audio-channels to audio-groups (#663) 2020-08-22 13:24:41 +02:00
derselbst
0acfd81e28 Merge branch '2.1.x' into master 2020-08-17 18:24:45 +02:00
derselbst
fa6f9c3570 Remove unused member variable 2020-08-17 18:23:43 +02:00
Tom M
43078d6b7b
TravisCI: add a build for GCC 4.8 (#662) 2020-08-17 18:19:15 +02:00
Fabrice Fontaine
0cccf83a38 CMakeLists.txt: fix build with gcc 4.8 (#661)
-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>
2020-08-17 18:01:39 +02:00
derselbst
4b83ee55c0 Merge branch '2.1.x' into master 2020-08-10 20:35:42 +02:00
jjceresa
3ee2bbed96 fix NULL permitted for out and fx pointer buffer
Closes #659
2020-08-10 20:33:42 +02:00
Tom M
31c4e12ac9
Update Travis CI (#658)
* update to Ubuntu Focal
* use clang10
* avoid unintentional fallbacks to  default `/usr/bin/c++` compiler
* fix related compiler warnings
2020-07-28 21:05:01 +02:00
derselbst
3c94f6366d Merge branch '2.1.x' into master 2020-07-12 13:03:59 +02:00
derselbst
277eda6bc6 Update Android Asset loader to new callback API 2020-07-12 13:03:30 +02:00
derselbst
2393aef3bd Fix printf format warnings 2020-07-12 12:55:32 +02:00
derselbst
62b715483f Merge branch '2.1.x' into master 2020-07-09 19:39:21 +02:00
derselbst
d7abe8bdfd Fix a possible race condition during midi autoconnect 2020-07-09 19:30:32 +02:00
derselbst
eac0de0345 Fix a NULL deref in jack driver 2020-07-09 19:10:11 +02:00
derselbst
85f94c61c9 Fix passing arguments from incompatible pointer type 2020-07-08 19:20:13 +02:00
derselbst
137a14e106 Turn incompatible-pointer-types warning into error 2020-07-08 19:10:53 +02:00
Tom M
031b740451
Update Doxyfile 2020-07-06 18:46:57 +02:00
derselbst
d73135fc48 Merge branch '2.1.x' into master 2020-07-05 16:32:47 +02:00
derselbst
459949a62b Bump to 2.1.4 2020-07-05 16:19:33 +02:00
derselbst
56f8f9be7c Update API docs 2020-07-05 16:15:11 +02:00
derselbst
c5293fc753 Fix an uninitialized memory access
that could possibly trigger an FPE trap for instruments that use the exclusive class generator
2020-06-28 14:58:02 +02:00
derselbst
4261848dd4 Fix regression introduced in a89399476e
Mentioned commit broke fluid_synth_start() when using a DLS soundfont.
2020-06-26 17:38:49 +02:00
Tom M
aa32da0a47
Properly handle overlapping notes when using fluid_event_note() (#637) 2020-06-15 08:38:56 +02:00
Tom M
e16ca05a58
Avoid num_samples from becoming negative (#653)
For Soundfonts bigger 2GiB, num_samples becomes negative. When being passed to safe_fread() it's promoted to long long and when being passed to fread(), it's cast to size_t. Works fine in twos-complement, but still is not nice.
2020-06-08 09:24:23 +02:00
derselbst
0354196e43 Fix typo in API docs 2020-05-27 17:26:14 +02:00
Tom M
0d98c47545
Revise the sequencer's event queue (#604)
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.
2020-05-26 17:16:22 +02:00