Re: [linux-audio-dev] discussion about development overlap

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] discussion about development overlap
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Thu Sep 28 2000 - 18:52:41 EEST


On Thu, 28 Sep 2000, Paul Barton-Davis wrote:

>
> >I hope that someday "pro" apps like Ardour can be converted to this
> >model. (the audio thread has to be basically completely non-blocking
> >and can't wait o n mutexes etc, and I do not know how hard this would
> >be to do in Ardour (basically you have to transform mutexes into
> >lock-free message passing (which is sometimes more complicated than
> >simply locking a variable))
>
> ardour's audio thread doesn't block for anything except page faults
> and the audio device. page faults will not happen either away if
> mlockall() is called. there are no mutexes and no system calls in the
> audio thread once it starts running its main loop.

sounds good !
just for completeness, one more question:
(no time to read your code for now :-( )

How do you manage audio<-->GUI and audio<-->diskthread
communicaion ?
For the transfer of samples between disk thread and audio thread,
you probably use shared mem with some sort of lock-free structure,
but how do you handle commands, like:
start , stop adio, change position, etc etc.
Do you use shared variables to do this, or do you use some sorf of messagin ?
And are there structures in ardour that need to be shared between the
audio thread and other threads ?
If yes, how do you manages this (so that races are avoided) ?

Sorry for all these questions, but it will help be to understand if Ardour can
be easily adapted to run as a rt-plugin, plus it will perhaps help me
to understand better the needs of a complex HDR app so that the
rtsoundserver API can be designed with this in mind.

(more discussions will follow, because EVO will need a GUI too, which
has to interact well with the RT-part of the app (must ensure a great deal of
control flexibiltiy, but without adding points of non-determinism within the
audio thread)
And I think that we can certianly reuse some of these gui-audio interaction
ideas you've put into ardour.)

thanks,
Benno.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Sep 28 2000 - 18:19:03 EEST