[Xenomai-help] Communication between Xenomai and Linux domains

[Xenomai-help] Communication between Xenomai and Linux domains

[van der Linden]

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

Hello,

I'm quite new to Xenomai. 

Before further exploring Xenomai, I like to know if it is possible to communicate between a Xenomai process and a standard Linux process.

Is there some reading on this subject?

Thanks for your help,

E-J


[-- Attachment #2: Type: text/html, Size: 1150 bytes --]

Re: [Xenomai-help] Communication between Xenomai and Linux domains

[Gilles Chanteperdrix]

van der Linden wrote:
 > Hello,
 > 
 > I'm quite new to Xenomai. 
 > 
 > Before further exploring Xenomai, I like to know if it is possible to communicate between a Xenomai process and a standard Linux process.
 > 
 > Is there some reading on this subject?

I answered a similar question yesterday:
https://mail.gna.org/public/xenomai-core/2008-04/msg00082.html

It was about communicating between threads, whereas you ask about
communicating between processes. But the answer is pretty much the same;
native skin pipes and other Xenomai IPCs may be used to communicate
between different processes.

-- 


					    Gilles.

Re: [Xenomai-help] Communication between Xenomai and Linux domains

[van der Linden]

Gilles, thanks for the answer.

Perhaps I may ask a few more questions?

I have to create an application that is partly real-time (low interrupt 
latency required) and partly non-real-time (also communicating via UDP 
etc.).
Both parts need to communicate (exchange control information). I will create 
multiple threads in this application.

My real-time thread will call the alsa-sound library libasound and use the 
ALSA Linux kernel driver for my sound card.

I gues I have to follow the next steps:

1. Determine the real-time threads and make them Xenomai threads. Also give 
them the right priority.

2. Non real-time threads become Linux threads.

3. Now I can follow two paths

4A. Start linux as a prio 0 Xenomai thread (how do you do that?) and use 
Xenomai IPC methods between Xenomai threads and the Linux threads.
      Side effect; when a Xenomai thread calls a Linux system call, the 
Linux system call is executed with the priority of the calling Xenomai 
thread.
      Also when a Linux thread calls a Xenomai IPC, it will change from 
secondary to primary mode.
      I think calling a Linux system call from Xenomai thread should be 
avoided because the real-time behaviour can be disturbed.

4B. Start Linux as a seperate ADEOS operating system (besides Xenomai) and 
communicate with native skin rt pipes between Xenomai threads and Linux 
threads.
       Xenomai runs in primary mode, Linux runs in secondary mode.
       Is the calling of a Linux system calls from a Xenomai thread 
possible? Can I use the Linux ALSA library lib_asound?
       So, my (Linux) application starts Xenomai threads and Linux threads. 
Xenomai threads can communicate with native skin rt pipes.

What do you recommend for a new application 4A or 4B?

What can be used as performance measurement tool. The normal "top" Linux 
command will only show IRQ's taking almost 100% of the cpu loading.
I gues that must be the Xenomai schedular but how can I display the loading 
the seperate Xenomai threads realy take?

Thanks for helping me.

Ernst-jan


> van der Linden wrote:
> > Hello,
> >
> > I'm quite new to Xenomai.
> >
> > Before further exploring Xenomai, I like to know if it is possible to 
> > communicate between a Xenomai process and a standard Linux process.
> >
> > Is there some reading on this subject?
>
> I answered a similar question yesterday:
> https://mail.gna.org/public/xenomai-core/2008-04/msg00082.html
>
> It was about communicating between threads, whereas you ask about
> communicating between processes. But the answer is pretty much the same;
> native skin pipes and other Xenomai IPCs may be used to communicate
> between different processes.
>
> -- 
>
>
>     Gilles.
> 

Re: [Xenomai-help] Communication between Xenomai and Linux domains

[Jan Kiszka]

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

van der Linden wrote:
> ...
> My real-time thread will call the alsa-sound library libasound and use the 
> ALSA Linux kernel driver for my sound card.

I many cases, audio processing is a soft real-time task: quality
decreases as latency increases, but the world won't stop turning. So
unless you have very tight latency requirements (can you specify them,
BTW?), you are probably better off with the -rt (or "PREEMPT-RT")
patches. They achieve quite low, but generally not guaranteed latencies
for wide areas of the Linux kernel, including its sound subsystem (the
Linux audio community is using those patches e.g.).

If this doesn't fly for you (because of too low or actually hard latency
requirements), you will have to audit the relevant ALSA code paths from
the library in user land down to the low-level driver, either improve
them for your scenario on -rt or port a required subset over to
Xenomai's RTDM driver model.

