Discussion:
[fluid-dev] fluid-dev Digest, Vol 179, Issue 8
Christopher Leger
2018-06-13 05:37:48 UTC
Permalink
How would I be sure my program has realtime prio? I tried running the
program with sudo nice --20 and also tried setting midi.realtime-prio to
99. I also tried changing the synth.cpu-cores to be 4 since my RPi has 4
cores. Oddly enough this only seemed to work when using the stock
fluidsynth, not the program that I wrote. I can tell if there are actually
4 processes being generated by looking at top and I only see 4 processes in
the stock fluidsynth vs. the program that I wrote there is still 1 even
when I set this setting.

I was able to get my keyboard hooked up to alsa_seq using JACK but the
problem was still there.

I also cloned the 1.1.x branch and compiled it but I am still having the
same problem.

And thanks for the info jjc, I am sure that an event is just being missed
for some reason. Yes, I realized that noteoff is the same as noteon with
velocity 0 when I saw that some midi files only have noteon events.

-Chris
Send fluid-dev mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.nongnu.org/mailman/listinfo/fluid-dev
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of fluid-dev digest..."
1. Re: Intercepting midi events (Tom M.)
2. Re: Intercepting midi events (Ceresa Jean-Jacques)
----------------------------------------------------------------------
Message: 1
Date: Fri, 08 Jun 2018 06:27:22 +0200
Subject: Re: [fluid-dev] Intercepting midi events
Content-Type: text/plain; charset="us-ascii"
Make sure your app actually has permission to run fluidsynth in realtime
prio.
Try using a different midi driver, like hooking up alsa_raw through jack.
(compiled from the original git source code)
Try stable 1.1.11.
Tom
------------------------------
Message: 2
Date: Fri, 8 Jun 2018 15:03:05 +0200 (CEST)
Subject: Re: [fluid-dev] Intercepting midi events
Content-Type: text/plain; charset="utf-8"
Hello Chris,
?
?
When I am jamming away on a lot of keys at one time on the keyboard it
seems to sometimes miss midi noteon or noteoff events...
It also happens that some notes don't turn on sometimes....
?
I verified this by adding an error printout to my program to detect
noteoff events for notes that are already off and noteon events for notes
that are already on.
Be aware that when releasing a key, we cannot predict that a noteoff
message will be generated. Most MIDI keyboard (low and medium cost) send a
MIDI noteon with velocity set to 0.
?
So as it seems that there is a lost of messages (noteon, and noteoff)
somewhere in the path between your MIDI keyboard and the
the MIDI driver output (i guess you use a MIDI keyboard).
The first thing to do is to verify that your keyboard send a MIDI message
when a key is depressed, and another MIDI message when a key is released.
To do this check , we can simply print? "MIDI message received" (
regardless of the type of MIDI message !) in your intercept() function.
?
int intercept(void* data, fluid_midi_event_t* event)
{
? printf(MIDI message received\n");
? return fluid_synth_handle_midi_event((fluid_synth_t*) data, event);??
}
?
?
Requested a period size of 64, got 256 instead"
I don't think this would be related to not receiving midi events right??
?
Right, this is only related to the audio driver that said that actually
you have requested a period size of 64 (audio.period-size=64) and it this
value is not possible so the driver had raised the buffer size to 256.
Generally using RPi we get this message when using the default RPI audio
card (on 3,5 jack output). This audio card is a PWM device and doesn't
allow low latency. In this case we need to set audio.period-size= 1024
minimum otherwise we get a distorded output. Also, this kind of audio card
is really poor quality. All this is true for RPi 2. For RPi 3, i don't
know but i am looking forward for your report, thanks.
?
jjc.
Message du 08/06/18 05:21
De : "Christopher Leger"
A : "Tom M."
Copie ? : "FluidSynth mailing list"
Objet : Re: [fluid-dev] Intercepting midi events
Thanks Tom for realizing my very stupid mistake! I've made some changes
and I have got almost everything working how I wanted it to.
However, I have one issue and this problem happens only when I am running
Fluidsynth on my Raspberry Pi 3. When I am jamming away on a lot of keys at
one time on the keyboard it seems to sometimes miss midi noteon or noteoff
events. I know this because when running Fluidsynth (compiled from the
original git source code) if I set the midi channel to an organ and I press
a lot of keys and I pull away my hands one or two notes will still be
sustaining. It also happens that some notes don't turn on sometimes.
I verified this by adding an error printout to my program to detect
noteoff events for notes that are already off and noteon events for notes
that are already on. Sure enough I get? one of these error printouts when I
hear an issue.?
I checked with top and the PI has plenty of memory and cpu power available
fluidsynth: warning: Requested a period size of 64, got 256 instead
I don't think this would be related to not receiving midi events right??
Any suggestions?
Thanks for the help,
-Chris
#include "fluid_midi.h"
#include "fluid_sfont.h"
I will never understand why people keep including fluidsynths private
headers. And I'm so tired of repeating that this way of programming is
undefined behaviour as there is no API / ABI stability guarantee for
internal data types and functions. That's why there are accessor functions
of all kinds.
new_fluid_midi_driver(settings, intercept, NULL);
You bascially asked for the synth instance being NULL. Have you read the
API doc of new_fluid_midi_driver() ?
http://www.fluidsynth.org/api/midi_8h.html#ad0971af69fb51398d468b151cba70bee
Also you are deleting the synth before deleting the midiDriver. This
will cause the midiDriver to call a deleted synth instance. You must always
cleanup all objects exactly in the reverse order you've created them.
And your `fluid_midi_driver_t* midiDriver` will be uninitialized if any
of the `goto cleanup` happens.
Tom
_______________________________________________
fluid-dev mailing list
https://lists.nongnu.org/mailman/listinfo/fluid-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.nongnu.org/archive/html/fluid-dev/attachments/20180608/b5698df7/attachment.html
------------------------------
Subject: Digest Footer
_______________________________________________
fluid-dev mailing list
https://lists.nongnu.org/mailman/listinfo/fluid-dev
------------------------------
End of fluid-dev Digest, Vol 179, Issue 8
*****************************************
Ceresa Jean-Jacques
2018-06-13 14:22:30 UTC
Permalink
Hi Chris.

 

My thoughts

 
I also tried changing the synth.cpu-cores to be 4 since my RPi has 4 cores.
Using 4 cores allows fluidsynth audio engine to start 4 threads. The global cpu load will be divided by 4. In others words, the engine will be able to generate 4 more voices than using only one core.

 

Using Fluidsynth with only one core a Ppi zero is able to run 60 voices maximum (i.e using 100% cpu load). Using Rpi 3 with synth.cpu-cores = 1, i guess you should expect the same result.

This allows to play 60 notes of organ (prog 17 ,GUGSv1_47.sf2) at the same time (because this organ use only one voice by note).
prof_set_notes 50
prof_start 4 1000
"Estimated maxVoices" display the maximum voices your Rpi 3 is able.

 
I can tell if there are actually 4 processes being generated by looking at top and I only see 4 processes in the stock fluidsynth vs. the program that I wrote there is still 1 even when I set this setting.
Notes that the four threads runs in the context of only one process (i.e fluidsynth process). So even if synth.cpu-core is > 1 you should only see only one fluidsynth process. If you see

more that one fluidsynth process, that means that you have lauched fluidsynth executable more time. Please kill these unnecessary process.

 

2) > Oddly enough this only seemed to work when using the stock fluidsynth, not the program that I wrote.
I also cloned the 1.1.x branch and compiled it but I am still having the same problem.
Great to know you have used the fluidsynth console without lost of MIDI messages. That means that your MIDI keyboard works fine.

