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. >> 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. 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? Regards, Jeff koftinoff. www.jdkoftinoff.com _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
