Re: [LAD] [Jack-Devel] jack2's dbus name

On Thu, 18.06.09 17:41, Paul Davis (paul@email-addr-hidden) wrote:

>
> On Thu, Jun 18, 2009 at 3:12 PM, Lennart Poettering<mzynq@email-addr-hidden> 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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev