First, thank you for your answer.
I see your point.

However, I was wondering:
Is it clever or completely stupid to envisage the following issue:
- reading and writting audio data is done by a non-RT process and uses the
linux driver of the soundcard.
- a realtime thread processes the audio signal.
-  RT and non-RT threads communicate using RTFifos.

What are the limits of such an implementation? What I mean is that in case
of high rates, high sampling frequency (which implies to read and write more
Data), would it slow the RT-processing part of the application down?

Thank you.

SIMON Benjamin.
http://asi.insa-rouen.fr


----- Original Message -----
From: "David Olofson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, April 11, 2002 1:15 AM
Subject: Re: [rtl] acees to sound devices with RTLinux


> On Wednesday 10 April 2002 17:39, SIMON Benjamin wrote:
> > I'm a beginner with RTLinux...
> >
> > I have several questions that go in the same way:
> >
> > Victor Yodaiken has written:
> > "The standard RTLinux open will open /dev/x for a fixed set of
> > devicesand will not support any other path names" . Which devices are
> > supported? for example, can I open /dev/dsp with the RTLinux open
> > function?
>
> Any devices that are registered by RTLinux drivers, AFAIK...
>
>
> > In the case of an RT audio application that reads data on /dev/dsp,
> > computes them an plays them back on /dev/dsp, is it necessary to have
> > realtime driver for the soundcard?
>
> Yes, and no. For "normal" use of the sound card, you'll need a full
> RTLinux driver (or there can be no deterinistic timing!), but there's a
> way around this:
>
> * Set the card up in shared memory mode, using the standard
>   Linux driver.
>
> * Have your RTLinux thread keep track of the playback position
>   without talking to the standard Linux driver. That is, ask
>   the card directly, or (probably better) hook the sound card
>   fragment interrupt with a PLL-like construct.
>
> * Whenever you feel like it (ie when you'r RTLinux thread is
>   scheduled), write at most (output_position - last_position)
>   samples into the shared memory buffer.
>
>
> Of course, you could implement an RTLinux driver that does this
> automatically, if you prefer to use the traditional read()/write() API in
> your application. You could probably even implement blocking, to make it
> work just like in user space.
>
>
> //David Olofson --- Programmer, Reologica Instruments AB
>
> .- M A I A -------------------------------------------------.
> |      Multimedia Application Integration Architecture      |
> | A Free/Open Source Plugin API for Professional Multimedia |
> `----------------------------> http://www.linuxdj.com/maia -'
> .- David Olofson -------------------------------------------.
> | Audio Hacker - Open Source Advocate - Singer - Songwriter |
> `-------------------------------------> http://olofson.net -'
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
> --
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/
>


-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/

Reply via email to