Dave Robillard <drobilla(a)connect.carleton.ca> writes:
I need to know if gettimeofday (or one of the other
standard time
functions) is okay to use in a realtime jack thread. I can't find any
information on the net about whether it's deterministic or not (or even
how expensive it is).
On Linux it does not wait (AFAIK). But, it does involve the overhead
a system call. Plus, there's always some danger when taking a trip
through the system call exit path that the scheduler will screw things
up and decide to run some other thread.
The JACK ALSA backend calls it once per cycle, but we use the cycle
counter (on platforms that support it) to avoid paying this cost any
more than that.
Problem is I have an event-based system that pushes
events (from
OSC/Midi) into a dequeue, which the audio thread runs through to
execute. If you flood with events, too many need to be processed per
block, the audio thread takes too long and you get dropouts.
I'd like to be able to only process (non timestamped) events for x% of
the time available to prevent this from happening; so I need to be able
to determine how much time has been eaten by event processing so far.
Is calling gettimeofday this many times in the realtime thread a wise
idea?
How often? Once per MIDI event? That should be OK, I suppose.
--
joq