Re: [Xenomai-help] rt_task_set_periodic and different time base

[Jeff Koftinoff <jeffk@domain.hid>]

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