Re: [linux-audio-dev] midi events in jack callback (was: Reborn)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
From: Bob Ham (node_AT_users.sourceforge.net)
Date: Mon Aug 26 2002 - 02:57:43 EEST


On Thu, 2002-08-22 at 02:21, David Olofson wrote:
> On Friday 16 August 2002 00.19, Bob Ham wrote:
> > On Thu, 2002-08-15 at 20:17, Paul Davis wrote:
> [...timestamps...]
> > ...and only make calls on those that are stamped "now".
> > Except that removes the ability for the softsynth to accept events
> > in the future, but I'm not sure how useful that would be.
>
> Events stamped with a time outside the buffer you're currently
> processing should (depending on how the event system is
> implementated) either be left alone until it's time to process them,
> or just never happen. That's all there is to it. (At least in a
> callback driven, "audio oriented" real time system.)

That shouldn't be a problem.

> > I envisioned a system where a sequencer object delivers midi events
> > to the softsynth. Ie, all the time-specific magic would be in the
> > sequencer object, rather than the synth/wave/whatever objects.
> > Thinking more about it, tho, I can see this being bad. Each object
> > would have at least two threads, and those with jack callbacks
> > having another. Lots of room for things going wrong, time wise.
>
> Yes indeed. I don't think you'll have much fun at all with any kind
> of design that tries to run the event processing and the audio
> processing in separate threads. :-)

The actual processing of the events will be done in the jack process
callback. Their reception from alsa, and delivery to the callback
thread will happen in a different thread, though.

> > I
> > wanted it so that an object isn't necessarily a jack client.
> > Perhaps I'll have to change that. More thinking to do, I fear.
>
> Well, unless JACK is going to provide some kind of ports that can be
> used to pass timestamped events, how about dropping the extra
> threads, and just pass the events through lock-free FIFOs? Read
> events from inside the audio callback, and stop when you see a
> timestamp that's past the end of the current buffer.

Not sure I understand you correctly; pass events through lock-free FIFOs
from where? One of the extra threads is the "from" I'm thinking of.

> Just one "minor" issue left: The actual timestamping. If the events
> originate from a thread that doesn't run as a JACK client (real time
> MIDI input, perhaps), you'll have to keep track of "audio time" some
> other way. Knowing the sample rate, keeping track of JACK "buffer
> cycles" and checking the current time...?

For the moment, I'm not concerned about timestamps; I'm going with my
original plan.

Bob


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Aug 26 2002 - 02:53:38 EEST