Quoting David Henningsson :
j...@resonance.org wrote:
I don't think there is an issue with this. Since the new value isn't
actually passed through the queue, the queued event is essentially
just an update request. The latest value will always be the value
assigned to the variable and the
j...@resonance.org wrote:
Quoting David Henningsson :
If someone is playing along with the midi track, they can't have high
latency. On the other hand, I think it is only between songs there is a
problem, the rest should not be very time-consuming.
True, hadn't really thought of that scenario.
Quoting David Henningsson :
j...@resonance.org wrote:
This scenario is less critical IMO, since the audio buffers could
be increased without issue (so what if the MIDI file plays 100ms
later). Good to know though. We may want FluidSynth to be smarter
about selecting default buffer size
j...@resonance.org wrote:
Quoting David Henningsson :
Btw; with the sample timers we also have the entire midi file player
(with its fopen calls etc) inside the audio thread. I'm guilty of that,
and it should be fixed by inserting a sequencer between the player and
the audio thread, at least in
Quoting David Henningsson :
Btw; with the sample timers we also have the entire midi file player
(with its fopen calls etc) inside the audio thread. I'm guilty of that,
and it should be fixed by inserting a sequencer between the player and
the audio thread, at least in real-time use cases. Perha
j...@resonance.org wrote:
Quoting David Henningsson :
A difference between 1.0.9 and 1.1.0 is that the audio thread got more
of the state machine work to do; making it harder to keep its real-time
properties. I admit to not having considered this well enough when we
discussed the thread safety t
Quoting David Henningsson :
Ebrahim Mayat wrote:
Currently, fluidsynth has five threads.
5 process 6014 thread 0x6f03 0x936a11f8 in mach_msg_trap ()
4 process 6014 thread 0x6703 0x936a1278 in
semaphore_timedwait_signal_trap ()
3 process 6014 thread 0x6203 0x936a11f8 in mach_msg_trap ()
2
On Nov 18, 2009, at 2:13 AM, David Henningsson wrote:
//
I'm not sure about the fifth (I/O procs) thread, is that something
used internally by libraries we use? What does it do?
My sketchy idea about this is that this thread is kernel-related (at
least on OS X); it is created by the hard
Ebrahim Mayat wrote:
Currently, fluidsynth has five threads.
5 process 6014 thread 0x6f03 0x936a11f8 in mach_msg_trap ()
4 process 6014 thread 0x6703 0x936a1278 in
semaphore_timedwait_signal_trap ()
3 process 6014 thread 0x6203 0x936a11f8 in mach_msg_trap ()
2 process 6014 thread 0x1003 0x
On Nov 16, 2009, at 12:47 AM, David Henningsson wrote:
While the recent thread safety improvements are much better than the
previous handling (since the previous had unpredictable crashes),
the recent postings, the shadow variable workaround, and the multi-
core support got me thinking. See
Quoting David Henningsson :
j...@resonance.org wrote:
Quoting David Henningsson :
The fluid_synth is becoming increasingly large and complex. I've
started to think of it as two parts, a state machine, and a voice
renderer. The voice renderer is strict real-time, and corresponds
roughly to fluid
j...@resonance.org wrote:
Quoting David Henningsson :
The fluid_synth is becoming increasingly large and complex. I've
started to think of it as two parts, a state machine, and a voice
renderer. The voice renderer is strict real-time, and corresponds
roughly to fluid_synth_one_block and everythi
> Date: Mon, 16 Nov 2009 00:37:40 -0800
> From: j...@resonance.org
>
> Quoting David Henningsson :
>
> > However, nothing new without a downside. Since the
> sample is used by
> > the voice renderer, freeing a preset or soundfont is
> not solved easily.
> > But outlined, first we should check if
Quoting David Henningsson :
While the recent thread safety improvements are much better than the
previous handling (since the previous had unpredictable crashes), the
recent postings, the shadow variable workaround, and the multi-core
support got me thinking. See this as long-term thoughts for di
While the recent thread safety improvements are much better than the
previous handling (since the previous had unpredictable crashes), the
recent postings, the shadow variable workaround, and the multi-core
support got me thinking. See this as long-term thoughts for discussion,
rather than some
j...@resonance.org skrev:
> Quoting David Henningsson :
>> j...@resonance.org skrev:
>>> This could be handled by identifying which "thread" is the synthesis
>>> thread (first call to fluid_synth_one_block). Any function which might
>>> need to synchronize in the multi-thread case, could check if
Quoting David Henningsson :
j...@resonance.org skrev:
This could be handled by identifying which "thread" is the synthesis
thread (first call to fluid_synth_one_block). Any function which might
need to synchronize in the multi-thread case, could check if the calling
thread is the synthesis thre
Quoting jimmy :
Here's my my comments on special effects processing (SFX, for short
here) in sound synthesis. But since Midi allow for some live
manipulation of some paramenters, it may allow for per channel
manipulation, too?
I guess one way to describe it is how many "SFX processors
j...@resonance.org skrev:
> This could be handled by identifying which "thread" is the synthesis
> thread (first call to fluid_synth_one_block). Any function which might
> need to synchronize in the multi-thread case, could check if the calling
> thread is the synthesis thread or not and process t
> Date: Thu, 04 Jun 2009 20:10:10 -0400
> From: j...@resonance.org
>
> Yes. The main "synthesis" thread, would be the audio
> thread, since it
> ultimately calls fluid_synth_one_block(). The MIDI
> thread could be
> separate, but it could also be just a callback, as long as
> it is
> guar
Hello Pedro,
Quoting Pedro Lopez-Cabanillas :
Hi,
I'm not following closely your threading debate, sorry. But there are some
existing traditional terms in computer technology that I find applicable to
the scenarios you are talking about. I am not asking you to change your
vocabulary, this is on
Hi,
I'm not following closely your threading debate, sorry. But there are some
existing traditional terms in computer technology that I find applicable to
the scenarios you are talking about. I am not asking you to change your
vocabulary, this is only a comment.
On Thursday, June 4, 2009, Dav
Hello David,
Quoting David Henningsson :
j...@resonance.org skrev:
It seems like you're thinking that we pre-render one fluidsynth buffer
(64 samples) ahead, and add that to the latency. That's a simpler
solution than the one I had in mind: I was thinking that we should
prerender several buff
j...@resonance.org skrev:
> Quoting David Henningsson :
>>> I think ideas like these are good. Having each voice be processed and
>>> then mixed, would only require one buffer (64 bytes) per voice and
>>> would not require much extra CPU. This could also facilitate moving
>>> to the multi-thread
Quoting j...@resonance.org:
Yeah, I also came to that conclusion (one FIFO per thread). Adding the
FIFOs wouldn't be that difficult. Just have a fixed size array
(maximum number of threads), which is initialized with NULLs. A
GPrivate (private data per thread) could be used to assign a FIFO t
Quoting David Henningsson :
I think ideas like these are good. Having each voice be processed and
then mixed, would only require one buffer (64 bytes) per voice and
would not require much extra CPU. This could also facilitate moving
to the multi-thread voice processing model.
I guess you woul
j...@resonance.org skrev:
> Quoting David Henningsson :
>>
> Looking at how things are coded in FluidSynth, I'm amazed there aren't
> more issues, in real world use. I suspect there are lots of issues
> lurking, those one in a million synthesis glitches or worst case, crashes.
Then you and I have
Quoting David Henningsson :
Excitement is a good thing. It would be nice to know your plans in terms
of time and effort, that is, if you can tell in advance. :-)
Indeed, it is difficult for me to know how much time I have available.
I've had my mind on this particular subject for a bit no
j...@resonance.org skrev:
> Quoting David Henningsson :
>>
>> However, if you say that Swami expects fluid_synth_t to be somewhat
>> thread-safe (just had a five-minute look a qsynth and at first glance it
>> seems to expect the same), perhaps it would be bad to enforce the
>> single-threaded synth
Quoting David Henningsson :
The proposed change is that incoming events will be pushed into the
sequencer queue by the midi thread, then popped and processed by the
audio thread. (The call stack for the audio thread would be:
fluid_synth_one_block -> fluid_sample_timer_process ->
fluid_sequencer
Hello Jimmy,
The current design of FluidSynth is that the synthesizer runs in the
audio thread, there is a MIDI thread and the main thread for the
fluidsynth shell. The audio thread synthesizes active voices to the
audio stream. Events received by the MIDI thread activate/deactivate
voi
> Date: Tue, 19 May 2009 07:28:07 +0200
> From: David Henningsson
> Here's an answer for you, jimmy, and anyone else whose
> questions can be
> shortened to "you won't break anything, will you?" :-)
>
> First, to me it seems like the current synchronization
> handling is very
> broken, and I se
j...@resonance.org skrev:
> Hello David,
>
> Looks like you have done a pretty thorough analysis of FluidSynth
> threading, something which I have not done and still lack some knowledge
> concerning the current code base. Despite this, I'll try to be
> intelligent in my questions and opinions ;)
Dave Serls skrev:
> On Sun, 17 May 2009 10:20:18 +0200
> David Henningsson wrote:
>> Given that priority list, we should make the fluid_synth_t class
>> single-threaded and avoid mutexes altogether. One reason for this is
>> that one of Fluidsynth's most important usages are as a virtual
>> instru
On Sun, 17 May 2009 10:20:18 +0200
David Henningsson wrote:
>
> Given that priority list, we should make the fluid_synth_t class
> single-threaded and avoid mutexes altogether. One reason for this is
> that one of Fluidsynth's most important usages are as a virtual
> instrument in MusE/Rosegard
Some more questions for David,
I don't know of the FS internal threading code or David's propose changes. But
let me ask if the change may affect apps that use 32, 48, 64, or more channels?
There are some apps that use such features in FS.
Along with that, what about cases of running multip
Hello David,
Looks like you have done a pretty thorough analysis of FluidSynth
threading, something which I have not done and still lack some
knowledge concerning the current code base. Despite this, I'll try to
be intelligent in my questions and opinions ;)
Quoting David Henningsson :
I've been looking at the threading strategy in Fluidsynth, which seems
to need some review. While thinking about this, my first priority have
been to avoid concurrency issues, at all costs (an underrun is bad, but
a segfault is 100 times worse), and my second priority has been to avoid
unnecessary
38 matches
Mail list logo
