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
