[Xenomai-help] rt_task_set_periodic and different time base

[Xenomai-help] rt_task_set_periodic and different time base

[Jeff Koftinoff]

Hi everyone.

I am going to be running xenomai on custom hardware to process audio.  I 
want my processes to be scheduled via rt_task_set_periodic(), but I do 
not want to specify time in jiffies or nanoseconds.

I need to specify time in terms of audio sample interrupts which can be 
generated by an external signal and can be slightly variable via a VCXO 
for synchronization.

The processes that I run must be synchronous to the audio, which is 
asynchronous to any other clock period/time in the system.

Should I modify Xenomai to make my audio interrupt the source of the 
jiffies? What is recommended in this case?

My original thought was to use rt_intr_wait() in my user mode program 
and do the scheduling of sub-tasks myself.

But it would be ideal if rt_task_set_periodic() could just use the 
appropriate time source itself.

Regards,
Jeff Koftinoff
www.jdkoftinoff.com

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]

Jeff Koftinoff wrote:
> Hi everyone.
> 
> I am going to be running xenomai on custom hardware to process audio.  I 
> want my processes to be scheduled via rt_task_set_periodic(), but I do 
> not want to specify time in jiffies or nanoseconds.
> 
> I need to specify time in terms of audio sample interrupts which can be 
> generated by an external signal and can be slightly variable via a VCXO 
> for synchronization.
> 
> The processes that I run must be synchronous to the audio, which is 
> asynchronous to any other clock period/time in the system.
> 
> Should I modify Xenomai to make my audio interrupt the source of the 
> jiffies? What is recommended in this case?

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?

> 
> 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 :)).

> 
> But it would be ideal if rt_task_set_periodic() could just use the 
> appropriate time source itself.

Why?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

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

[Jeff Koftinoff]

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

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2544 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

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

[Jeff Koftinoff]

On Mon, 2007-05-14 at 23:42 +0200, Jan Kiszka wrote:
> Jeff Koftinoff wrote:
> > 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?
> 

Thanks for the info. I'll try it out like this - one thread which waits
on the interrupt, and then have it selectively wake up lower priority
tasks after it finishes the most important ones based on the count. I
just thought it would be nicer to do all timing in terms of the audio
samples - as all processing that we do is directly related to the audio
rate.


Regards,

Jeff Koftinoff
www.jdkoftinoff.com