Subject: Re: [linux-audio-dev] Draft: Audiality article for MusicStation
From: David Olofson (audiality_AT_swipnet.se)
Date: ti loka 05 1999 - 17:09:47 EDT
On Tue, 05 Oct 1999, Guenter Geiger wrote:
> David Olofson writes:
> >
> > Currently, it seems to be evolving into an open design/standardization
> > effort, where a plug-in API and a client/server API currently have higher
> > priority than the actual implementation. The implementation itself may
> > actually end up as a part of some other project.
> >
>
> ... and thatīs the sentence with most relevance for the Plugin API
> specification. I think we should keep Audiality in mind by designing
> the API, as it stands for one kind of application with very special needs.
>
> But, yes there are other applications for the API, which are to be
> considered as well ... hmmm ... someone ever thought
> of doing audio processing faster than realtime ?
> Thatīs what most soundeditors are about :) (donīt need to tell you).
I see no problem here... Plug-ins and sub nets of plug-ins sync to the data
streams, and the event system's time stamps are sample frames. Real time
systems sync to the I/O devices, while off-line systems sync to the hard drive
(or whatever media used).
> As a last word, we should start to build a basis for the API
> definition by probably writing a kind of RFC, which will be updated
> and reposted each week or two for discussion on audiodev.
>
> It is interesting who else (especially authors of applications)
> want to take part in the discussion.
Agree.
> We may write to authors of audio applications, who probably donīt
> read the discussion and ask them what they think about it and
> if the like to take part.
Actually, I'd like to hear from other kinds of multimedia developers as well.
If the buffers + event system foundation of the plug-in API can be kept as low
level and generic as I'd like, there's no excuse for dedicating it to audio.
POSIX I/O, /dev, IPC and pipes works well for most things. This is about the
same thing, but with optimized real time streaming support.
> This way we will see potential problems very fast and can react to
> them.
Yep, and that's why I'd like to see some prototype implementations soon, so
that lower level or more obscure design flaws can be found as well.
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST