Jeff Koftinoff wrote: > Jan Kiszka wrote: >> >> There exists some vague ideas to provide an infrastructure with Xenomai >> that allows to smoothly synchronise its local clock on whatever external >> (jittery) source, but note that "vague" above. >> >> Moreover, I don't think you actually want this for your scenario. You >> may rather look for a hard sync on each audio tick, no? >> >> > correct, a hard sync on each audio tick is what I want. 166 +- 20 > Microseconds. > >>> My original thought was to use rt_intr_wait() in my user mode program >>> and do the scheduling of sub-tasks myself. >>> >> >> Sounds what you need (or directly derive an RTDM device with appropriate >> interface for your audio-hw :)). >> >> > 90% of my CPU time needs to be spent processing audio and the control > for this audio, at the highest priority above linux, and running in C++ > in userspace (really!)... There is no 'audio driver' involved, really, > as the whole point of the hardware is to process live audio in real time > from audio in to audio out with very low latency in usermode.
I see. >>> But it would be ideal if rt_task_set_periodic() could just use the >>> appropriate time source itself. >>> >> >> Why? >> >> > Because I have many layers of audio processing procedures that need to > be scheduled at different periodic intervals, with different priorities. > lower level audio processing procedures run every 166 microseconds and > have highest priority, and interrupt higher level lower rate (5.3 > ms,10.66 ms and 32 ms) control processing procedures. So they are all multiples of the base period? Why not let the high-rate tasks wake the low-rate ones when time has come, e.g. via semaphores? > I have non-xenomai usermode code right now that can use a recursive > signal handler to manually schedule these 'layers' of processing tasks. > But then I'm just duplicating the rt_task_set_periodic() capability that > is already there in xenomai. > > I just want the Xenomai task scheduler to be controlled directly by the > audio tick interrupt.... Is that a problem to enable? You may hack this into the code, but I would rather suggest to design this at application level in order to remain portable across Xenomai releases. Only if you find relevant performance deficits (but I do not see any yet), you may consider special solutions (in that case, please come back with the issue, maybe we can find a generic way that helps others as well). Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
