On 12/03/2013 5:58 AM, Nigel Redmon wrote:
// round up to nearest power of two
unsigned int v = theSize;
v--;// so we don't go up if already a power of 2
v |= v >> 1;// roll the highest bit into all lower bits...
v |= v >> 2;
v |= v >> 4;
v |= v
On 15/03/2013 7:27 AM, Sampo Syreeni wrote:
Quite a number of processors have/used to have explicit support for
counted for loops. Has anybody tried masking against doing the inner
loop as a buffer-sized counted for and only worrying about the
wrap-around in an outer, second loop, the way we do i
On 15/03/2013 6:02 AM, jpff wrote:
"Ross" == Ross Bencina writes:
Ross> I am suspicious about whether the mask is fast than the conditional for
Ross> a couple of reasons:
Ross> - branch prediction works well if the branch usually falls one way
Ross> - cmove (conditional move instruction
RBJ's response would fit into that category I think Sampo (:
On Thu, Mar 14, 2013 at 1:27 PM, Sampo Syreeni wrote:
> On 2013-03-14, jpff wrote:
>
>> I did the comparison for Csound a few months ago. The loss in using
>> modulus over mask was more than I could contemplate my users accepting.
>
>
>
On 2013-03-14, jpff wrote:
I did the comparison for Csound a few months ago. The loss in using
modulus over mask was more than I could contemplate my users
accepting.
Quite a number of processors have/used to have explicit support for
counted for loops. Has anybody tried masking against doin
On 14/03/2013 19:02, jpff wrote:
"Ross" == Ross Bencina writes:
Ross> I am suspicious about whether the mask is fast than the conditional for
Ross> a couple of reasons:
Ross> - branch prediction works well if the branch usually falls one way
Ross> - cmove (conditional move instructio
I'm sure it varies from hardware to hardware too, so always good to
know your options
On Thu, Mar 14, 2013 at 12:02 PM, jpff wrote:
>> "Ross" == Ross Bencina writes:
>
> Ross> I am suspicious about whether the mask is fast than the conditional for
> Ross> a couple of reasons:
>
> Ross> -
> "Ross" == Ross Bencina writes:
Ross> I am suspicious about whether the mask is fast than the conditional for
Ross> a couple of reasons:
Ross> - branch prediction works well if the branch usually falls one way
Ross> - cmove (conditional move instructions) can avoid an explicit branch
To: music-dsp@music.columbia.edu
Subject: Re: [music-dsp] Efficiency of clear/copy/offset buffers
On 3/11/13 4:25 PM, Theo Verelst wrote:
A lot of the considerations of course have to do with trying to make
maintainable, and therefore readable code.
...
Of course fancy looking constructs are cool, probably
On 3/11/13 4:25 PM, Theo Verelst wrote:
A lot of the considerations of course have to do with trying to make
maintainable, and therefore readable code.
...
Of course fancy looking constructs are cool, probably in industry it
is sometimes the only way to keep secrets from the competition,
ha
A lot of the considerations of course have to do with trying to make
maintainable, and therefore readable code. That's good, but it often is
not all too clear what DSP constructs have to do with enums or digital
logic definitions, even though of course the P in DSP is done by digital
logic.
V
actually a way to do it is to create these power-of-2 circular buffers
at one level (like a higher "system" level) and allocate delay lines
*within* an already-created circular buffer. you might need more than
one circular buffer if you have, inside your algorithm or system of
algorithms, di
A way to do it at run time (the caller requests an arbitrary size, the routine
enforces a power of 2):
// round up to nearest power of two
unsigned int v = theSize;
v--;// so we don't go up if already a power of 2
v |= v >> 1;// roll the highest bit into all lower
interesting idea about rounding up and letting multiple buffers using
the memory. Very nice.
I just wanted to add on the front of enforcing powers of 2 sizes, the
way you have it where you pass in an integer and it understand that as
a power of 2 is nice but of course a little less intuitive to t
On 3/11/13 11:19 AM, Phil Burk wrote:
Regarding power-of-2 sized circular buffers, here is a handy way to
verify that a bufferSize parameter is actually a power-of-2:
int init_circular_buffer( int bufferSize, ... )
{
assert( (bufferSize & (bufferSize-1)) == 0 )
...
might be silly, but a way
Regarding power-of-2 sized circular buffers, here is a handy way to
verify that a bufferSize parameter is actually a power-of-2:
int init_circular_buffer( int bufferSize, ... )
{
assert( (bufferSize & (bufferSize-1)) == 0 )
Phil Burk
--
dupswapdrop -- the music-dsp mailing list and website:
s
>>On Mar 9, 2013, at 9:23 PM, robert bristow-johnson >>audioimagination.com> wrote:
>> if it's a wavetable and you're doing linear interpolation, a simple
>>trick is to copy x[0] to x[256] (make a 256 point wavetable a 257
>>element array) do the AND only for the first sample in the linear
>>i
On Mar 9, 2013, at 9:23 PM, robert bristow-johnson
wrote:
> if it's a wavetable and you're doing linear interpolation, a simple trick is
> to copy x[0] to x[256] (make a 256 point wavetable a 257 element array) do
> the AND only for the first sample in the linear interpolation, the follow
> sa
On 10/03/2013 05:23, robert bristow-johnson wrote:
..
ANDing with 2^p - 1 is a well-known and oft-used technique in C.
probably the best way to do it in C.
...
if it's a wavetable and you're doing linear interpolation, a simple
trick is to copy x[0] to x[256] (make a 256 point wavetable a 257
>>> Though recent gcc versions will replace the above "a/3.14" with a
>>> multiplication, I remember a case where the denominator was constant
>>> as well but not quite as explicitly stated, where gcc 4.x produced a
>>> division instruction.
>>
>> not necessarily: in floating point math a/b and a *
On 10/03/2013 3:51 PM, Alan Wolfe wrote:
> index = index + 1;
> if (index >= count)
> index = 0;
Another, more compact way could be to do it this way:
index = (index + 1) % count;
I am suspicious about whether the mask is fast than the conditional for
a couple of reasons:
- branch pred
On 10/03/2013 7:01 AM, Tim Goetze wrote:
[robert bristow-johnson]
>On 3/9/13 1:31 PM, Wen Xue wrote:
>>I think one can trust the compiler to handle a/3.14 as a multiplication. If it
>>doesn't it'd probably be worse to write a*(1/3.14), for this would be a
>>division AND a multiplication.
>
>th
On 3/9/13 11:51 PM, Alan Wolfe wrote:
There's a neat technique to do this faster that I have to admit i got
from Ross's code a few years ago in his audio library PortAudio. That
technique requires that your circular buffer is a power of 2, but so
long as that is true, you can do an AND to get th
Hey while we are on the topic of efficiency and the OP not knowing
that division was slower...
Often times in DSP you'll use circular buffers (like for delay buffers
for instance).
Those are often implemented by having an array, and an index into the
array for where the next sample should go. Wh
[Tim Blechmann]
>> Though recent gcc versions will replace the above "a/3.14" with a
>> multiplication, I remember a case where the denominator was constant
>> as well but not quite as explicitly stated, where gcc 4.x produced a
>> division instruction.
>
>not necessarily: in floating point math a/
>>> I think one can trust the compiler to handle a/3.14 as a multiplication. If
>>> it
>>> >> doesn't it'd probably be worse to write a*(1/3.14), for this would be a
>>> >> division AND a multiplication.
>> >
>> > there are some awful crappy compilers out there. even ones that start
>> > from gn
[robert bristow-johnson]
> On 3/9/13 1:31 PM, Wen Xue wrote:
>> I think one can trust the compiler to handle a/3.14 as a multiplication. If
>> it
>> doesn't it'd probably be worse to write a*(1/3.14), for this would be a
>> division AND a multiplication.
>
> there are some awful crappy compilers o
> There is some discussion here:
> http://www.kvraudio.com/forum/viewtopic.php?t=348751
Hey Ross, this was a good thread. So the pcture I'm getting is this:
1) a gain curve that is linear in dB will produce an ideal profile where equal
incremental movements along the curve produce an equal ch
On Mar 8, 2013, at 10:55 PM, Ross Bencina wrote:
> If your input is MIDI master volume you have to map from the MIDI value range
> to linear gain (perhaps via decibels). Maybe there is a standard curve for
> this?
There may be standards for subsets, such as GM. Or perhaps even a more global
s
On 3/9/13 1:31 PM, Wen Xue wrote:
I think one can trust the compiler to handle a/3.14 as a
multiplication. If it doesn't it'd probably be worse to write
a*(1/3.14), for this would be a division AND a multiplication.
there are some awful crappy compilers out there. even ones that start
from g
ssion list for music-related DSP
Subject: Re: [music-dsp] Efficiency of clear/copy/offset buffers
On Mar 8, 2013, at 2:53 PM, ChordWizard Software
wrote:
But some are quite new - I never realised that multiplication ops were
more efficient than divisions.
Worthy of some background...
When multip
On Mar 8, 2013, at 2:53 PM, ChordWizard Software
wrote:
> But some are quite new - I never realised that multiplication ops were more
> efficient than divisions.
Worthy of some background...
When multiplying, you can do all the necessary multiplications in parallel
(think of performing a long
On 9/03/2013 2:55 PM, Ross Bencina wrote:
Note that audio faders are not linear in decibels either, e.g.:
http://iub.edu/~emusic/etext/studio/studio_images/mixer9.jpg
There is some discussion here:
http://www.kvraudio.com/forum/viewtopic.php?t=348751
Ross.
--
dupswapdrop -- the music-dsp m
On 9/03/2013 9:53 AM, ChordWizard Software wrote:
Maybe you can advise me on a related question - what's the best
approach to implementing attenuation? I'm guessing it is not
linear, since perceived sound loudness has a logarithmic profile - or
am I confusing amplifier wattage with signal ampli
On 3/8/13 5:53 PM, ChordWizard Software wrote:
Ross, Alan, Robert, thanks for the comments.
It's all good sense and very helpful as a reality check. I had considered some
of these concepts already, it's good to get these validated (and expanded).
But some are quite new - I never realised that
Ross, Alan, Robert, thanks for the comments.
It's all good sense and very helpful as a reality check. I had considered some
of these concepts already, it's good to get these validated (and expanded).
But some are quite new - I never realised that multiplication ops were more
efficient than d
On 3/7/13 10:11 PM, Alan Wolfe wrote:
Quick 2 cents of my own to re-emphasize a point that Ross made -
profile to find out which is fastest if you aren't sure (although it's
good to ask too in case different systems have different oddities you
don't know about)
Also, if in the future you have pe
Quick 2 cents of my own to re-emphasize a point that Ross made -
profile to find out which is fastest if you aren't sure (although it's
good to ask too in case different systems have different oddities you
don't know about)
Also, if in the future you have performance issues, profile before
acting
Stephen,
On 8/03/2013 9:29 AM, ChordWizard Software wrote:
a) additive mixing of audio buffers b) clearing to zero before
additive processing
You could also consider writing (rather than adding) the first signal to
the buffer. That way you don't have to zero it first. It requires having
a "w
Greetings, and apologies in advance for bringing up what must be a well-covered
topic on this list, I just couldn't find it in the archives anywhere.
I'm in the final stages of building an audio host/synth engine in C++, and of
course a large part of its realtime workload is building and transfe
40 matches
Mail list logo
