Re: [linux-audio-dev] XAP spec & PTAF comments [merge]

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

Subject: Re: [linux-audio-dev] XAP spec & PTAF comments [merge]
From: David Olofson (david@olofson.net)
Date: Sat Feb 08 2003 - 01:09:59 EET


On Friday 07 February 2003 23.07, Steve Harris wrote:
[...]
> > You might ove the conditionals around a bit depending on which
> > case you want to be the fastest, but I don't think it gets much
> > more fun than that.
>
> The are branchless clamps, which save a few cycles.

Cool. Would your average compiler generate that kind of code from
clean if()s, or do you have to go SIMD? (I've only seen this in SIMD
extensions and DSPs before, but I'm not up to date with the "normal"
x86 or PPC instruction sets.)

[...]
> > something out... It just seems to me that plugins have a better
> > idea how to clamp - and they can quite often use constant limits
> > as well, I guess.
>
> I'm fine with this. If the plugin can constrian the inputs itseelf,
> it seems reasonable not to have explict host support. We know it
> works, and its Simple(TM)

Yeah. It's always a good idea to consider alternatives, I guess we
haven't seen any sensible ones yet...

Any wild ideas are welcome, of course! A bit of brainstorming never
hurts.

> [silence optimisation]
>
> > I do see your point, but I'm not certain whether or not this
> > optimization is really useless for normal "one song at a time"
> > use. Some real life test data would be really interesting...
>
> You also have to weigh the cost of increased debugging dificulty,
> and the erros when lugins mis-estimate thier silence state.

Yeah, that's one of the reasons why I can't quite make up my mind on
this. This feature is not for free, so it has to be seriously
motivated.

Besides, if you have seriously heavy plugins in combination with this
"a few effects at a time" behavior, the host could probably optimize
this a bit without plugins explicitly supporting it. It means the
host has to test buffers and figure out a clean way of activating and
deactivating plugins without side effects, but if the plugins, or
whole sub nets of plugins can be disabled, it's still a big win.
...and doesn't require any API support whatsoever, apart from the
(de)activation stuff, which is needed anyway.

BTW, just testing a buffer for silence by sampling it in a "smart"
pattern shouldn't cost much when there is audio in it. Looping would
usually stop after the first test.

Hmm... Do P-III and up have bit reverse instructions? (I remember
*some* old thing having it, but I can't remember if that was a DSP or
something else.)

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---


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

This archive was generated by hypermail 2b28 : Sat Feb 08 2003 - 01:09:48 EET