Subject: Re: [linux-audio-dev] audio interference or ... ?
From: David Olofson (audiality_AT_swipnet.se)
Date: pe loka 15 1999 - 20:04:20 EDT
On Sat, 16 Oct 1999, Paul Barton-Davis wrote:
> >Oh, BTW, you *are* ramping to new levels with sample accuracy when
> >the controllers are moved, right? If you don't, you'll get clicks
> >and/or a soft, buzzing sound when moving the faders...
>
> well, not i am not doing this yet. once we get the plugin API worked
> out, i'll work on an engine that does this with sample accuracy. for
> now, its block-size quantized. the noise is probably there, though I
> don't hear it, but its not something i am worried about at this point.
You could get away with zero crossing triggering as well (used in
some digitally controlled amplifiers), but I'm afraid that's more
expensive than ramping on a CPU...
> actually, now that I'm mentioning the plugin API again, i've been
> wondering about your response to my last long-ish message regarding
> addressing, engine deMUX efficiency etc. i've assumed that you're busy
> with other things, a not entirely unreasonable state to be in :)
Well, I've kind of had a cerebral database overload here with all
this, work, and then trying to get the new ATI Rage 128 X-server to
work. (Would like to testdrive the iiyama 22"er with a card that can
do better than 1600x1200 @ 85 Hz - impressive monitor BTW;
recommended! :-)
What's the date/time of that post, in case I'm not thinking about
the right one?
Anyway, I have a few other interesting problems to solve:
1) Huge block transfers
* Jaroslav dreamt about sending an entire sampled
instrument as an event. Why not throwing in a
request/reply event that lets you do asynchronous
I/O? Network transparent and all... Real time or
off-line, AND, it means you can do asynchronous
stuff from within plug-ins! (The latter is
probably a bad habit in most cases...)
* The event system's memory allocator is meant for
small events, =< 256 bytes or so. Getting rid of
that restriction would most likely mean a
significant performance hit in the average case.
Therefore, "huge blocks" should be added as a
higher level, so that you only get the
performance hit when there really is no way
around it.
* Note that the normal events are always in locked
memory (real time...), while "huge blocks"
needn't be.
Simply a more flexible, but also slightly more expensive way of
sending data.
2) Variable data (audio) buffer size
* For compressed formats, variable sample rates, ...
* Memory allocation? This can be big buffers, so
it's getting tricky... So far, I've been thinking
"specified maximum size", as that's about the
only thing that works in a hard real time system.
Do we use "audio ports" (let's call them "stream ports" or
something...) for this at all, or should the "huge block" event
protocol be used here? That is, should the stream ports actually
support dynamic buffer size, or should an event system extension
carry that "special" feature? Unless "variable rate streams" really
*can* be supported with virtually no performance hit for constant
rate streams, I think this is the way to go. It would keep the extra
complexity out of plug-ins that don't use it anyway.
3) The name of the standard! :-)
* Currently referred to as MCS -
The Multimedia Communication System
* MuCoS
* MInT - Multimedia Integration Toolkit
* MICS - Multimedia Integration & Communication Standard
* ReTMIS - Real Time Multimedia Integration Standard
* ...or whatever... We had a few other suggestions a
while ago. Some cut'n'paste perhaps...
*zzrr... rattle* Found sum'!
> LAPS Linux Audio Plugin Standard
> LAPLAND Linux Audio Plugin
> Language and Design LAPI Linux Audio Plugin Interface
> YAPI Yet Another Plugin Interface
> TAPDANCE The Audio Plugin Definition ANd Connection Extension
> LAPDOG Linux Audio Plugin Definition
> SOCKET Sound Connection and Key Extension Tools
> GACK GNU Audio Connector Kit
> TEDIUM This Extension Definition Is Under new Management
> inVeST is not VeST
I also wrote a post on a games programming site regarding "sounds &
ambience" in games. The system I describe there (although a bit heavy
for games, unless most of the advanced features proposed are left out)
illustrates one kind of processing that I'd like to be able to do
with MCS... (I'm Mr. Harmony on that board.)
http://www.lionhead.co.uk/forums/Forum4/HTML/002387.html
And I posted a note on the design efforts as well, to see if we could
possibly get some audio hackers to reveal the weaknesses of the Dark
Side, so that we can avoid doing the same mistakes. :-)
http://www.lionhead.co.uk/forums/Forum4/HTML/002386.html
//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:59 EST