You means probably that the program you wrote is the only one that lost MIDI messages ?. From there hard to see where is the issue !

jjc
Message du 13/06/18 07:38
De : "Christopher Leger"
A : "FluidSynth mailing list"
Objet : Re: [fluid-dev] fluid-dev Digest, Vol 179, Issue 8
How would I be sure my program has realtime prio? I tried running the program with sudo nice --20 and also tried setting midi.realtime-prio to 99. I also tried changing the synth.cpu-cores to be 4 since my RPi has 4 cores. Oddly enough this only seemed to work when using the stock fluidsynth, not the program that I wrote. I can tell if there are actually 4 processes being generated by looking at top and I only see 4 processes in the stock fluidsynth vs. the program that I wrote there is still 1 even when I set this setting.
I was able to get my keyboard hooked up to alsa_seq using JACK but the problem was still there.
I also cloned the 1.1.x branch and compiled it but I am still having the same problem. 
And thanks for the info jjc, I am sure that an event is just being missed for some reason. Yes, I realized that noteoff is the same as noteon with velocity 0 when I saw that some midi files only have noteon events.
-Chris
On Fri, Jun 8, 2018 at 12:06 PM wrote:
Send fluid-dev mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.nongnu.org/mailman/listinfo/fluid-dev
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of fluid-dev digest..."
   1. Re: Intercepting midi events (Tom M.)
   2. Re: Intercepting midi events (Ceresa Jean-Jacques)
----------------------------------------------------------------------
Message: 1
Date: Fri, 08 Jun 2018 06:27:22 +0200
From: "Tom M."
To: Christopher Leger
Cc: FluidSynth mailing list
Subject: Re: [fluid-dev] Intercepting midi events
Content-Type: text/plain; charset="us-ascii"
Make sure your app actually has permission to run fluidsynth in realtime prio.
Try using a different midi driver, like hooking up alsa_raw through jack.
(compiled from the original git source code)
Try stable 1.1.11.
Tom
------------------------------
Message: 2
Date: Fri, 8 Jun 2018 15:03:05 +0200 (CEST)
From: Ceresa Jean-Jacques
To: FluidSynth mailing list ,     "Tom M."
       
