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
15 matches
Mail list logo
