On Fri, 30 Dec 2005 17:04:24 +0100
Florian Schmidt <[EMAIL PROTECTED]> 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 u
On Sun, 1 Jan 2006 13:18:09 +0100
[EMAIL PROTECTED] wrote:
> > in a low latency *live* system, "timing" doesn't really exist outside of
> > the current period. there is no concept of "when" that exists beyond the
> > end of the current period.
> to remove jitter i would delay all events i reciv
On Sat, Dec 31, 2005 at 08:03:06AM -0500, Paul Davis wrote:
> On Sat, 2005-12-31 at 00:04 +0100, fons adriaensen wrote:
> > On Fri, Dec 30, 2005 at 05:10:44PM -0500, Paul Davis wrote:
> > > On Fri, 2005-12-30 at 22:27 +0100, Pedro Lopez-Cabanillas wrote:
> > > > On Friday 30 December 2005 17:37, We
On Saturday 31 December 2005 17:10, Paul Davis wrote:
> On Fri, 2005-12-30 at 22:27 +0100, Pedro Lopez-Cabanillas wrote:
> > On Friday 30 December 2005 17:37, Werner Schweer wrote:
> > > The ALSA seq api is from ancient time were no realtime threads were
> > > available in linux. Only a kernel driv
Paul Davis:
> i guess it all depends on one's definition of
> "sufficient". my take is that there are several MIDI
> h/w boxes that guarantee MIDI delivery to a
> resolution that matches the wire protocol
> (1/3msec). until we have scheduling capabilities that
> match this (or better), i don't
On Saturday 31 December 2005 00:52, Florian Schmidt wrote:
> All of this depends on whether physical port midi activity is really
> handled by IRQ's too. Anyone know more?
I don't know every MIDI interface details, but there are many different
variations. Please, somebody with better knowledge c
On Sat, Dec 31, 2005 at 08:03:06AM -0500, Paul Davis wrote:
> On Sat, 2005-12-31 at 00:04 +0100, fons adriaensen wrote:
> > 1. If things have to be timed accurately, it seem logical to concentrate
> > this activity at one point. At least then the timing will be consistent,
> > you can impose prior
On Sat, 2005-12-31 at 14:58 +, Chris Cannam wrote:
> Paul Davis:
> > most of the ALSA sequencer's
> > capabilities are redundant, which is compounded
> > because it currently has
> > no way of providing sufficiently accurate scheduling
>
> You say this as if it were self-evident, when it's b
Paul Davis:
> most of the ALSA sequencer's
> capabilities are redundant, which is compounded
> because it currently has
> no way of providing sufficiently accurate scheduling
You say this as if it were self-evident, when it's been
the subject of much of this thread. _Does_ it have
no way of p
On Fri, 30 Dec 2005 19:01:46 +0100
Werner Schweer <[EMAIL PROTECTED]> 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.
Midi input is generating IRQ's, too (at least it appears
On Sat, 2005-12-31 at 00:04 +0100, fons adriaensen wrote:
> On Fri, Dec 30, 2005 at 05:10:44PM -0500, Paul Davis wrote:
> > On Fri, 2005-12-30 at 22:27 +0100, Pedro Lopez-Cabanillas wrote:
> > > On Friday 30 December 2005 17:37, Werner Schweer wrote:
> > >
> > > > The ALSA seq api is from ancient
On Sat, 2005-12-31 at 00:00 +, Chris Cannam wrote:
> Paul Davis:
> > frank (v.d.p) had the right idea back when he
> > started this
>
> Huh? Started what?
the ALSA sequencer.
Paul Davis:
> frank (v.d.p) had the right idea back when he
> started this
Huh? Started what?
Chris
On Fri, 30 Dec 2005 18:40:20 -0500
Lee Revell <[EMAIL PROTECTED]> 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 b
On Sat, 2005-12-31 at 00:31 +0100, Florian Schmidt wrote:
> On Fri, 30 Dec 2005 20:54:53 +0100
> "Ralf Beck" <[EMAIL PROTECTED]> 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 no
On Fri, 30 Dec 2005 20:54:53 +0100
"Ralf Beck" <[EMAIL PROTECTED]> 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 activ
On Fri, Dec 30, 2005 at 05:10:44PM -0500, Paul Davis wrote:
> On Fri, 2005-12-30 at 22:27 +0100, Pedro Lopez-Cabanillas wrote:
> > On Friday 30 December 2005 17:37, Werner Schweer wrote:
> >
> > > The ALSA seq api is from ancient time were no realtime threads were
> > > available in linux. Only a
On Fri, 2005-12-30 at 22:27 +0100, Pedro Lopez-Cabanillas wrote:
> On Friday 30 December 2005 17:37, Werner Schweer wrote:
>
> > 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 intro
On Friday 30 December 2005 17:37, Werner Schweer wrote:
> 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 don't agree w
> 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).
Su
Me:
> I'll have to review the sequencer API and look at
> adding a separate RT MIDI thread as an alternative
Actually no, hang on a minute. First I want to know
more about why the ALSA sequencer queue doesn't
work better here.
It's all very well saying it's irrelevant now that it's
so easy
On Fri, 2005-12-30 at 15:17 +, 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
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
> microsecond
On Fri, 2005-12-30 at 18:25 +0100, Florian Schmidt wrote:
> On Fri, 30 Dec 2005 15:17:04 + GMT
> "Chris Cannam" <[EMAIL PROTECTED]> 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'
On Friday 30 December 2005 18:06, Florian Schmidt wrote:
> On Fri, 30 Dec 2005 17:37:13 +0100
>
> Werner Schweer <[EMAIL PROTECTED]> 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
Florian Schmidt:
> 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.
That'll be the chap. Mind you, I never saw the RTC-
based timer measure significantly better than the
system timer at 1000Hz. Although yo
On Fri, 30 Dec 2005 15:17:04 + GMT
"Chris Cannam" <[EMAIL PROTECTED]> 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
Florian Schmidt writes:
> Here's example output with rosegarden producing a
> supposedly steady stream of 16th notes at 120 bpm:
> [...]
Those results certainly are pretty poor. We do have
a very similar test in the Rosegarden tree (the
complainer test) but it doesn't stress the system
quite
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
On Fri, 30 Dec 2005 11:54:56 -0500
Paul Davis <[EMAIL PROTECTED]> wrote:
> 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
On Fri, 30 Dec 2005 17:37:13 +0100
Werner Schweer <[EMAIL PROTECTED]> 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.
On Fri, 2005-12-30 at 17:17 +0100, Florian Schmidt wrote:
> On Fri, 30 Dec 2005 10:41:46 -0500
> Paul Davis <[EMAIL PROTECTED]> 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,
On Friday 30 December 2005 16:17, Chris Cannam wrote:
> 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 -- Rosega
On Fri, 30 Dec 2005 10:41:46 -0500
Paul Davis <[EMAIL PROTECTED]> 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 b
On Fri, 30 Dec 2005 15:17:04 + GMT
"Chris Cannam" <[EMAIL PROTECTED]> wrote:
Hi Chris,
> > 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
> kern
> 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 Fri, 30 Dec 2005 16:03:44 +0100
Jens M Andreasen <[EMAIL PROTECTED]> wrote:
> Flo!
>
> Is it important for the midi thread priority to be above the soundcard
> IRQ, or is it enough to be above jackd?
This is not 100% clear to me. I'd figure it should be above soundcard
irq, too, just to be sa
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 sequ
Flo!
Is it important for the midi thread priority to be above the soundcard
IRQ, or is it enough to be above jackd?
How will having several sound/midi cards fit into this scheme? (I have a
builtin VIA chipset sound, a better quality Aureal PCI card and, for
good measure, a USB control surface.)
On Fri, 30 Dec 2005 01:52:10 +0100
Florian Schmidt <[EMAIL PROTECTED]> wrote:
> On Fri, 30 Dec 2005 00:47:46 +0100
> Florian Schmidt <[EMAIL PROTECTED]> wrote:
>
> [snip]
>
> Hmm,
>
> forget this post :) I need to do some more testing first..
Ok,
my synth was buggy (damn copy and paste). Now
On Fri, 30 Dec 2005 00:47:46 +0100
Florian Schmidt <[EMAIL PROTECTED]> wrote:
[snip]
Hmm,
forget this post :) I need to do some more testing first..
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
Hi,
i was wondering:
With the new shiny -rt kernels and realtime scheduling available to non
root users via the usual mechanisms, there's the possibility of really
finetuning an audio/midi system.
The main issue i am interested in is the interplay between midi and
audio in such a system. How to
42 matches
Mail list logo