Cc: FluidSynth mailing list
Subject: Re: [fluid-dev] Intercepting midi events
Content-Type: text/plain; charset="utf-8"
Hello Chris,
?
?
When I am jamming away on a lot of keys at one time on the keyboard it seems to sometimes miss midi noteon or noteoff events...
It also happens that some notes don't turn on sometimes....
?
I verified this by adding an error printout to my program to detect noteoff events for notes that are already off and noteon events for notes that are already on.
Be aware that when releasing a key, we cannot predict that a noteoff message will be generated. Most MIDI keyboard (low and medium cost) send a MIDI noteon with velocity set to 0.
?
So as it seems that there is a lost of messages (noteon, and noteoff) somewhere in the path between your MIDI keyboard and the
the MIDI driver output (i guess you use a MIDI keyboard).
The first thing to do is to verify that your keyboard send a MIDI message when a key is depressed, and another MIDI message when a key is released.
To do this check , we can simply print? "MIDI message received" ( regardless of the type of MIDI message !) in your intercept() function.
?
int intercept(void* data, fluid_midi_event_t* event)
{
? printf(MIDI message received\n");
? return fluid_synth_handle_midi_event((fluid_synth_t*) data, event);??
}
?
?
The only warning fluidsynth prints out is this: "fluidsynth: warning: Requested a period size of 64, got 256 instead"
I don't think this would be related to not receiving midi events right??
?
Right, this is only related to the audio driver that said that actually you have requested a period size of 64 (audio.period-size=64) and it this
value is not possible so the driver had raised the buffer size to 256.
Generally using RPi we get this message when using the default RPI audio card (on 3,5 jack output). This audio card is a PWM device and doesn't
allow low latency. In this case we need to set audio.period-size= 1024 minimum otherwise we get a distorded output. Also, this kind of audio card
is really poor quality. All this is true for RPi 2. For RPi 3, i don't know but i am looking forward for your report, thanks.
?
jjc.
Message du 08/06/18 05:21
De : "Christopher Leger"
A : "Tom M."
Copie ? : "FluidSynth mailing list"
Objet : Re: [fluid-dev] Intercepting midi events
Thanks Tom for realizing my very stupid mistake! I've made some changes and I have got almost everything working how I wanted it to.
However, I have one issue and this problem happens only when I am running Fluidsynth on my Raspberry Pi 3. When I am jamming away on a lot of keys at one time on the keyboard it seems to sometimes miss midi noteon or noteoff events. I know this because when running Fluidsynth (compiled from the original git source code) if I set the midi channel to an organ and I press a lot of keys and I pull away my hands one or two notes will still be sustaining. It also happens that some notes don't turn on sometimes.
I verified this by adding an error printout to my program to detect noteoff events for notes that are already off and noteon events for notes that are already on. Sure enough I get? one of these error printouts when I hear an issue.?
fluidsynth: warning: Requested a period size of 64, got 256 instead
I don't think this would be related to not receiving midi events right??
Any suggestions?
Thanks for the help,
-Chris
#include "fluid_midi.h"
#include "fluid_sfont.h"
I will never understand why people keep including fluidsynths private headers. And I'm so tired of repeating that this way of programming is undefined behaviour as there is no API / ABI stability guarantee for internal data types and functions. That's why there are accessor functions of all kinds.
new_fluid_midi_driver(settings, intercept, NULL);
You bascially asked for the synth instance being NULL. Have you read the API doc of new_fluid_midi_driver() ?
http://www.fluidsynth.org/api/midi_8h.html#ad0971af69fb51398d468b151cba70bee
Also you are deleting the synth before deleting the midiDriver. This will cause the midiDriver to call a deleted synth instance. You must always cleanup all objects exactly in the reverse order you've created them.
And your `fluid_midi_driver_t* midiDriver` will be uninitialized if any of the `goto cleanup` happens.
Tom
_______________________________________________
fluid-dev mailing list
https://lists.nongnu.org/mailman/listinfo/fluid-dev
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Subject: Digest Footer
_______________________________________________
fluid-dev mailing list
https://lists.nongnu.org/mailman/listinfo/fluid-dev
------------------------------
End of fluid-dev Digest, Vol 179, Issue 8
*****************************************
Marcus Weseloh
2018-06-15 09:52:44 UTC
Permalink
Hi JJC,

Am Mi., 13. Juni 2018 um 16:22 Uhr schrieb Ceresa Jean-Jacques <
Post by Ceresa Jean-Jacques
Using Fluidsynth with only one core a Ppi zero is able to run 60 voices
maximum (i.e using 100% cpu load). Using Rpi 3 with synth.cpu-cores = 1, i
guess you should expect the same result.

Just a quick note: the Pi Zero uses the same CPU as the RPi 1 (ARM1176JZF-S
- ARMv6). The Rpi 3 uses an ARM Cortex-A53 and should therefore be *much*
faster, even on a single core. So you could probably expect more like 120
maximum voices on the RPi 3... maybe even more, depending on kernel and
buffer sizes.

Cheers,

Marcus

Loading...