fluid-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[fluid-dev] FluidSynth scheduling


From: Josh Green
Subject: [fluid-dev] FluidSynth scheduling
Date: 22 Apr 2003 17:57:20 -0700

Had trouble sending this before.. Please excuse multiple postings, if any.

---

Greetings..

It seems that FluidSynth 1.0.1 does not use SCHED_FIFO when running as
root. What I found is that just a call to pthread_attr_setschedpolicy is
not sufficient, the priority must also be set with
pthread_attr_setschedparam. From the man page it sounds like the default
priority is 0, which corresponds to SCHED_OTHER processes, so that is
what is assumed even after setting the policy to SCHED_FIFO. I added a
call to this and just set it to a priority of 90, which seems to work.
I've attached a patch against 1.0.1, as an example (it also contains the
restored snd_pcm_nonblock calls).

Concerning other things.. I made several of the changes to FluidSynth
that Peter suggested.

- #define DC_OFFSET 0.001f in fluid_rev.c
- changed the reverb width range checking to be more tolerant

Now FluidSynth seems to be working quite well and I had a really fun jam
session with 4 other people. It sounded really really cool! I wish I had
recorded it, perhaps next time. So far I haven't experienced any 100%
CPU consumption problems (besides playing too many notes with long
decays :)

For the future it might be neat to have a dynamic voice allocation
policy. I'm not sure how complicated this would be, but.. If the CPU
consumption of the synthesis thread could be monitored, a CPU usage
threshold could be set at which lower priority voices (less audible) are
discarded as new ones are created. This would be cool too because it
would give the user rough control over how much CPU FluidSynth would
consume. Having the default be something like 95% would allow for one to
fix things should the synthesis process get sequenced too fast when
using SCHED_FIFO.

Anyways.. Still plodding along with Swami development :) As always, its
more work than I had anticipated. But its a fun process and I'm looking
forward to when it finally sees the light of day. Its quite an ambitious
project to try and write a powerful multi-threaded generic sample based
instrument editor, but I'm happy with the architecture that is being
formed. Cheers.
        Josh Green

Attachment: fluid_alsa.c.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]