[Xenomai-help] RTDM/ALSA hybrid driver ?

[Xenomai-help] RTDM/ALSA hybrid driver ?

[Thomas Witzel]

Hello,

I'm now trying to create a sound driver that will start and stop playback in 
real time. Is it better to implement a driver for RTDM from scratch, or is it 
reasonable to just add a RTDM interface for the required functionality to an 
existing ALSA driver ? The advantage of the latter approach is of course, 
that everything that doesn't need to be done in realtime already exists 
through ALSA and I only would have to implement the pcm triggers through 
RTDM. Is that reasonable at all ?

Thomas

Re: [Xenomai-help] RTDM/ALSA hybrid driver ?

[Jan Kiszka]

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

Thomas Witzel wrote:
> Hello,
> 
> I'm now trying to create a sound driver that will start and stop playback in 
> real time. Is it better to implement a driver for RTDM from scratch, or is it 
> reasonable to just add a RTDM interface for the required functionality to an 
> existing ALSA driver ? The advantage of the latter approach is of course, 
> that everything that doesn't need to be done in realtime already exists 
> through ALSA and I only would have to implement the pcm triggers through 
> RTDM. Is that reasonable at all ?

Yes, this can be reasonable. You will fork the driver effectively, but
you should be able to reuse init/cleanup parts for this. Basically, this
is how most RTnet drivers were developed.

But how hard and how tight are your RT requirements? I'm asking because
I know that a lot of people are using unmodified ALSA drivers over the
PREEMPT_RT kernel for real-time recording, processing, and playback.
Maybe this can already provide you what you need. But I don't know the
internal design of ALSA, if there are any pitfalls hidden like dynamic
buffer management.

Jan


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

Re: [Xenomai-help] RTDM/ALSA hybrid driver ?

[Romain Lenglet]

Jan Kiszka wrote:
> Thomas Witzel wrote:
> > Hello,
> >
> > I'm now trying to create a sound driver that will start and
> > stop playback in real time. Is it better to implement a
> > driver for RTDM from scratch, or is it reasonable to just
> > add a RTDM interface for the required functionality to an
> > existing ALSA driver ? The advantage of the latter approach
> > is of course, that everything that doesn't need to be done
> > in realtime already exists through ALSA and I only would
> > have to implement the pcm triggers through RTDM. Is that
> > reasonable at all ?
>
> Yes, this can be reasonable. You will fork the driver
> effectively, but you should be able to reuse init/cleanup
> parts for this. Basically, this is how most RTnet drivers were
> developed.
>
> But how hard and how tight are your RT requirements? I'm
> asking because I know that a lot of people are using
> unmodified ALSA drivers over the PREEMPT_RT kernel for
> real-time recording, processing, and playback. Maybe this can
> already provide you what you need. But I don't know the
> internal design of ALSA, if there are any pitfalls hidden like
> dynamic buffer management.

I believe that most people wanting real-time audio use JACK 
instead of ALSA. All "serious" audio software on Linux use JACK: 
Ardour, Rosegarden, etc.
Its design allows for real-time audio, better than ALSA.
http://jackaudio.org/

I believe that you could easily port JACK to Xenomai, 
transparently for client apps, and then interface an RTDM-based 
driver to JACK.

There is already an alternative implementation of JACK 
specifically for IEEE1394 audio interfaces:
http://freebob.sourceforge.net/index.php/Main_Page
You could get inspiration from this implementation.

Regards,

-- 
Romain LENGLET

Re: [Xenomai-help] RTDM/ALSA hybrid driver ?

[Thomas Witzel]

On Wednesday 25 October 2006 23:13, Romain Lenglet wrote:
> I believe that most people wanting real-time audio use JACK
> instead of ALSA. All "serious" audio software on Linux use JACK:
> Ardour, Rosegarden, etc.
> Its design allows for real-time audio, better than ALSA.
> http://jackaudio.org/
>
> I believe that you could easily port JACK to Xenomai,
> transparently for client apps, and then interface an RTDM-based
> driver to JACK.
>
> There is already an alternative implementation of JACK
> specifically for IEEE1394 audio interfaces:
> http://freebob.sourceforge.net/index.php/Main_Page
> You could get inspiration from this implementation.

Maybe I understand this wrong, but it seems to me that Jack itself does not 
provide lowlevel drivers for the hardware, but in most cases sits on top of 
ALSA. Also most applications seem to use Jack to control other professional 
devices via MIDI or 1394.

Thomas

Re: [Xenomai-help] RTDM/ALSA hybrid driver ?

[Romain Lenglet]

