[Top][All Lists]

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

Re: [fluid-dev] Voice-stealing logic, and more

From: Elimar Green
Subject: Re: [fluid-dev] Voice-stealing logic, and more
Date: Thu, 5 Aug 2010 22:27:10 -0700

I think I forgot to reply to this message..

On Sun, Jul 4, 2010 at 2:04 AM, David Henningsson
<address@hidden> wrote:
> On 2010-07-04 05:21, Elimar Green wrote:
> Hmm, I'll go with 1.1.2, the changes don't bring in any cool new
> features, from the user end point this is more of a bug fix release.

Sounds good.

>> Both of those sound good.  We could even go as far as making each
>> driver its own dynamically loaded plugin.  There is code in Swami
>> which does this using glib, which may be useful as a reference.
> Seen from a packagers perspective, are you expecting the packager to
> output one package for each driver then?

I don't usually think in terms of packaging, so good point.  I guess
if drivers were built as plugins it might make sense to have
individual packages for each, to customize dependencies.

>> Yes, I think the synth process could do a volume calculation for each
>> voice, perhaps taking into account whether the volume may increase
>> (currently attack stage, etc).  This value could be atomically
>> written/read and used in the voice stealing logic.  Thats just a quick
>> thought on it though, might be overlooking something.
> That's a solution, I just don't like having to spend CPU time updating
> things that are so seldom used.
> I have been thinking about a compromise which would mean duplicating the
> volume envelope (i e the voice and the rvoice has one copy each) and
> then the renderer overhead would be to just atomically update
> synth->ticks. What do you think about that?

Not sure if this is still applicable or not..  But I didn't really
understand it anyways.  The volume envelope doesn't really tell you
how loud a sound is.  I think the previous voice overflow code tried
to determine the lowest volume voice in its kill algorithm.  There was
and still is, I think, a sample variable which stores a value related
to how much attenuation is needed before a given sample is determined
to be too quiet to be perceived.  Perhaps that value could be used in
conjunction with the volume envelope information, to have an
understanding of how quiet a voice currently is.

> // David



reply via email to

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