Subject: [linux-audio-dev] [SRC] trial API (was: acid, linux)
From: Roger Larsson (roger.larsson_AT_norran.net)
Date: pe joulu 03 1999 - 10:37:02 EST
Hi all,
First I like to notify you all about my 'trial API'
more can be read at
http://www.norran.net/nra02596/
It is not intended to become the one and only audio API.
I won't even try... See this more as a proof of concept.
Stefan Westerfeld wrote:
>
> Hi!
>
> On Wed, Dec 01, 1999 at 05:56:56PM +0100, MOULET Xavier CNET/DMR/ISS wrote:
> > [...]
>
> I can tell you what aRts is doing right now.
>
> The idea I have is moving away from CORBA towards a lighter consistent
> object model which spreads throughout aRts. The thing will be called
> MCOP, which expands to multimedia communication protocol. But keep in
> mind that it cares about communcation and object model (the things that
> were handled by CORBA before). One will write things like
>
> interface Synth_ADD {
> in audio stream signal1, signal2;
> out audio stream result;
> };
>
> in an idl file, and it will generate C++ skeleton classes, which you
> only need to implement. For Synth_ADD, this could look somthing along
> the lines:
>
> void SynthAdd_impl::calculateBlock(unsigned long cycles)
> {
> float *end = result + cycles;
>
> while(result != end) *result++ = *signal1++ + *signal2++;
> }
>
How to handle plugin with non constant data rate?
Then you will need one cycle counter per signal (including result)
I have tried to design for the most general case without closing
optimization possibilities. I could write a wrapper for your plugins,
can you write one for mine?
BTW I think this would be faster (testing against zero v. testing
against end
that has to bee in a register anyway):
void SynthAdd_impl::calculateBlock(unsigned long cycles)
{
while(cycles--) *result++ = *signal1++ + *signal2++
}
> that's about all you need to write. By the way, you could also have
> something like
>
> interface BinaryOperation {
> in audio stream signal1, signal2;
> out audio stream result;
> };
>
> interface Synth_ADD : BinaryOperation {
> //
> };
>
But what if I have additional requirements like only handling 2''n
buffer sizes?
Varying data rates?
You could add such description in the IDL.
And select plugintype depending on it - not too bad.
> which means you get the wonders of polymorphism and inheritance in your
> plugin system.
>
> [ - - - ]
>
> Perhaps other people who are still considering whether they want to do
> something similar could also join in. Basically, writing a middleware
> like MCOP is a lot of work. It is more or less as complete as CORBA (at
> least the relevant parts I used) in it's current development stadium,
> though not everything works fine yet, but it supports
>
But won't that mean that there will be several not quite CORBA
implementations
in KDE environment in the future mostly for speed reasons?
In OS/2, IBM handled that with their SOM implementation. When used it
could
link objects to the same process space, or shared in different
processors,
or via DSOM (CORBA) should't it be possible to use one ORB that is
externaly
looking like CORBA, but uses the most effective method when local.
> [ - - - ]
>
> KDE2 will use aRts as multimedia framework, which also means the sound
> server that will be running for the desktop will be implemented on top
> of that. It will also not necessarily remain an audio-only thing, video
> for instance would also be great - but that has some time.
>
> The engine is partially ported from CORBA, but it currently can't do more
> than a beep (but at least that: fully modular) - also the plugins aren't
> ported, and some infrastructure is still completely missing (Qt GUI stuff).
>
> So the dependancies aRts has are reduced to: C++ with STL (no Qt, no Mico,
> no KDE, no X11, if you really want not even Unix are required).
>
Nice!
> The code is available from the KDE CVS (kdemultimedia/arts), which you also
> can get anonymously if you like via CVSup. It is still in its experimental
> phase, but I'll port over all aRts infrastructure to MCOP in the next time,
> though that may take a while.
>
I will take a look.
/RogerL
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST