hi all,
now fixed the problem by using timidity.
found another options to fix the issue of running larger soundfonts with it.
runs good now.
buzt if you still want to figure out whats broken we still can do that
as well too.
greetings,
simon
--
Simon Eigeldinger
Follow me on Twitter: http://w
Simon:
>From the error messages you get, it sounds like you don't have a
security limits (/etc/security/limits.d) file set up to give your
user-ID the necessary real-time priority, and the ability to lock
memory.
I have an even slower machine (450 megahertz) that runs Fluidsynth
successfully (t
hi pedro,
Am 12.10.2012 20:29, schrieb Pedro Lopez-Cabanillas:
On Friday 12 October 2012, Element Green wrote:
Probably lacks an FPU, which means rather slow floating point emulation.
The CPU just can't keep up in real-time. FluidSynth uses floating point
math heavily.
http://www.raspberrypi
On Friday 12 October 2012, Element Green wrote:
> Probably lacks an FPU, which means rather slow floating point emulation.
> The CPU just can't keep up in real-time. FluidSynth uses floating point
> math heavily.
http://www.raspberrypi.org/faqs
What SoC are you using?
The SoC is a Broadcom BCM28
hi,
thanks for the quick response.
so nothing to fix via the command line options i guess.
or is there something i might able to try?
greetings,
simon
Am 12.10.2012 20:13, schrieb Element Green:
Probably lacks an FPU, which means rather slow floating point emulation.
The CPU just can't keep up
Probably lacks an FPU, which means rather slow floating point emulation.
The CPU just can't keep up in real-time. FluidSynth uses floating point
math heavily.
Best regards,
Element Green
On Oct 12, 2012 11:06 AM, "Simon Eigeldinger"
wrote:
> Hi all,
>
> I am new to fluidsynth and i tried it to
Hi all,
I am new to fluidsynth and i tried it to run it on my raspberry pi computer.
its a small ARM board with a 700 mhz processor and 256 mb ram.
When i tried it it played the file for a few seconds and then it strated
to kind of grind or hum. sounded like a saw wave tone got quite low but
w
On 12.10.2012 10:54, David Henningsson wrote:
On 10/10/2012 10:29 AM, Kjetil Matheussen wrote:
On 10.10.2012 09:51, Kjetil Matheussen wrote:
Another thing we need to verify is that the sampledata is
read-only
once it's been bigendian converted. If it is not, chances are that
two
threads would
On 10/10/2012 10:29 AM, Kjetil Matheussen wrote:
On 10.10.2012 09:51, Kjetil Matheussen wrote:
Another thing we need to verify is that the sampledata is read-only
once it's been bigendian converted. If it is not, chances are that two
threads would both modify the sampledata, causing problems.
