Re: [fluid-dev] problems with fluidsynth 1.1.6 on a raspberry pi

[Aere Greenway]

All:

Though I can get Fluidsynth (Qsynth) to work on my minimum machine of my test-bed, and it performs reasonably well, I heartily endorse what Chris said. 

With a soundcard that has the emu10k1 (or emu10k2) chip on it, you have four hardware synthesizers an a chip, each sharing the same soundfont in memory. 

Yet, beware that soundblaster/audigy soundcards (or any soundcard?) on a laptop, does not have the emu10k1/emu10k2 chip, even though it has the Soundblaster or Audigy name.

With the emu10k1/emu10k2 chip, you have the ability to play 16 x 4 = 64 simultaneous voices (almost an entire symphony orchestra), all at an insignificant cost of processor load.  And there is no perceivable latency (delay between pressing the key and hearing the note).

On my low-end machines, I use that for most things demo-ed.  But I still demonstrate that a software synthesizer (Fluidsynth/Qsynth) can successfully be used. 

Fluidsynth has perceivable latency, but not enough to make it difficult to perform-with.  It does (as this e-mail stream has demonstrated), significantly bog-down the processor, and currently, each instance of Fluidsynth (Qsynth 'engine') has to have its own copy of its 142 megabyte soundfont - even if all instances of it use the same soundfont. 

That memory usage problem has been addressed, but the fix is not in the repositories that go out with the Linux distributions yet. 

There are three things you need to know about to successfully use the soundcards that have the emu10k1/emu10k2 chips. 

First, to use the FluidR3_GM.sf2 soundfont (which is in my opinion, probably the very best around), you have to add the following statement to the end of the "/etc/modprobe.d/alsa-base.conf" file:

options snd-emu10k1 max_buffer_size=150

Without the above change, only part of the soundfont will be loaded, and some voices (notably the oboe) will not make a sound!  Ouch!!

After making the above change, you have to reboot before it becomes effective. 

Secondly, if you have no soundfont loaded, the hardware synthesizers will go through the motions of playing the MIDI events, but no sound will come out of the card.  A soundfont must be loaded before the hardware synthesizers will make any sound. 

You need to install package awesfx. 

After doing so, you need to do something that causes the soundfont to be loaded, before you try using it.  The following statement (which could be run from a desktop icon) will do it:

asfxload /usr/share/sounds/sf2/FluidR3_GM.sf2

Keep in mind that doing this will 'permanently' use up 141.5 megabytes of RAM (memory).  The only way I know of to free-up that memory, is to use a variation of the asfxload statement above, to load a smaller soundfont, such as as follows:

asfxload /usr/share/sounds/sf2/TimGM6mb.sf2

This will release the 141.5 megabytes of RAM, and in its place, use 5.7 megabytes of RAM.  The smaller soundfont above, is available in the "musescore-soundfont-gm" package.  This smaller soundfont has some good solo instrument voices (notably, flute and oboe), but the french horn has intonation (out-of-tune notes) problems. 

Thirdly, with the above done, you will notice that the software synthesizer plays, but plays at an annoyingly soft volume level. 

To fix this, I install gnome-alsamixer, though other mixers might do what you need. 

Run "GNOME ALSA Mixer", and scroll to the right looking for a control called "Synth" (which controls the hardware synthesizer sound volume).  Slide its slider up to (or near) the top.  You may also want to enable recording from it. 

On some mixers, you have to specify what controls are visible.  Make sure the "Synth" control is one of the visible controls! 


As you can see, there is a lot of complexity involved with making the hardware synthesizers on the soundcard work. 

In comparison, using Qsynth (Fluidsynth), and setting it up, is much easier, and it has a better sound, but alas, not on low-speed processors... 

I apologize for the long-winded nature of this e-mail, but the information is essential if you are to successfully use the hardware synthesizers on a soundcard. 


- Aere


-----Original Message-----
From: S. Christian Collins <address@hidden>
To: FluidSynth mailing list <address@hidden>
Subject: Re: [fluid-dev] problems with fluidsynth 1.1.6 on a raspberry pi
Date: Sun, 25 Nov 2012 09:19:38 -0600

Back when I used to have a 450 MHz machine, I remember avoiding softsynths in general for the same reason. If you wanted to do music production on such a machine, you really had to use hardware synths, whether the sounds from a Sound Blaster AWE32 or an external unit connected via MIDI.

-~Chris

On 11/24/2012 11:28 PM, Aere Greenway wrote:

All:

I wouldn't characterize the test results on my 450 megahertz machine as "good results".  I would call it "just barely usable" results. 

Although I can play my demo pieces on it, and it sounds good, it occasionally cuts-out (under-runs). 

Timidity does seem to be less prone to cut-out, but it has way too much latency to perform with.  Of course, if you are just playing an already-performed sequence, the latency wouldn't matter. 

- Aere

-----Original Message-----
From: Jan Newmarch <address@hidden>
Reply-to: FluidSynth mailing list <address@hidden>
To: FluidSynth mailing list <address@hidden>
Subject: Re: [fluid-dev] problems with fluidsynth 1.1.6 on a raspberry pi
Date: Sat, 24 Nov 2012 12:27:44 +1100

On Wed, 2012-11-21 at 16:26 +0100, David Henningsson wrote:

> 
> That is a very valid point; we might not strive to eliminate the average 
> CPU as much as the worst-case CPU, even if both are important.
> 
> Maybe you could run "perf top -d 1" and monitor that, to see if anything 
> special happens while the CPU maxes out?

No luck :-(. The output looked the same for good and bad bits

> 
> I have another idea too; maybe we're trashing the L1 cache? If so, 
> running with -z 1024 or -z 512 might give better result (combined with 
> using floats instead of doubles). Here, -z 1024 gave better results, but 
> not by much. The Raspberry Pi does not seem to have a L2 Cache (for CPU 
> usage), so it might diff more for you.

Just setting -z to either 512 or 1024 and floats instead of doubles
didn't work by itself.

> 
> If we do an extremely rough calculation: We have a computer of 1 GHz, a 
> sample rate of 50 kHz, and 100 voices; that gives us only 200 cycles per 
> voice and sample. And we still have to do several floating point 
> calculations every sample. So this leads me to believe that maybe there 
> is no holy grail solution to this problem, nothing obvious we're missing 
> that causes this CPU usage. Maybe it's more of trying one thing here and 
> another thing there.

Sorry to pull in the "competition" here... Timidity gives CPU usage of
around 70-90% on nightsin.kar. But it doesn't have the blowouts to above
100%, and plays okay (just). I don't know what the default settings are
for Timidity though. Maybe it is just fine tuning, although Aere is
getting good results on a slower CPU.

On another tangent, running Fluidsynth as a server to the ALSA MIDI
sequencer alsa_seq plays okay with rate set to 22050.

--

Sincerely,
Aere

Sincerely,
Aere

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev

--

Sincerely,
Aere