On Thu, 18.06.09 17:41, Paul Davis ([email protected]) wrote: > > On Thu, Jun 18, 2009 at 3:12 PM, Lennart Poettering<[email protected]> wrote: > > > > On Jack we have jack_frames_since_cycle_start(), would it be > > considered an ugly hack if I use that to implement a similar logic? > > > > for (;;) { > > n = jack_client_wait() > > process(n); > > jack_cycle_signal(); > > while (jack_frames_since_cycle_start() < threshold) > > process_one_of_my_private_event(); > > } > > > > Just ugly? Or *too* ugly? Is jack_frames_since_cycle_start() costly? > > Its (a) ugly (b) illegal - frames_since_cycle_start() is legal only > within the process() cycle but your code is not bounded by it (c) > fundamentally incompatible with basic RT programming. You're in a > thread which is competing for cycles with other JACK client threads, > and up against the deadline of the next cycle.
"Basic RT programming". Uh? I mean, seriously, you can do RT on many levels. I mean, when developing JACK you don't do real CPU cycle counting, do you? Or do you really verify the influences of the cache on your RT code? No, you don't. Wouldn't make much sense anyway. So you still have a lot variables in the whole thing. And that is fine that way, this is after all very soft RT. And that's true for PA certainly even more than JACK. For example, PA doesn't lock itself into memory because most of the time it is just one process among many and we cannot afford taking away all that many from all other processes. Now, the closest thing that comes to counting CPU cycles is counting actual time. Which the code I suggested above does. After all our deadlines are based on time, not CPU cycles. So what makes more sense than actually taking up a tiny bit of CPU time -- up to a specific worst case limit as protection -- if there is something to do? Please understand that the events that are dispatched there are not CPU intensive in any way, and only *very seldomly* actually triggered. Usually it's just adding an entry to a hash table here, removing an entry from a list there, or doing other data structure work that is quick and takes constant or O(log(N)) and very few data accesses. Having that time limit there like I proposed is mostly just a protection against dispatching too many events at once, in the unlikely event that we get more than a handful queued up. In almost all iterartions of the RT loop we'll have exactly 0 queued up. Regarding competing with other clients or deadlines, this is really just a matter of picking the right threshold. That threshold is after all just a boundary for the worst case, in almost all cycles we'll not even iterate around it once. > I don't see any reason why you cannot do what every other app that is > fundamentally not interested in real time does: put all your normal > code behind a ringbuffer, and just have your jack process cycle > pull/push from/to the ringbuffer. This is basically what happens. However in PA we are much more dynamic than JACK generally is. JACK clients generally just have a single stream of PCM data which is passed between the RT and the non-RT threads. However, PA is not as simple as that. We have streams coming and going all the time, our control data changes. That's why we need to change our internal pipeline and other shared meta data often while streaming. In JACK the answer to pipeline changes is considering them something that doesn't normally happen and when it happens then drop-outs are fine. That doesn't really work for PA. If we'd drop out each time someone triggeres a stupid event sound to be played then uh, that would make people very unhappy. So, in PA that line is blurred and we do change our pipeline while streaming, which means communication between the control and the RT threads needs to go beyond simple passing of PCM data. We need to be able to make changes to the control stuff too. And some of that we do in asynchronous fashion, by asynchronously triggering something in the RT loop to be executed when the RT loop thinks it's a good time and verified that a bit of is timeslace is available. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