Xenomai as-is will not improve ALSA latencies. Rather, your thread will
leave the RT space managed by Xenomai when it starts talking to this layer.

Jan


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

Re: [Xenomai-help] Communication between Xenomai and Linux domains

[van der Linden]

Jan,

I have two real-time requirements:

1.  I have to get audio from ALSA and deliver it to a custom FPGA driver and 
vice versa each 5 miliseconds.
     So, I will set the chunk size for ALSA in such a way I get 5 ms audio 
samples. From the FPGA I also get chunks of 5ms.

     There may be some jitter in delivering between ALSA and FPGA but think 
of one or two miliseconds.

2. I want to receive 5ms audio from ALSA and after filtering and processing 
it I have to sent it back to ALSA.
    This must be done within 10ms.

We tested the real-time patches but the interrupt latency was not good 
enough on our Blackfin 537 DSP (measured with a latency measuring tool).
With Xenomai installed the latency tool showed very good response. So I want 
to go the Xenomai way.

So therefor I like to know more about the Xenomai / Linux interaction and 
the performance measuring method (see original mailing).

Ernst-Jan 

Re: [Xenomai-help] Communication between Xenomai and Linux domains

[Jan Kiszka]

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

van der Linden wrote:
> Jan,
> 
> I have two real-time requirements:
> 
> 1.  I have to get audio from ALSA and deliver it to a custom FPGA driver and 
> vice versa each 5 miliseconds.
>      So, I will set the chunk size for ALSA in such a way I get 5 ms audio 
> samples. From the FPGA I also get chunks of 5ms.
> 
>      There may be some jitter in delivering between ALSA and FPGA but think 
> of one or two miliseconds.

That sounds more than feasible.

> 
> 2. I want to receive 5ms audio from ALSA and after filtering and processing 
> it I have to sent it back to ALSA.
>     This must be done within 10ms.
> 
> We tested the real-time patches but the interrupt latency was not good 
> enough on our Blackfin 537 DSP (measured with a latency measuring tool).
> With Xenomai installed the latency tool showed very good response. So I want 
> to go the Xenomai way.

Yeah, there is no -rt in sight for Blackfin, thus going this way makes
sense. But you won't get around porting basic ALSA support into the
Xenomai domain. However, this can be fairly simply, provided a straight
audio controller design.

> 
> So therefor I like to know more about the Xenomai / Linux interaction and 
> the performance measuring method (see original mailing).

Regarding Xenomai/Linux interaction, there are basically two patterns:

 - Lock-less queues in shared memory between both sides.

 - A Xenomai "borderline" thread at low priority that interacts with
   other Xenomai threads in primary mode (e.g. via message queues or
   using shared memory and Xenomai mutexes, semaphores, etc.), then
   switches to secondary mode for its Linux tasks (like socket access)
   but without holding any lock at this point(!), and finally starts the
   loop all over again. Note that domain switching takes place
   automatically, you only have to take care of a clean design
   (RT/non-RT separation).

One warning regarding I-pipe/Xenomai on Blackfin, though: the last time
I checked we still had some issue in the patch that can cause scheduling
artifacts on the Linux side (but not for Xenomai!). This may not bite
you in your scenario, and I know of quite a few Blackfin applications
based on Xenomai which are fine as well, but one should be aware of this.

