30 Dec
2005
30 Dec
'05
10:19 a.m.
Florian Schmidt writes:
I further assume that the alsa seq event system
is used
This is true of Rosegarden,
and midi events are not queued
for future delivery but always delivered immediately.
but this isn't -- Rosegarden always queues events
from a non-RT thread and lets the ALSA sequencer
kernel layer deliver them. (Thru events are delivered
directly, with potential additional latency because of
the lower priority used for the MIDI thread.) In
principle this should mean that only the priority of
the receiving synth's MIDI thread is significant for
the timing of sequenced events. We also have a
mechanism to compensate for gradual drift between
the MIDI timing source (kernel timers or RTC) and
soundcard clock, when synchronising to audio, by
adjusting the sequencer skew factor. (This happens
to be similar to the mechanism for slaving to MTC,
which is handy.)
In my experience this is all a long way from
foolproof. The most common problems for users
seem to be:
- ALSA sequencer uses kernel timers by default and
of course they only run at 100 or 250Hz in many
kernels.
- ALSA sequencer can sync to RTC, but the
associated module (snd-rtctimer) appears to hang
some kernels solid when loaded or used. I don't have
much information about that, but I can probably find
out some more.
- ALSA sequencer can sync to a soundcard clock,
but this induces jitter when used with JACK and has
caused confusion for users who find themselves
inadvertently sync'd to an unused soundcard (the
classic "first note plays, then nothing" symptom).
The biggest advantage of course is not having to run
an RT MIDI timing thread. My impression is that this
aspect of MusE (which does that, I think) causes
as many configuration problems for its users as using
ALSA sequencer queue timers does for Rosegarden's.
Any more thoughts on this?
Chris
30 Dec
30 Dec
10:39 a.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
The biggest advantage of course is not having to run
an RT MIDI timing thread. My impression is that this
aspect of MusE (which does that, I think) causes
as many configuration problems for its users as using
ALSA sequencer queue timers does for Rosegarden's.
Any more thoughts on this?
several people have wanted JACK to export a thread create call that
would take care of the RT-ness. that way, if you can run JACK with RT
scheduling, you can run a MIDI thread too, with no extra steps. it would
also be useful for people doing FFT in JACK clients using a separate
thread.
i don't agree with florian that the MIDI thread should run with higher
priority than the JACK watchdog, btw. i think the watchdog should be
higher than anything else until such a time as the kernel guarantees
"watchdog" functionality itself.
--p
11:17 a.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Fri, 30 Dec 2005 10:41:46 -0500
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
several people have wanted JACK to export a thread
create call that
would take care of the RT-ness. that way, if you can run JACK with RT
scheduling, you can run a MIDI thread too, with no extra steps. it would
also be useful for people doing FFT in JACK clients using a separate
thread.
actually, with realtime-lsm, there's really no need for this, except for
some convenience. Every app can create its own RT threads these days.
The 2.4.x capabilities days are (thank gawd) over :)
i don't agree with florian that the MIDI thread
should run with higher
priority than the JACK watchdog, btw. i think the watchdog should be
higher than anything else until such a time as the kernel guarantees
"watchdog" functionality itself.
Agreed. why not make it prio 98 by default then? (system timer should
still be higher i suppose). With a difference of only 10 between main
jack loop and the watchdog, it might get a little crowded :)
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
11:52 a.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Fri, 2005-12-30 at 17:17 +0100, Florian Schmidt wrote:
good point.
On Fri, 30 Dec 2005 10:41:46 -0500
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
you don't know the correct priority to use. i imagine an api along the
lines of:
jack_create_thread (pthread_t*, void* (thread_function)(void*),
void* arg, int relative_to_jack);
the last argument would specify that the thread should run at, above or
below the jack RT thread(s) by a given amount. typical values would be
+1, 0, -1 etc.
several people have wanted JACK to export a
thread create call that
would take care of the RT-ness. that way, if you can run JACK with RT
scheduling, you can run a MIDI thread too, with no extra steps. it would
also be useful for people doing FFT in JACK clients using a separate
thread.
actually, with realtime-lsm, there's really no need for this, except for
some convenience. Every app can create its own RT threads these days.
The 2.4.x capabilities days are (thank gawd) over :) i don't
agree with florian that the MIDI thread should run with higher
priority than the JACK watchdog, btw. i think the watchdog should be
higher than anything else until such a time as the kernel guarantees
"watchdog" functionality itself.
Agreed. why not make it prio 98 by default then? (system timer should
still be higher i suppose). With a difference of only 10 between main
jack loop and the watchdog, it might get a little crowded :)
12:11 p.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Fri, 30 Dec 2005 11:54:56 -0500
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
OTOH, i'm not really sure if 9 priority levels isn't enough. It seems
one above jacks main thread should be good enough for most midi purposes.
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
you don't know the correct priority to use. i
imagine an api along the
lines of:
true.
jack_create_thread (pthread_t*, void* (thread_function)(void*),
void* arg, int relative_to_jack);
the last argument would specify that the thread should run at, above or
below the jack RT thread(s) by a given amount. typical values would be
+1, 0, -1 etc.
Why not simply
/*
* returns the priority (1-99) of the jack main loop (which is already one
* above the clients' process() threads or 0 if not realtime. Clients having
* a midi handling thread should create it with a priority at least one
* above the return value of this function.
*/
int jack_get_rt_priority();
Then the app can decide itself about how to create the thread.
Agreed. why
not make it prio 98 by default then? (system timer should
still be higher i suppose). With a difference of only 10 between main
jack loop and the watchdog, it might get a little crowded :)
good point. 
12:26 p.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Fri, Dec 30, 2005 at 11:54:56AM -0500, Paul Davis wrote:
you don't know the correct priority to use. i
imagine an api along the
lines of:
jack_create_thread (pthread_t*, void* (thread_function)(void*),
void* arg, int relative_to_jack);
the last argument would specify that the thread should run at, above or
below the jack RT thread(s) by a given amount. typical values would be
+1, 0, -1 etc.
- It's fairly easy to find out a JACK client's thread priority - some
of my apps, e.g. Aeolus do this to set their thread priorities relative
to it.
- It could be wise to express *all* (including JACK's) priorities relative
to the maximum. That way things will still work when the kernel developers
decide to revise their numbering scheme.
- Some apps may want to run as well without linking to libjack, so I'm not
so sure that this is the right place for a RT-thread creation routine.
Anyway, unless you want to use capabilities or work around completely
broken things such as NPTL 0.60, creating a RT thread *is* quite simple.
If you are using an application framework or toolkit, and it provides
safe communication between RT and e.g. GUI threads, then it probably
will have a call to do it anyway.
Best wishes to all !
--
FA
11:04 a.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Fri, 30 Dec 2005 15:17:04 +0000 GMT
"Chris Cannam" <chris.cannam(a)ferventsoftware.com> wrote:
Hi Chris,
Hi,
i tested Rosegarden running with the system timer as timing source (RTC
is a bit broken atm on -rt kernels for me), and i do not get
satisfactory results. I used my ughsynth again (which is heavy on the
cpu which makes the problems just clearer) with its midi thread at
priority 95.
Here's example output with rosegarden producing a supposedly steady
stream of 16th notes at 120 bpm:
note on, frame_time: 205200106
next event: 744
next event: 746
diff: 5998
note on, frame_time: 205206104
next event: 599
next event: 600
diff: 6042
note on, frame_time: 205212146
next event: 497
next event: 498
diff: 6157
note on, frame_time: 205218303
next event: 510
next event: 511
diff: 6140
note on, frame_time: 205224443
next event: 506
next event: 507
diff: 6145
note on, frame_time: 205230588
next event: 507
next event: 508
diff: 5511
note on, frame_time: 205236099
next event: 898
next event: 899
diff: 6000
note on, frame_time: 205242099
next event: 754
next event: 755
diff: 5998
note on, frame_time: 205248097
next event: 608
next event: 609
diff: 6034
note on, frame_time: 205254131
next event: 498
next event: 499
diff: 6153
note on, frame_time: 205260284
next event: 507
next event: 508
diff: 6141
note on, frame_time: 205266425
next event: 504
next event: 505
diff: 6148
note on, frame_time: 205272573
next event: 507
next event: 509
diff: 5521
note on, frame_time: 205278094
next event: 908
next event: 910
next event: 510
which is again in the range as with my test program and ughsynth having
a low midi thread prio. This is clearly audible, too:
http://affenbande.org/~tapas/rosegarden_ughsynth.ogg
this is the rosegardenfile used for this:
http://affenbande.org/~tapas/test16th.rg
This would imply to me, that either the way the events are scheduled in
rosegarden is buggy (unlikely as it works fine when there's less audio
load on the system) or that the event queue delivery by ALSA is somehow
happening with only SCHED_OTHER priority as well.
I have not yet found an option for ALSA to configure this.
and midi
events are not queued
for future delivery but always delivered immediately.
but this isn't -- Rosegarden always queues events
from a non-RT thread and lets the ALSA sequencer
kernel layer deliver them. (Thru events are delivered
directly, with potential additional latency because of
the lower priority used for the MIDI thread.) In
principle this should mean that only the priority of
the receiving synth's MIDI thread is significant for
the timing of sequenced events. - ALSA sequencer uses kernel timers by default and
of course they only run at 100 or 250Hz in many
kernels.
In my case i have compiled the kernel to use a system timer frequency of
1000hz. It would be interesting to know though what priority the ALSA
event queue handling gets.
I also stumbled across some problems with sleep() and especially waking
up when the sleep time has expired in the course of writing my
rt_watchdog program. Sometimes the high prio SCHED_FIFO thread wasn't
woken up as long as a lower SCHED_FIFO prio thread hugged the cpu even
when the sleep time of the high prio thread was long expired.. Ingo told
me back then that there's extra kernel threads for the timing subsystem
which need to be setup to high prios too for this to work correctly.
Haven't really investigated further into this.
I need to write another small test app that uses sleep based timing and
a high prio, too, to drive ughsynth. Will report what results i get.
- ALSA sequencer can sync to RTC, but the
associated module (snd-rtctimer) appears to hang
some kernels solid when loaded or used. I don't have
much information about that, but I can probably find
out some more.
I have never bothered to try this either.
- ALSA sequencer can sync to a soundcard clock,
but this induces jitter when used with JACK and has
caused confusion for users who find themselves
inadvertently sync'd to an unused soundcard (the
classic "first note plays, then nothing" symptom).
The biggest advantage of course is not having to run
an RT MIDI timing thread. My impression is that this
aspect of MusE (which does that, I think) causes
as many configuration problems for its users as using
ALSA sequencer queue timers does for Rosegarden's.
Any more thoughts on this?
From my point of view just setting up a RT midi thread
driven by RTC and
with a sufficiently high prio for dispatching midi events
immediately is
the best way. As it seems to work well, at least for my small test case.
Further testing needs to be done though. I will report back.
I haven't really tried muse. Will do so if i find the time though..
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
3 Jan
3 Jan
9:55 p.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Fri, 30 Dec 2005 17:04:24 +0100
Florian Schmidt <mista.tapas(a)gmx.net> wrote:
I also stumbled across some problems with sleep() and
especially waking
up when the sleep time has expired in the course of writing my
rt_watchdog program. Sometimes the high prio SCHED_FIFO thread wasn't
woken up as long as a lower SCHED_FIFO prio thread hugged the cpu even
when the sleep time of the high prio thread was long expired.. Ingo told
me back then that there's extra kernel threads for the timing subsystem
which need to be setup to high prios too for this to work correctly.
Haven't really investigated further into this.
I need to write another small test app that uses sleep based timing and
a high prio, too, to drive ughsynth. Will report what results i get.
Ok, as Ingo has told me before (and which i just remembered again
today):
To make sure threads actually do get woken up after their sleep() time
elapses one needs to make the softirq-timer/0 thread (only in -rt)
systems high priority, too (higher than jack).
I actually implemented a small sleep() based midi note generator
(similar to the rtc based one) and the results i get are a little worse
than with the rtc based timer, but not by thaaat much:
diff: 6047
diff: 5999
diff: 5999
adjusted midi event [frame offset >nframes] - handed to next period
diff: 5999
diff: 6048
diff: 5998
diff: 6000
diff: 6047
diff: 5999
diff: 5999
diff: 5999
diff: 6047
diff: 5999
diff: 6000
diff: 5999
diff: 6047
That's in the 1-2% jitter range which is still fine for me.
Rosegarden in 2.6.14 vanilla and with the adjusted softirq-timer/0
kernel thread works a lot better than w/o the adjustment (naturally)
when using the system timer as timing source.
So all -rt users beware, make your softirq-timer/0 thread high prio, too
:) Benefits seq24, too.
Regards,
Flo
P.S.: if you want to make your own experiments, here's the updated
tarball with the sleep() and rtc based test note generators (they only
produce note-on events though):
http://affenbande.org/~tapas/midi_timer-0.tgz
--
Palimm Palimm!
http://tapas.affenbande.org
30 Dec
30 Dec
11:36 a.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Friday 30 December 2005 16:17, Chris Cannam wrote:
Florian Schmidt writes:
its right that MusE uses a RT midi thread to schedule midi
events. ALSA is used only to deliver (route) midi events.
I think this is the easiest possible solution and gives the app
the best control over timing.
Using the ALSA seq api means that ALSA has to operate the RT thread which
only moves the problems to ALSA.
The ALSA seq api is from ancient time were no realtime threads were
available in linux. Only a kernel driver could provide usable
midi timing. But with the introduction of RT threads the
ALSA seq api is obsolete IMHO.
Midi is synced to audio in MusE by using JACK frame timing to
schedule midi events which is also easy and straightforward.
There is nothing for a user to configure except he changes the
priority of the JACK RT thread.
The priority of the MusE midi RT thread has to be at least one above the
JACK RT priority. The point is that this allows the midi thread
to interrupt the JACK audio process thread which is necessary
to provide acceptable midi timing.
Last note about RT-linux kernels: its not _that_ important. Its
only a micro optimization. A normal recent kernel works pretty well.
If your normal kernel does not operate with sufficient low latencies,
the RT-kernel will most likely also not work.
/Werner
I further assume that the alsa seq event system
is used
This is true of Rosegarden,
and midi events are not queued
for future delivery but always delivered immediately.
but this isn't -- Rosegarden always queues events
from a non-RT thread and lets the ALSA sequencer
kernel layer deliver them. (Thru events are delivered
directly, with potential additional latency because of
the lower priority used for the MIDI thread.) In
principle this should mean that only the priority of
the receiving synth's MIDI thread is significant for
the timing of sequenced events. We also have a
mechanism to compensate for gradual drift between
the MIDI timing source (kernel timers or RTC) and
soundcard clock, when synchronising to audio, by
adjusting the sequencer skew factor. (This happens
to be similar to the mechanism for slaving to MTC,
which is handy.)
In my experience this is all a long way from
foolproof. The most common problems for users
seem to be:
- ALSA sequencer uses kernel timers by default and
of course they only run at 100 or 250Hz in many
kernels.
- ALSA sequencer can sync to RTC, but the
associated module (snd-rtctimer) appears to hang
some kernels solid when loaded or used. I don't have
much information about that, but I can probably find
out some more.
- ALSA sequencer can sync to a soundcard clock,
but this induces jitter when used with JACK and has
caused confusion for users who find themselves
inadvertently sync'd to an unused soundcard (the
classic "first note plays, then nothing" symptom).
The biggest advantage of course is not having to run
an RT MIDI timing thread. My impression is that this
aspect of MusE (which does that, I think) causes
as many configuration problems for its users as using
ALSA sequencer queue timers does for Rosegarden's.
Any more thoughts on this?
12:06 p.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Fri, 30 Dec 2005 17:37:13 +0100
Werner Schweer <ws(a)seh.de> wrote:
its right that MusE uses a RT midi thread to schedule
midi
events. ALSA is used only to deliver (route) midi events.
I think this is the easiest possible solution and gives the app
the best control over timing.
Using the ALSA seq api means that ALSA has to operate the RT thread which
only moves the problems to ALSA.
This is my understanding also.
The ALSA seq api is from ancient time were no realtime
threads were
available in linux. Only a kernel driver could provide usable
midi timing. But with the introduction of RT threads the
ALSA seq api is obsolete IMHO.
I wouldn't say obsolete, but IMHO RT thread based midi dispatching is
more easy to get right.
Midi is synced to audio in MusE by using JACK frame
timing to
schedule midi events which is also easy and straightforward.
There is nothing for a user to configure except he
changes the
priority of the JACK RT thread.
The priority of the MusE midi RT thread has to be at least one above the
JACK RT priority. The point is that this allows the midi thread
to interrupt the JACK audio process thread which is necessary
to provide acceptable midi timing.
Yep. I agree.
Is this "one above the JACK RT priority" automated in muse? Your first
sentence seems to imply otherwise. It's probably a reasonable approach
to do it this way. Although manual user overide would be nice, too.
Last note about RT-linux kernels: its not _that_
important. Its
only a micro optimization. A normal recent kernel works pretty well.
If your normal kernel does not operate with sufficient low latencies,
the RT-kernel will most likely also not work.
I do not agree. While this is true for an otherwise unloaded system, it
is rather easy (on a vanilla kernel) to produce xruns by putting other
load on the system.
The IRQ priorization provided by -rt kernels is extremely useful to
avoid these. It is _vital_ to run jackd with a priority higher than
those IRQ handlers not doing audio/midi stuff (network, disk, etc). The
soundcard IRQ handler must run with a high prio for this to work, too.
I'm not all too sure about whether it matters which of the two (jack or
soundcard irq) is higher though, as long as both are higher than other
irq handlers.
It is very useful to be able to do other stuff while audio/midi is
working uninterrupted. I got used to be able to compile a kernel
alongside running jackd with a periodsize of 32 or 16 frames :) which
means, i can play o.e. guitar while waiting for the damn compile to
finish.
Flo
P.S.: softsynths need to have their midi thread higher prio than jackd,
too, for the flawless midi timing to work. So i suppose it's time for
some bug reports to softsynth authors :)
--
Palimm Palimm!
http://tapas.affenbande.org
1 p.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Friday 30 December 2005 18:06, Florian Schmidt wrote:
higher priority thread can interrupt lower priority threads. What do
you gain if the soundcard can interrupt the jack thread? I believe
it does not matter.
Interrupt routines on a well behaved system are using only some
microseconds so it should not matter at all for audio purposes.
Or do i miss something here?
On Fri, 30 Dec 2005 17:37:13 +0100
Werner Schweer <ws(a)seh.de> wrote:
...
Last note about RT-linux kernels: its not _that_
important. Its
only a micro optimization. A normal recent kernel works pretty well.
If your normal kernel does not operate with sufficient low latencies,
the RT-kernel will most likely also not work.
I do not agree. While this is true for an otherwise unloaded system, it
is rather easy (on a vanilla kernel) to produce xruns by putting other
load on the system.
The IRQ priorization provided by -rt kernels is extremely useful to
avoid these. It is _vital_ to run jackd with a priority higher than
those IRQ handlers not doing audio/midi stuff (network, disk, etc). The
soundcard IRQ handler must run with a high prio for this to work, too.
I'm not all too sure about whether it matters which of the two (jack or
soundcard irq) is higher though, as long as both are higher than other
irq handlers.
It is very useful to be able to do other stuff while audio/midi is
working uninterrupted. I got used to be able to compile a kernel
alongside running jackd with a periodsize of 32 or 16 frames :) which
means, i can play o.e. guitar while waiting for the damn compile to
finish.
32 or 16 frames is IMHO insanely low. Lets assume your keyboard is
only 3.5m away from the drummer, you are about 10msec out of sync, which
translates to about 256 frames. This works reliable on a vanilla kernel
whatever you are doing in the background.
An interesting question is what max. latencies are accepted for real live
situations?
I can comfortably play keyboard at 20msec latency.
Something really bad is a timing _jitter_ of midi events. For
some drumloops you can hear a jitter of 2ms or lower. Latencies are
not so important for me but low jitter is.
Flo
P.S.: softsynths need to have their midi thread higher prio than jackd,
too, for the flawless midi timing to work. So i suppose it's time for
some bug reports to softsynth authors :)
1:31 p.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Fri, 2005-12-30 at 19:01 +0100, Werner Schweer wrote:
higher priority thread can interrupt lower priority
threads. What do
you gain if the soundcard can interrupt the jack thread? I believe
it does not matter.
Interrupt routines on a well behaved system are using only some
microseconds so it should not matter at all for audio purposes.
Or do i miss something here?
I think you are right. It's not the relative priority of IRQ threads
that matter (most IRQs run for far less than 1ms anyway and the
soundcard IRQ thread and JACK should never contend) but the
preemptibility of softirqs (and a few rude hardirqs like IDE) that makes
the biggest difference. Long running softirqs can delay preemption by
~10ms with 2.6.14 OOTB.
Lee
2:56 p.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
higher priority thread can interrupt lower priority
threads. What do
you gain if the soundcard can interrupt the jack thread? I believe
it does not matter.
For proper midi handling, all threads, irq and user, related to midi should
have a higher
priority than that of the jack thread(s).
Suppose a jack thread is running and your midiin device irq comes in but not
through,
because the device's irq thread has lower priority and does not get
scheduled!
Ralf
6:31 p.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Fri, 30 Dec 2005 20:54:53 +0100
"Ralf Beck" <musical_snake(a)gmx.de> wrote:
Suppose a jack thread is running and your midiin
device irq comes in but not
through,
because the device's irq thread has lower priority and does not get
scheduled!
This is an interesting question: How is midi activity on physical ports
handled? Is it polled? Or is the soundcard IRQ used for this, too? In
the latter case the soundcard IRQ should definetly have a higher prio
than all jack stuff.
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
6:40 p.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Sat, 2005-12-31 at 00:31 +0100, Florian Schmidt wrote:
On Fri, 30 Dec 2005 20:54:53 +0100
"Ralf Beck" <musical_snake(a)gmx.de> wrote:
The relative priorities of the JACK and soundcard IRQs really don't
matter because they never contend - one is woken up by the other.
Lee
Suppose a jack thread is running and your midiin
device irq comes in but not
through,
because the device's irq thread has lower priority and does not get
scheduled!
This is an interesting question: How is midi activity on physical ports
handled? Is it polled? Or is the soundcard IRQ used for this, too? In
the latter case the soundcard IRQ should definetly have a higher prio
than all jack stuff.
6:52 p.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Fri, 30 Dec 2005 18:40:20 -0500
Lee Revell <rlrevell(a)joe-job.com> wrote:
The relative priorities of the JACK and soundcard IRQs
really don't
matter because they never contend - one is woken up by the other.
This is true for the audio only case. Imagine for now, that MIDI
activity i shandled by IRQ's, too. Let's further assume jackd's prio is
higher than the soundcard IRQ (which is there for both audio and midi in
this scenario).
Ok, some audio irq has happened and jackd is doing its thing. Now a
soundcard IRQ is generated for an incoming midi event. As the soundcard
handler thread prio is lower than jackd's it will not get to run until
jackd's process loop is finished.
All of this depends on whether physical port midi activity is really
handled by IRQ's too. Anyone know more?
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
31 Dec
31 Dec
8:15 a.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Fri, 30 Dec 2005 19:01:46 +0100
Werner Schweer <ws(a)seh.de> wrote:
It didn't for me. Vanilla generally is a bit more prone to xruns than
-rt is, even at large periodsizes (> 64 frames). But if its good enough
for you.. ;) I suppose it also depends on what exact hw you use.
higher priority thread can interrupt lower priority
threads. What do
you gain if the soundcard can interrupt the jack thread? I believe
it does not matter.
Midi input is generating IRQ's, too (at least it appears so by watching
/proc/interrupts with midi activity only (i.e. hook up your midi in to a
midi monitor, as it seems withouth connections ALSA doesn't bother about
the MIDI at all)). So having the soundcard IRQ handler thread prio
higher than jackd makes sense to get stable midi input timing.
Interrupt routines on a well behaved system are using
only some
microseconds so it should not matter at all for audio purposes.
Or do i miss something here?
I'm not sure. But experience shows (to me at least) that a -rt kernel,
where i can make i.e. the hard disk controller IRQ's lower prio than
jackd and the soundcard irq, is handling additional load on the system
better than a non -rt kernel without this tuning.
It is very
useful to be able to do other stuff while audio/midi is
working uninterrupted. I got used to be able to compile a kernel
alongside running jackd with a periodsize of 32 or 16 frames :) which
means, i can play o.e. guitar while waiting for the damn compile to
finish.
32 or 16 frames is IMHO insanely low. Lets assume your keyboard is
only 3.5m away from the drummer, you are about 10msec out of sync, which
translates to about 256 frames. This works reliable on a vanilla kernel
whatever you are doing in the background. An interesting question is what max. latencies are
accepted for real live
situations?
Well, we had this discussion earlier :) Always keep in mind that
latencies are accumulative and people are different. I like to use 32
frames when playing my guitar through the computer, although 64 frames
is good enough, too. 128 or 256 frames definitely start to feel weird,
especially when effects add additional latency. Keep in mind that i
additionally run around in my room :) So the distance from the speakers
produces additional latency.
I can comfortably play keyboard at 20msec latency.
Something really bad is a timing _jitter_ of midi events. For
some drumloops you can hear a jitter of 2ms or lower. Latencies are
not so important for me but low jitter is.
20ms would be way too much for me. I agree though that midi jitter is
also bad :)
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
30 Dec
30 Dec
12:25 p.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Fri, 30 Dec 2005 15:17:04 +0000 GMT
"Chris Cannam" <chris.cannam(a)ferventsoftware.com> wrote:
- ALSA sequencer can sync to RTC, but the
associated module (snd-rtctimer) appears to hang
some kernels solid when loaded or used. I don't have
much information about that, but I can probably find
out some more.
Yeah, i got a nice and juicy BUG in it (see below). So this is what
kills rosegarden regularly here when run with RTC timing source. I'm not
sure this is ALSA's fault, though, might be the -rt kernel, too. But
nonetheless after this happens rosegarden is hung and syslog tells me
"rtc: lost some interrupts at 1024hz" over and over until infinity (or
reboot):
Dec 30 17:30:27 mango kernel: BUG at include/linux/timer.h:83!
Dec 30 17:30:27 mango kernel: ------------[ cut here ]------------
Dec 30 17:30:27 mango kernel: kernel BUG at include/linux/timer.h:83!
Dec 30 17:30:27 mango kernel: invalid operand: 0000 [#1]
Dec 30 17:30:27 mango kernel: PREEMPT
Dec 30 17:30:27 mango kernel: Modules linked in: snd_rtctimer snd_seq_dummy snd_seq_oss
snd_seq_midi snd_seq_midi_event snd_seq realtime iptable_nat ipt_addrtype ipt_state
iptable_filter agpgart snd_intel8x0 usb_storage scsi_mod ohci_hcd usbcore ipt_MASQUERADE
ip_nat ip_tables ip_conntrack snd_ice1712 snd_ice17xx_ak4xxx snd_ak4xxx_adda snd_cs8427
snd_i2c snd_mpu401_uart bsd_comp ppp_deflate zlib_deflate ppp_async ppp_generic slhc
crc_ccitt sis900 mii crc32 snd_cs46xx gameport snd_rawmidi snd_seq_device snd_ac97_codec
snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc
Dec 30 17:30:27 mango kernel: CPU: 0
Dec 30 17:30:27 mango kernel: EIP: 0060:[<c0238311>] Not tainted VLI
Dec 30 17:30:27 mango kernel: EFLAGS: 00210296 (2.6.15-rc7-rt1)
Dec 30 17:30:27 mango kernel: EIP is at rtc_do_ioctl+0x9c1/0xa00
Dec 30 17:30:27 mango kernel: eax: 00000024 ebx: 00000001 ecx: 00200246 edx:
00000001
Dec 30 17:30:27 mango kernel: esi: 00200202 edi: 00821192 ebp: d680ea40 esp:
e45e1d94
Dec 30 17:30:27 mango kernel: ds: 007b es: 007b ss: 0068 preempt: 00000001
Dec 30 17:30:27 mango kernel: Process rosegardenseque (pid: 6134, threadinfo=e45e0000
task=dcad58c0 stack_left=7520 worst_left=-1)
Dec 30 17:30:27 mango kernel: Stack: c02e8de1 c02ed6bf 00000053 22222222 22222222 22222222
22222222 22222222
Dec 30 17:30:27 mango kernel: 22222222 22222222 c0331b20 e45e0000 e45e0000 c013953a
e45e0000 00000001
Dec 30 17:30:27 mango kernel: 00200246 00200246 00000000 d680ea40 c02dda53 c0331b20
00007005 f09f7e44
Dec 30 17:30:27 mango kernel: Call Trace:
Dec 30 17:30:27 mango kernel: [<c013953a>] sub_preempt_count+0x1a/0x20 (56)
Dec 30 17:30:27 mango kernel: [<c02dda53>] _spin_lock_irqsave+0x23/0x60 (28)
Dec 30 17:30:27 mango kernel: [<f09f70a3>] rtctimer_start+0x43/0x70 [snd_rtctimer]
(40)
Dec 30 17:30:27 mango kernel: [<f081da09>] snd_timer_start1+0x89/0xa0 [snd_timer]
(20)
Dec 30 17:30:27 mango kernel: [<f081db2f>] snd_timer_start+0xaf/0xe0 [snd_timer]
(16)
Dec 30 17:30:27 mango kernel: [<f09e9f61>] snd_seq_timer_continue+0x41/0x70
[snd_seq] (36)
Dec 30 17:30:27 mango kernel: [<f09e8664>] snd_seq_queue_process_event+0x144/0x160
[snd_seq] (16)
Dec 30 17:30:27 mango kernel: [<f09e86d7>] snd_seq_control_queue+0x57/0xb0
[snd_seq] (32)
Dec 30 17:30:27 mango kernel: [<f09e3cf1>] snd_seq_deliver_single_event+0x181/0x190
[snd_seq] (28)
Dec 30 17:30:27 mango kernel: [<f09e3f02>] snd_seq_deliver_event+0x42/0xa0
[snd_seq] (52)
Dec 30 17:30:27 mango kernel: [<f09e41a1>] snd_seq_client_enqueue_event+0x91/0x160
[snd_seq] (28)
Dec 30 17:30:27 mango kernel: [<f09e444b>] snd_seq_write+0x16b/0x200 [snd_seq]
(44)
Dec 30 17:30:27 mango kernel: [<c0164eb5>] vfs_write+0xd5/0x1b0 (80)
Dec 30 17:30:27 mango kernel: [<c016505b>] sys_write+0x4b/0x80 (36)
Dec 30 17:30:27 mango kernel: [<c0102e71>] syscall_call+0x7/0xb (40)
Dec 30 17:30:27 mango kernel: ---------------------------
Dec 30 17:30:27 mango kernel: | preempt count: 00000001 ]
Dec 30 17:30:27 mango kernel: | 1-level deep critical section nesting:
Dec 30 17:30:27 mango kernel: ----------------------------------------
Dec 30 17:30:27 mango kernel: .. [<c013948a>] .... add_preempt_count+0x1a/0x20
Dec 30 17:30:27 mango kernel: .....[<00000000>] .. ( <=
_stext+0x3feffde0/0x60)
Dec 30 17:30:27 mango kernel:
Dec 30 17:30:27 mango kernel: ------------------------------
Dec 30 17:30:27 mango kernel: | showing all locks held by: | (rosegardenseque/6134
[dcad58c0, 1]):
Dec 30 17:30:27 mango kernel: ------------------------------
Dec 30 17:30:27 mango kernel:
Dec 30 17:30:27 mango kernel: #001: [e1d2d4e8] {&timer->lock}
Dec 30 17:30:27 mango kernel: ... acquired at: snd_timer_start+0x8e/0xe0
[snd_timer]
Dec 30 17:30:27 mango kernel:
--
Palimm Palimm!
http://tapas.affenbande.org
1:28 p.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Fri, 2005-12-30 at 18:25 +0100, Florian Schmidt wrote:
On Fri, 30 Dec 2005 15:17:04 +0000 GMT
"Chris Cannam" <chris.cannam(a)ferventsoftware.com> wrote:
You had better report this to LKML like yesterday so 2.6.15 does not get
released with this bug!
Lee
- ALSA sequencer can sync to RTC, but the
associated module (snd-rtctimer) appears to hang
some kernels solid when loaded or used. I don't have
much information about that, but I can probably find
out some more.
Yeah, i got a nice and juicy BUG in it (see below).
1:32 p.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Fri, 2005-12-30 at 15:17 +0000, Chris Cannam wrote:
- ALSA sequencer uses kernel timers by default and
of course they only run at 100 or 250Hz in many
kernels.
Not anymore, since 2.6.14 when the kernel developers decided to roll
back HZ to 250 it uses the RTC by default.
- ALSA sequencer can sync to RTC, but the
associated module (snd-rtctimer) appears to hang
some kernels solid when loaded or used. I don't have
much information about that, but I can probably find
out some more.
Some bugs in the RTC driver were fixed in the 2.6.13.x series, make sure
these users try a newer kernel.
Lee
6780
days inactive
6784
days old
linux-audio-dev@lists.linuxaudio.org
19 comments
7 participants
participants (7)
-
Chris Cannam -
Florian Schmidt -
fons adriaensen -
Lee Revell -
Paul Davis -
Ralf Beck -
Werner Schweer