iiwusynth-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [iiwusynth-devel] Fw: Re: [linux-audio-dev] more about iiwusynth


From: Peter Hanappe
Subject: Re: [iiwusynth-devel] Fw: Re: [linux-audio-dev] more about iiwusynth
Date: Tue, 11 Jun 2002 20:19:52 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417

Josh Green wrote:
> On Mon, 2002-06-10 at 19:09, Peter Hanappe wrote:
>
>>Hi Juan,
>>Hi all,
>>
>>I was a LinuxTag this weekend showing Swami and the iiwusynth so I
>>missed the whole discussion this weekend. I'll try to catch up a bit.
>>

Hey Josh!


> Tell us how it went :) I'm curious about your experience with Swami in
> particular.

I talked mostly with the other LAD'ers and not so much with the people
coming in the booth. On saturday I had a long talk with Takashi Iwai
(alsa team, sfxload, helped also on timidity). I showed him Swami and
iiwusynth. He seemed to like both a lot. I also talked to Matthias
Nagorni (alsa project) who wanted to use iiwusynth as a ladspa plugin
in his project AlsaModularSynthesizer.

Sunday I showed iiwusynth mainly to Steve Harris (are you on the mailing
list Steve?). We talked mainly about LADSPA and JACK integration (I
showed the Markus' ladspa extensions in iiwusynth).

I did do that much demo'ing. The weekend just flew by and I didn't have
a computer at my disposal. I'd like to have shown Muse + Swami +
iiwusynth, but only Frank Neuman's machine had a working Muse and he was
actively demonstrating Linux audio applications.

BTW. the release you made last week compiled and ran fine
all the two machines were I installed it.

>>So I repeat my point, yes, we should go for fixed point if that makes
>>us gain CPU. But there is CPU to gain from managing the voice releases
>>better as well.
>>
>
>
> I wonder if an MMX and/or SSE core would give us significant gains? MMX
> is INTEGER based parallel data processing, but I don't know much about
> SSE. Also, it would seem like fixed point would also give us much more
> efficient use of available sample range (all this has I think been
> mentioned).
>
> Should we start discussing ideas for better voice extinguishing? (Can
> you tell I'm trying to get involved :)
>
> Some thoughts (might be totally useless):
>
> - It might be nice to have a configurable option for how voices are
> selected for termination. The most useful value would seem to be
> percentage of CPU time (although I have no idea how this could be
> calculated) or perhaps, much easer max polyphony

Specifying max polyphony on the command line is very easy to do.
When the max polyphony is reached and a new notes comes in, a voice
stealing algorithm is used. The MIDI standard gives some guidelines
about what voices should be released first, based on channel priority
(drum channel has highest priority) and release phase.

The iiwusynth does all that, so specifying max polyphony can give
you a guarantee about maximum CPU usage.

> (a fixed number of
> voices probably wont always equal the same amount of CPU time, right?).

I would estimate that a voice take almost always the same amount of CPU.
The algorithm stays pretty much the same for all values of voice
parameters.

> Perhaps there could also be a soft and hard limit. Hitting the soft
> limit would speed up the release stage, hard limit would just cut them
> off (to allocate for new voices).

That's something that could be considered. The hard limit is the max
polyphony. The soft limit could be set at, say, 80% of the max
polyphony. It should be a option, though.

> - Once this configurable threshold has been reached (CPU time or # of
> voices) the current voices would be rated and the one with lowest
> priority would be set for rapid release (the release time could perhaps
> also be configurable?)

The MIDI standard (or DLS2 standard) specifies something along that
lines. see above.

> - Priority selection seems like where some smarts might be able to be
> implemented, the rating ideally related to _perceptible_ volume level.
>   Criteria (I seem to remember writing this before, can't remember if I
> got any response though)
>   - Volume envelope in release stage and its level (maybe take into
> account the other stages of the volume envelope also, to see if it will
> get any louder than it is currently is).
>   - Attenuation (greater values = quieter)
>   - Filter Cutoff and Filter Q (lower values of FilterFC and FilterQ =
> quieter, since as FilterQ gets higher more of the FilterFC frequency can
> be heard)

It would be good to specify that notes should be cut off below a certain
volume. Again this should be configurable. According to the soundfont
standard, it should at -100 dB but I think using -80 dB won't make a
noticeable difference in many situations.

> Perhaps a slightly silly question, but.. Does iiwusynth terminate
> samples that are not looped and have reached the end of the sample (just
> checking to see if perhaps the volume envelope is being heeded even when
> no more sample).

It does!

> Another question I have is what is taking up so much time when iiwusynth
> is running IDLE (no voices ~ 19% of my P-II 366 CPU).

Yes, Takashi and I were looking at that as well. It's inacceptable.
As a starter, turn off reverb and chorus and it will drop by half.
But that's still too much. I'll check what's taking time.

Also, the synth could go in sleeping mode when it hasn't received any
notes for a while, provided it can jump into action as soon as a note
arrives. This could be useful when the synth runs as a deamon in the
background.

Lates!
Peter

>>Cheers!
>>Peter
>>
>>
>
>
> I hope at least some of this is useful. Cheers.
>    Josh Green
>






reply via email to

[Prev in Thread] Current Thread [Next in Thread]