HTH,
Jan


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

Re: [Xenomai-help] Communication between Xenomai and Linux domains

[Gilles Chanteperdrix]

van der Linden wrote:
 > Jan,
 > 
 > I have two real-time requirements:
 > 
 > 1.  I have to get audio from ALSA and deliver it to a custom FPGA driver and 
 > vice versa each 5 miliseconds.
 >      So, I will set the chunk size for ALSA in such a way I get 5 ms audio 
 > samples. From the FPGA I also get chunks of 5ms.
 > 
 >      There may be some jitter in delivering between ALSA and FPGA but think 
 > of one or two miliseconds.
 > 
 > 2. I want to receive 5ms audio from ALSA and after filtering and processing 
 > it I have to sent it back to ALSA.
 >     This must be done within 10ms.

As long as you use ALSA, you will not be able to gain anything by using
Xenomai: in order to access the ALSA driver a real-time thread will
enter secondary mode, that is loose its real-time characteristic, and
you will get the same latencies as you would get with Linux. So, for
best performances, you will have to rewrite part of the Audio driver
using Xenomai services. The recommended way being to use the RTDM skin
to write a real-time driver.

-- 


					    Gilles.

Re: [Xenomai-help] Communication between Xenomai and Linux domains

[van der Linden]

Gilles,

I see the problem.
I think the best (easiest) way is not using the libasound library but using 
the kernel driver directly.

Then using "borderline" threads for the non-realtime tasks.

If this is right I keep still one question,

What can be used as performance measurement tool.
The normal "top" Linux command will only show IRQ's taking almost 100% of 
the cpu loading. I gues that must be the Xenomai schedular but how can I 
display the loading the Xenomai threads realy take?

Ernst-Jan

> van der Linden wrote:
> > Jan,
> >
> > I have two real-time requirements:
> >
> > 1.  I have to get audio from ALSA and deliver it to a custom FPGA driver 
> > and
> > vice versa each 5 miliseconds.
> >      So, I will set the chunk size for ALSA in such a way I get 5 ms 
> > audio
> > samples. From the FPGA I also get chunks of 5ms.
> >
> >      There may be some jitter in delivering between ALSA and FPGA but 
> > think
> > of one or two miliseconds.
> >
> > 2. I want to receive 5ms audio from ALSA and after filtering and 
> > processing
> > it I have to sent it back to ALSA.
> >     This must be done within 10ms.
>
> As long as you use ALSA, you will not be able to gain anything by using
> Xenomai: in order to access the ALSA driver a real-time thread will
> enter secondary mode, that is loose its real-time characteristic, and
> you will get the same latencies as you would get with Linux. So, for
> best performances, you will have to rewrite part of the Audio driver
> using Xenomai services. The recommended way being to use the RTDM skin
> to write a real-time driver.
>
> -- 
>
>
>     Gilles.
> 

Re: [Xenomai-help] Communication between Xenomai and Linux domains

[Gilles Chanteperdrix]

van der Linden wrote:
 > Gilles,
 > 
 > I see the problem.
 > I think the best (easiest) way is not using the libasound library but using 
 > the kernel driver directly.

It will not work either. The kernel driver uses some synchronization
objects such as mutexes, semaphores, spinlocks that only work in Linux
domain. So, you really need to rewrite a driver using RTDM's own
synchronization objects.

 > 
 > Then using "borderline" threads for the non-realtime tasks.
 > 
 > If this is right I keep still one question,
 > 
 > What can be used as performance measurement tool.
 > The normal "top" Linux command will only show IRQ's taking almost 100% of 
 > the cpu loading. I gues that must be the Xenomai schedular but how can I 
 > display the loading the Xenomai threads realy take?

cat /proc/xenomai/sched or /proc/xenomai/stat but you really have other
issues to solve before you care about that.


-- 


					    Gilles.