19 Feb
2003
19 Feb
'03
11:14 a.m.
Hi all,
Some fixes and extra bits for the midi stuff; makes things much more
responsive.
* icon and .desktop get installed properly
* much more graceful handling of jackd shutdowns
* midi thread will now try and use SCHED_FIFO. If you run jackd with
jackstart (or as root, but you don't want to do that :) then you
don't need to do anything to enable this as jackd will give the
appropriate rights to jack rack.
Bob
--
Bob Ham <rah(a)bash.sh>
20 Feb
20 Feb
9:14 a.m.
On Wednesday 19 February 2003 17.33, Paul Davis wrote:
Probably to make MIDI control as deterministic as the audio
processing. (Not much point in running a synth with small buffers and
SCHED_FIFO otherwise.)
Another motivation would be to avoid having MIDI timing quantized to
audio block granularity under heavy audio CPU load. This would make
sense only if events have to be timestamped in the context of the
MIDI thread, and then it would require that the MIDI thread gets
higher priority than the audio thread(s).
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
* midi thread
will now try and use SCHED_FIFO. If you run jackd
with
why? 
9:36 a.m.
On Wednesday 19 February 2003 17.33, Paul Davis wrote:
Probably to make MIDI control as deterministic as the audio
processing. (Not much point in running a synth with small buffers and
SCHED_FIFO otherwise.)
but this is for JACK Rack, not a MIDI sequencer. we're talking about
controlling things from a control surface. why does it need to be so
"deterministic" when its already inherently sloppy? nobody suggests
that the X server and the GUI thread should be SCHED_FIFO so that
mouse-based control is "deterministic" ...
--p
* midi
thread will now try and use SCHED_FIFO. If you run jackd
with
why?
9:40 a.m.
On Thursday 20 February 2003 15.29, Paul Davis wrote:
Well, if that's all there is to it (ie no input from external MIDI h/w
or something), I have to agree.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
On Wednesday 19
February 2003 17.33, Paul Davis wrote:
Probably to make MIDI control as deterministic as the audio
processing. (Not much point in running a synth with small buffers
and SCHED_FIFO otherwise.)
but this is for JACK Rack, not a MIDI sequencer. we're talking
about controlling things from a control surface. why does it need
to be so "deterministic" when its already inherently sloppy? nobody
suggests that the X server and the GUI thread should be SCHED_FIFO
so that mouse-based control is "deterministic" ... * midi
thread will now try and use SCHED_FIFO. If you run
jackd with
why?
10:38 a.m.
On Wed, 2003-02-19 at 16:33, Paul Davis wrote:
Without SCHED_FIFO, the midi thread takes a back seat in the
processing. This means that control changes come in chunks, causing big
jumps in the plugins' controls settings. This makes clicks and pops and
stuff, it doesn't reflect what happening in real-time, and is generally
not very nice.
Bob
--
Bob Ham <rah(a)bash.sh>
* midi thread
will now try and use SCHED_FIFO. If you run jackd with
why?
10:47 a.m.
On Thu, 2003-02-20 at 14:29, Paul Davis wrote:
but this is for JACK Rack, not a MIDI sequencer.
we're talking about
controlling things from a control surface. why does it need to be so
"deterministic" when its already inherently sloppy? nobody suggests
that the X server and the GUI thread should be SCHED_FIFO so that
mouse-based control is "deterministic" ...
Not sure what this determinism is about, but the UI thread doesn't seem
to suffer the same effects of non-SCHED_FIFO-ness that the midi thread
does; that's why the midi thread has SCHED_FIFO. I'm not sure *why* the
midi thread suffers; both the midi thread and ui thread operate in
pretty much exactly the same way. The only difference is the alsa
sequencer is involved; perhaps it's something to do with that.
Bob
--
Bob Ham <rah(a)bash.sh>
10:53 a.m.
* midi thread will now try and use SCHED_FIFO. If you
run jackd with
why? 
11:30 a.m.
On Thu, Feb 20, 2003 at 03:26:27 +0000, Bob Ham wrote:
On Wed, 2003-02-19 at 16:33, Paul Davis wrote:
Without SCHED_FIFO, the midi thread takes a back seat in the
processing. This means that control changes come in chunks, causing big
jumps in the plugins' controls settings. This makes clicks and pops and
stuff, it doesn't reflect what happening in real-time, and is generally
not very nice.
If you get pops and clicks because the plugin doesn't handle sudden
changes (and its a control you expect to change in realtime) you should
proably report it as a bug to the author...
- Steve
* midi
thread will now try and use SCHED_FIFO. If you run jackd with
why?
7770
days inactive
7771
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
4 participants
participants (4)
-
Bob Ham -
David Olofson -
Paul Davis -
Steve Harris