Thomas Witzel wrote:
> On Wednesday 25 October 2006 23:13, Romain Lenglet wrote:
> > I believe that most people wanting real-time audio use JACK
> > instead of ALSA. All "serious" audio software on Linux use
> > JACK: Ardour, Rosegarden, etc.
> > Its design allows for real-time audio, better than ALSA.
> > http://jackaudio.org/
> >
> > I believe that you could easily port JACK to Xenomai,
> > transparently for client apps, and then interface an
> > RTDM-based driver to JACK.
> >
> > There is already an alternative implementation of JACK
> > specifically for IEEE1394 audio interfaces:
> > http://freebob.sourceforge.net/index.php/Main_Page
> > You could get inspiration from this implementation.
>
> Maybe I understand this wrong, but it seems to me that Jack
> itself does not provide lowlevel drivers for the hardware, but
> in most cases sits on top of ALSA.

JACK has several backends, including ALSA. But the Freebob 
backend does implement its own drivers, in userspace, using the 
libraw1394, etc.

Since you wanted to develop/port your own device driver anyway, I 
just suggested to use JACK as an interface with your 
applications, instead of the ALSA interface. I believe that the 
JACK API/interface is better suited for realtime applications.
So why not develop your own new JACK hard-realtime backend with 
your RTDM driver?

> Also most applications seem 
> to use Jack to control other professional devices via MIDI or
> 1394.

No. JACK has been designed to pass/route audio data in realtime 
and with low latency between applications, and to/from drivers. 
It can also route MIDI data, but that is not its main purpose.

Freebob is an implementation of a JACK backend that provides 
drivers for IEEE1394 audio interfaces, without using ALSA 
drivers.

-- 
Romain LENGLET

Re: [Xenomai-help] RTDM/ALSA hybrid driver ?

[Thomas Witzel]

On Wednesday 01 November 2006 01:58, Romain Lenglet wrote:
> Since you wanted to develop/port your own device driver anyway, I
> just suggested to use JACK as an interface with your
> applications, instead of the ALSA interface. I believe that the
> JACK API/interface is better suited for realtime applications.
> So why not develop your own new JACK hard-realtime backend with
> your RTDM driver?
I just wanted to modify an existing driver Intel8x0 AC97 to do realtime 
playback of  a sample. I'm still pursuing this.
I have implemented a regular Linux userspace application for this at first and 
it provides a response latency smaller than 1 ms for 19 out of 20 triggers, 
but the 20th (on average) has latencies up to 20ms, which is totally 
unacceptable.

Thomas

Re: [Xenomai-help] RTDM/ALSA hybrid driver ?

[Wolfgang Grandegger]

Thomas Witzel wrote:
> On Wednesday 01 November 2006 01:58, Romain Lenglet wrote:
>> Since you wanted to develop/port your own device driver anyway, I
>> just suggested to use JACK as an interface with your
>> applications, instead of the ALSA interface. I believe that the
>> JACK API/interface is better suited for realtime applications.
>> So why not develop your own new JACK hard-realtime backend with
>> your RTDM driver?
> I just wanted to modify an existing driver Intel8x0 AC97 to do realtime 
> playback of  a sample. I'm still pursuing this.
> I have implemented a regular Linux userspace application for this at first and 
> it provides a response latency smaller than 1 ms for 19 out of 20 triggers, 
> but the 20th (on average) has latencies up to 20ms, which is totally 
> unacceptable.

Linux should be able to do better than that. Is your application 
prioritized properly (check for real-time priorities with "man 
sched_setscheduler")? And the kernel option CONFIG_PREEMPT should also 
help.

Wolfgang.

Re: [Xenomai-help] RTDM/ALSA hybrid driver ?

[Thomas Witzel]

On Wednesday 25 October 2006 19:09, you wrote:
> > Fairly hard. I'm controlling a physics experiment with this (being short
> > the money for a function generator that will do exactly what I need).
> > This is going to be a nasty hack (given the time constraints to get this
> > accomplished).
>
> What order or dimension do those time constraints have? I.e. how long
> will the piece of output pattern be you can write ahead-of-time into the
> hardware?
Oh I was talking about the time constraints to get this implemented. I spent 
some more time on building the hardware interface between sound card output 
and experiment and I'm now back at the software.
The time constraint is that I'd like to playback a sound sample within 500us 
(or better if possible) of a trigger. The sample is short enough to fit in 
one period/buffer of the sound driver, so no "reloading" of the buffer is 
required.
> Well, understanding how the hardware and the original driver work will
> likely be unavoidable ;). Furthermore, be warned about interferences by
> other PCI users. Shutting them down or switching off DMA where feasible
> may be required.
I have a forked driver now, which actually still plays sound over the ALSA 
interface. I think the key routine to modify is snd_pcm_trigger, which 
basically starts,pauses,resumes or stops playback. The problem is that the 
routine is called from the layer above (somewhere in ALSA) already within a 
spin_lock, so I can't really wait directly in this routine. 
My idea would be that it would be best if the trigger routine for the START 
command would just activate a realtime thread that waits for the external 
event and then does what the trigger start would have done. 
> Jan