Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
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
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
Martijn Sipkema wrote: I find that for sending MIDI to an external device, resolution = RTC Hz works very well. It is a problem that a realtime audio thread 'suffocates' a RTC thread if low-latency is required, and only one processor available. It's very hard to find a clean solution in this case, but firm timers obviously do not address this particular problem. User space MIDI scheduling should run at high rt priority. If scheduling MIDI events is not done at a higher priority than the audio processing then it will in general suffer jitter at the size of the audio interrupt period. Jitter amounting to the length of time the audio cycle takes to compute, that is (which will obviously be less than the audio irq period in a usable configuration). Another reason to run MIDI behind audio: task switching and the cache invalidation it causes. If audio processing is interrupted 1024 times per second, audio performance *will* degrade, even more if many Jack clients (= separate processes) are involved. Not sure about the impact though. We definitely need some testing data here. Using the RTC is not necessary when using firm-timers. If you're doing software MIDI through, you'll have to cancel the timer you've just set, which is bad. It gets worse when you have user functions that generate MIDI events at random. In this case I think the use of firm timers is not adequate. Also, when doing hard real-time audio/MIDI, it is not possible to use more than about 70% of the available CPU time and still get reliable results. Would a library for requesting the preferred scheduling policy and priority for a certain task be a good idea to improve cooperation between applications? I'd leave it to the user, but I tend to expect a user to be savvy. tim
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
[...] User space MIDI scheduling should run at high rt priority. If scheduling MIDI events is not done at a higher priority than the audio processing then it will in general suffer jitter at the size of the audio interrupt period. Jitter amounting to the length of time the audio cycle takes to compute, that is (which will obviously be less than the audio irq period in a usable configuration). Yes, the audio interrupt period represents the worst case. But with large audio buffers and a jitter of say 70% of the interrupt period size this is still a very very large jitter and completely unacceptable (IMHO). Another reason to run MIDI behind audio: task switching and the cache invalidation it causes. If audio processing is interrupted 1024 times per second, audio performance *will* degrade, even more if many Jack clients (= separate processes) are involved. Not sure about the impact though. We definitely need some testing data here. I think that the impact will not very high. Also, that is the price one has to pay for decent MIDI timing. Clearly, running MIDI at a lower than the audio priority will result in bad timing. Using the RTC is not necessary when using firm-timers. If you're doing software MIDI through, you'll have to cancel the timer you've just set, which is bad. It gets worse when you have user functions that generate MIDI events at random. In this case I think the use of firm timers is not adequate. MIDI through and any other 'immediate' type MIDI messages do not need to be scheduled, they can be written to the interface immediately. Also, when doing hard real-time audio/MIDI, it is not possible to use more than about 70% of the available CPU time and still get reliable results. Would a library for requesting the preferred scheduling policy and priority for a certain task be a good idea to improve cooperation between applications? I'd leave it to the user, but I tend to expect a user to be savvy. More likely it will be left to the developers of various different applications and cooperation between these applications might suffer as a result. Instead a library for priorities could support the user to define his own priorities for various tasks, so a user would be able to choose if he wants to use a high or low priority for MIDI scheduling. --martijn
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
Paul Davis ([EMAIL PROTECTED]): none of this, alas, addresses the more fundamental question of how to do the timing correctly. without something like the hard-timer patch, its more or less impossible to do MIDI sequencing correctly under linux. of course, you can do it well enough with existing mechanisms, but the reason most people haven't noticed this yet is that there is fairly strong division between audio + MIDI software. its only when *this* MIDI event needs to be delivered at audio frame N that you start to see the problems. there is no way to accurately schedule anything under Linux with hard-timers unless by accurately you mean either resolution = HZ or resolution = RTC Hz or resolution = audio interrupt frequency. What do you think the solution is? Someone on #lad mentioned that ardour apparently outputs MIDI clock sync. How do you swing that one? Right now, all of my MIDI messages are output with reasonably constant latency clocked from a remote MIDI clock: effectively software MIDI thru. This + close-to-realtime audio means that my PC will hopefully output correct on both MIDI and audio in sync with constant latency, using my drum machine or hard disk recorder as the clock source. -- Billy Biggs [EMAIL PROTECTED]
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
Paul Davis wrote: none of this, alas, addresses the more fundamental question of how to do the timing correctly. without something like the hard-timer patch, its more or less impossible to do MIDI sequencing correctly under linux. of course, you can do it well enough with existing mechanisms, but the reason most people haven't noticed this yet is that there is fairly strong division between audio + MIDI software. its only when *this* MIDI event needs to be delivered at audio frame N that you start to see the problems. there is no way to accurately schedule anything under Linux with hard-timers unless by accurately you mean either resolution = HZ or resolution = RTC Hz or resolution = audio interrupt frequency. I find that for sending MIDI to an external device, resolution = RTC Hz works very well. It is a problem that a realtime audio thread 'suffocates' a RTC thread if low-latency is required, and only one processor available. It's very hard to find a clean solution in this case, but firm timers obviously do not address this particular problem. Since Jack is an Audio Connection Kit (and intended at large to stay audio iirc), all we need is to prequeue events for the next audio cycle, and get resolution = audio sample rate, which should be sufficient for an average softsynth. :) tim
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
none of this, alas, addresses the more fundamental question of how to do the timing correctly. without something like the hard-timer patch, its more or less impossible to do MIDI sequencing correctly under linux. of course, you can do it well enough with existing mechanisms, but the reason most people haven't noticed this yet is that there is fairly strong division between audio + MIDI software. its only when *this* MIDI event needs to be delivered at audio frame N that you start to see the problems. there is no way to accurately schedule anything under Linux with hard-timers unless by accurately OOPS. make that without you mean either resolution = HZ or resolution = RTC Hz or resolution = audio interrupt frequency. What do you think the solution is? Someone on #lad mentioned that the hard-timers patch or something like it needs to go into the kernel. ardour apparently outputs MIDI clock sync. How do you swing that one? no, it outputs MIDI Time Code, which is an entirely different beast. it has nothing to do with event scheduling, since its resolution is a video frame (about 1/30 sec). many people seem to confuse MIDI clock with MIDI time code - they are not related in any way whatsoever. in addition, ardour's MTC output is not lockable - it happens in a bursty way that other MTC devices will not lock to, though the reasonable ones will follow it (they will sync, but not lock). Right now, all of my MIDI messages are output with reasonably constant latency clocked from a remote MIDI clock: effectively software MIDI thru. This + close-to-realtime audio means that my PC will hopefully output correct on both MIDI and audio in sync with constant latency, its only an issue when correct means within less than a millisecond. many proprietary MIDI devices these days claim to be accurate to within the MIDI data rate (about 0.33msecs). the truth is that right now, it doesn't make much difference because most destinations for the message will take at least 1msec to respond to the data. but if you want correct, you're stuck on Linux without the hard-timers patch. using my drum machine or hard disk recorder as the clock source. these devices provide a very low resolution clock, and it can't be used to schedule MIDI data, only to provide a low resolution positional reference. --p
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
I agree, however HZ=1000 should be usable for MIDI even without patches for improved scheduling. I believe HZ=1000 is in 2.5? its usable, but its still not correct. right now, you can use RTC Hz = 1024 for the same effect, though that is slightly even less correct. --p
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
I find that for sending MIDI to an external device, resolution = RTC Hz works very well. It is a problem that a realtime audio thread 'suffocates' a RTC thread if low-latency is required, and only one processor available. It's very hard to find a clean solution in this why not just run the RTC thread at a higher priority? or does that cause other problems? Since Jack is an Audio Connection Kit (and intended at large to stay audio iirc), all we need is to prequeue events for the next audio cycle, and get resolution = audio sample rate, which should be sufficient for an average softsynth. :) agreed :) --p
RE: [linux-audio-dev] midi events in jack callback (was: Reborn)
So we need something which handles the timing like the DirectMusic(tm) in the Linux kernel. How about the ALSA project, could they put this stuff there? I mean even DirectMusic can synchronize it's master clock to audio clock, it surely must be possible also in Linux? Funny someone mentioned the MIDI clock, even the brand new Cubase SX (latest ver. 1.02) can't output solid MIDI clock, people on Cubase forum are complaining that they can't use external MIDI synced arpeggiators and sequencers. It' may though be a DirectMusic issue (in SX Steinberg decided to forget the MROS and go for DirectMusic API - synching ASIO with DirectMusic must be a pain in someone's ass). -Mikko -Original Message- From: ext Paul Davis [mailto:[EMAIL PROTECTED]] Sent: 16. August 2002 17:35 To: [EMAIL PROTECTED] Subject: Re: [linux-audio-dev] midi events in jack callback (was: Reborn) none of this, alas, addresses the more fundamental question of how to do the timing correctly. without something like the hard-timer patch, its more or less impossible to do MIDI sequencing correctly under linux. of course, you can do it well enough with existing mechanisms, but the reason most people haven't noticed this yet is that there is fairly strong division between audio + MIDI software. its only when *this* MIDI event needs to be delivered at audio frame N that you start to see the problems. there is no way to accurately schedule anything under Linux with hard-timers unless by accurately OOPS. make that without you mean either resolution = HZ or resolution = RTC Hz or resolution = audio interrupt frequency. What do you think the solution is? Someone on #lad mentioned that the hard-timers patch or something like it needs to go into the kernel. ardour apparently outputs MIDI clock sync. How do you swing that one? no, it outputs MIDI Time Code, which is an entirely different beast. it has nothing to do with event scheduling, since its resolution is a video frame (about 1/30 sec). many people seem to confuse MIDI clock with MIDI time code - they are not related in any way whatsoever. in addition, ardour's MTC output is not lockable - it happens in a bursty way that other MTC devices will not lock to, though the reasonable ones will follow it (they will sync, but not lock). Right now, all of my MIDI messages are output with reasonably constant latency clocked from a remote MIDI clock: effectively software MIDI thru. This + close-to-realtime audio means that my PC will hopefully output correct on both MIDI and audio in sync with constant latency, its only an issue when correct means within less than a millisecond. many proprietary MIDI devices these days claim to be accurate to within the MIDI data rate (about 0.33msecs). the truth is that right now, it doesn't make much difference because most destinations for the message will take at least 1msec to respond to the data. but if you want correct, you're stuck on Linux without the hard-timers patch. using my drum machine or hard disk recorder as the clock source. these devices provide a very low resolution clock, and it can't be used to schedule MIDI data, only to provide a low resolution positional reference. --p
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
I find that for sending MIDI to an external device, resolution = RTC Hz works very well. It is a problem that a realtime audio thread 'suffocates' a RTC thread if low-latency is required, and only one processor available. It's very hard to find a clean solution in this case, but firm timers obviously do not address this particular problem. User space MIDI scheduling should run at high rt priority. If scheduling MIDI events is not done at a higher priority than the audio processing then it will in general suffer jitter at the size of the audio interrupt period. Using the RTC is not necessary when using firm-timers. Also, when doing hard real-time audio/MIDI, it is not possible to use more than about 70% of the available CPU time and still get reliable results. Would a library for requesting the preferred scheduling policy and priority for a certain task be a good idea to improve cooperation between applications? --martijn
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
So we need something which handles the timing like the DirectMusic(tm) in the Linux kernel. I would prefer not to have this in the kernel. If the kernel provides accurate scheduling and CLOCK_MONOTONIC then I think this can and should be done from user-space. A driver should be able to read CLOCK_MONOTONIC from the kernel for timestamping though. --martijn
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
On Fri, 16 Aug 2002 09:40:01 -0400 Paul Davis [EMAIL PROTECTED] wrote: I sent a mail about this to the alsa-dev list, but didnt really get an useful answer. I ran into the following problem when running my sequencer and my sofsynth together. Using ALSA sequencer, I can set a timestamp to the midi event just fine, in ticks, absolute value, etc. Alsa will take care of delivering at the right time. This is not bad, but it's not enough when you are working with relatively big fragment sizes, alsa sequencer wont proovide any useful timing information. We know that the ideal way of doing this is having both the sequencer and the softsynth access to the same exact clock for reference, then having the audio app a predefined delay in time consisting of the fragment size. After that it's a simple matter of taking the current time before mixing a block, and mix internally in smaller blocks while retrieving the event. I see this as something JACK could do really well (take the timing before mixing a block and give it to the processes, so even if one has to wait for the other according to the graph, the sync with midi would be fine. I guess basically this alone may justify giving jack midi superpowers, since we know how important a good midi sync is. Juan Linietsky
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
Paul Davis wrote: I find that for sending MIDI to an external device, resolution = RTC Hz works very well. It is a problem that a realtime audio thread 'suffocates' a RTC thread if low-latency is required, and only one processor available. It's very hard to find a clean solution in this why not just run the RTC thread at a higher priority? or does that cause other problems? The problem is I write(2) MIDI from within the RTC thread; with the drivers/hardware we have I see no other way to ensure the bandwidth is used optimally and that MIDI clock is precise. (Sidenote:) That's also why I think firm timers don't help much; CC/pitch bursts must be fed to the interface that way, not to think of sysex. When writing to MIDI ports, some (especially the cheap) interfaces will block in kernel for generous amounts of time. Poll(2)ing for a write possible condition is not an option, on the AWE for example this can give up to 30% constant load in kernel. Ouch. For these reasons, I haven't yet seriously thought of running the RTC thread at a higher priority, though now I think maybe my stance should be reevaluated? tim
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
Paul Davis ([EMAIL PROTECTED]): What do you think the solution is? [...] the hard-timers patch or something like it needs to go into the kernel. Thanks for clarifying. ardour apparently outputs MIDI clock sync. [...] no, it outputs MIDI Time Code, which is an entirely different beast. Ah, that explains alot. using my drum machine or hard disk recorder as the clock source. these devices provide a very low resolution clock, and it can't be used to schedule MIDI data, only to provide a low resolution positional reference. 24ppq is fine when your sequencer only schedules notes on 24ppq boundaries. :) You're right though, I badly need hard timers, but my point was that an 8192hz clock isn't so bad if you only use it for events which are unaligned on 24ppq boundaries. Otherwise, I have to trust the MIDI clock for audio too, or my drumroll will stutter when I turn the tempo knob while playing. -- Billy Biggs [EMAIL PROTECTED]
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
We know that the ideal way of doing this is having both the sequencer and the softsynth access to the same exact clock for reference, then having the audio app a predefined delay in time consisting of the fragment size. After that it's a simple matter of taking the current time before mixing a block, and mix internally in smaller blocks while retrieving the event. this is how you handle incoming MIDI data,yes. but outgoing data is not a simple matter if you want to pre-queue the data and/or have a resolution that matches the MIDI data rate. I see this as something JACK could do really well (take the timing before mixing a block and give it to the processes, so even if one has to wait for the other according to the graph, the sync with midi would be fine. I guess basically this alone may justify giving jack midi superpowers, since we know how important a good midi sync is. yes, but MIDI sync isn't defined. as i've explained before, there are two kinds: MIDI clock: a low resolution tick MIDI timecode: a low resolution positional reference different kinds of devices use one or the other these, but rarely both. most drum machines and analog-ish sequencers use MIDI clock. most HDR systems and other digital audio systems use MTC. syncing to these two things is a very different task depending on which one you pick. MIDI clock tells you how fast you are moving, but doesn't necessarily contain any positional information. Of course, many systems may also generate MIDI song position data along with MIDI clock, just to confuse matters :) --p
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
using my drum machine or hard disk recorder as the clock source. these devices provide a very low resolution clock, and it can't be used to schedule MIDI data, only to provide a low resolution positional reference. 24ppq is fine when your sequencer only schedules notes on 24ppq boundaries. :) You're right though, I badly need hard timers, but my point was that an 8192hz clock isn't so bad if you only use it for events which are running the RTC at 8kHz causes very appreciable system load. thats why the hard/firm timers patch is so much better: interrupts generated when needed, instead of continuously. unaligned on 24ppq boundaries. Otherwise, I have to trust the MIDI clock for audio too, or my drumroll will stutter when I turn the tempo knob while playing. assuming you *have* MIDI clock :) i need to add this to the TODO list for Ardour. since it has tempo information, it can output this too. --p
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
Paul Davis wrote: I find that for sending MIDI to an external device, resolution = RTC Hz works very well. It is a problem that a realtime audio thread 'suffocates' a RTC thread if low-latency is required, and only one processor available. It's very hard to find a clean solution in this why not just run the RTC thread at a higher priority? or does that cause other problems? The problem is I write(2) MIDI from within the RTC thread; with the drivers/hardware we have I see no other way to ensure the bandwidth is used optimally and that MIDI clock is precise. (Sidenote:) That's also why I think firm timers don't help much; CC/pitch bursts must be fed to the interface that way, not to think of sysex. When writing to MIDI ports, some (especially the cheap) interfaces will block in kernel for generous amounts of time. Poll(2)ing for a write possible condition is not an option, on the AWE for example this can give up to 30% constant load in kernel. Ouch. please learn what i consider to be an invaluable lesson: software that uses cheap stuff to do cool things is great. software that tries to cover up the flaws in cheap stuff is a waste of time. the creative MIDI hardware is just so bad, its really pointless trying to make it work like this. just use a card with a decent size FIFO, and then you will find that write(2) will never block unless you are generating more data than was received by the port. For these reasons, I haven't yet seriously thought of running the RTC thread at a higher priority, though now I think maybe my stance should be reevaluated? from the perspective of the audio thread, it doesn't matter the RTC thread blocks, in fact its arguably a good thing. --p
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
On Fri, Aug 16, 2002 at 02:22:35PM -0400, Paul Davis wrote: (cut) 2) is cheap, the patch exists, and we should consider promoting it as widely as the low latency patches. (cut) Ok, let the lobbying begin :) v
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
Paul Davis wrote: Paul Davis wrote: I find that for sending MIDI to an external device, resolution = RTC Hz works very well. It is a problem that a realtime audio thread 'suffocates' a RTC thread if low-latency is required, and only one processor available. It's very hard to find a clean solution in this why not just run the RTC thread at a higher priority? or does that cause other problems? The problem is I write(2) MIDI from within the RTC thread; with the drivers/hardware we have I see no other way to ensure the bandwidth is used optimally and that MIDI clock is precise. (Sidenote:) That's also why I think firm timers don't help much; CC/pitch bursts must be fed to the interface that way, not to think of sysex. When writing to MIDI ports, some (especially the cheap) interfaces will block in kernel for generous amounts of time. Poll(2)ing for a write possible condition is not an option, on the AWE for example this can give up to 30% constant load in kernel. Ouch. please learn what i consider to be an invaluable lesson: software that uses cheap stuff to do cool things is great. software that tries to cover up the flaws in cheap stuff is a waste of time. the creative MIDI hardware is just so bad, its really pointless trying to make it work like this. just use a card with a decent size FIFO, and then you will find that write(2) will never block unless you are generating more data than was received by the port. :) That's a great argument to throw at somebody who cannot afford better hardware, don't you think? Not that I would not like to see firm timers in Linux though. tim
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
On Fri, 16 Aug 2002 14:14:02 -0400 Paul Davis [EMAIL PROTECTED] wrote: We know that the ideal way of doing this is having both the sequencer and the softsynth access to the same exact clock for reference, then having the audio app a predefined delay in time consisting of the fragment size. After that it's a simple matter of taking the current time before mixing a block, and mix internally in smaller blocks while retrieving the event. this is how you handle incoming MIDI data,yes. but outgoing data is not a simple matter if you want to pre-queue the data and/or have a resolution that matches the MIDI data rate. Well, outgoing is basically the same, you just send the timecode in which you want the event to be played (if future), or the actual time if you want to play it as soon as possible. Personally i think the incoming data is the harder thing to implement in code. ALSA sequencer seems to take care of rearranging the order of the events, but wont give you propert timing info/ I see this as something JACK could do really well (take the timing before mixing a block and give it to the processes, so even if one has to wait for the other according to the graph, the sync with midi would be fine. I guess basically this alone may justify giving jack midi superpowers, since we know how important a good midi sync is. yes, but MIDI sync isn't defined. as i've explained before, there are two kinds: MIDI clock: a low resolution tick MIDI timecode: a low resolution positional reference Yeah, midi clock and tick, but isnt that 10 milliseconds? That's basically just 100mhz timing. I was talking about something api-specific (which can become one of the other two when going outside the lib) which can work with UST. different kinds of devices use one or the other these, but rarely both. most drum machines and analog-ish sequencers use MIDI clock. most HDR systems and other digital audio systems use MTC. syncing to these two things is a very different task depending on which one you pick. MIDI clock tells you how fast you are moving, but doesn't necessarily contain any positional information. Of course, many systems may also generate MIDI song position data along with MIDI clock, just to confuse matters :) Well, basically what i mean is having the high resolution clock as api internal, that doesnt necesarily mean ignoring other midi input/output sources, but i dont think any of those really fullfill the task needed. This is basically because when managing external stuff (hardware) the devices can keep up fine with with realtime data, because there is no latency problems, thing you do have with a softsynth/soundcard. Well, personally I'd like to contribute to MIDI support for jack, i think would be great if it can handle midi, since it's already nice and consistent. How are you planning to do this? adding midi in/out ports besides the audio ones? I think if going that far, it would be nice at future, if it could also add some sort of control streams, such as start/stop/pause/set position,etc. Cheers. Juan Linietsky
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
Forgive my ignorance, but are we referring to http://sf.net/projects/high-res-timers/ by any chance? Regards, Scott. On 2002.08.17 05:54 Vincent Touquet wrote: On Fri, Aug 16, 2002 at 02:22:35PM -0400, Paul Davis wrote: (cut) 2) is cheap, the patch exists, and we should consider promoting it as widely as the low latency patches. (cut) Ok, let the lobbying begin :) v
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
On Wed, 2002-08-14 at 15:06, Paul Davis wrote: On Wed, 2002-08-14 at 13:21, Paul Davis wrote: a pull model (hey client: do this much work right now). Should the this much work be constant? Ie, should I be dealing with midi events (of which there may or may not be some) inside or outside the process callback? the process() callback is the only place where you can discover what time it is. given that midi events will typically need this to be useful, they will they need to be dispatched from within it, but they may have timestamps in the future and thus get queued at some level (your app, a user-space library, a device driver, etc.) I was actually thinking of ignoring time-stamps except within the code that sequences events. If my jack clients are given a midi event (eg, noteon,) they should deal with it immediately. Same goes for their despatches. Is this not what I should be doing? if your assumption is that you never get an event with an intended delivery time of anything but right now, then that sounds fine. this seems like quite a restricting assumption. however, its worth noting that ardour's dormant sequencer thread is designed around a similar idea, but not with this restriction. --p
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
On Thu, 2002-08-15 at 20:17, Paul Davis wrote: I was actually thinking of ignoring time-stamps except within the code that sequences events. If my jack clients are given a midi event (eg, noteon,) they should deal with it immediately. Same goes for their despatches. Is this not what I should be doing? if your assumption is that you never get an event with an intended delivery time of anything but right now, then that sounds fine. this seems like quite a restricting assumption. Well, what I have in mind is a superclass that passes the midi events to, eg a softsynth, through a virtual method. It wouldn't be much trouble to make the superclass's code pay attention to time-stamps 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. 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. 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. Bob -- Bob Ham: [EMAIL PROTECTED] http://pkl.net/~node/
