SonicBirth

EcHo2K · Post by **EcHo2K** » Thu Nov 12, 2009 1:22 pm

Hi everyone, i think this goes to the devs or anyone who has deep SB knowledge...

for one circuit i was designing i needed a very fast feedback loop and looking at the source it seems that the feedback is actually passed only every cycle, of course the original kSamplesPerCicle is 4096, so 92ms @44100, too long for my needs.

I checked out the svn and had a quick look to the code and found the constant: kSamplesPerCycle, i lowered it to 256 samples and now i get a feedback short enough...is there any warning in doing this?

why 4096 was choosen? there surely must be a very logic rason, but i think that i general having tighter processing loops allows for more realtime control, am i wrong in some way?

thank you

Saverio

EcHo2K · Post by **EcHo2K** » Fri Nov 13, 2009 1:13 am

i reply to myself:

the problem is that lowering kSamplesPerCycle _BELOW_ the frame lenght sent by the vst/au host crashes the host

i had ablton live set @ 512 samples for plugin buffer anf kSamplesPerCycle @ 256 and Live was crashing as soon as the second half f the block was being executed by sonicbirth. The i had a look at the vst runtime code:

Code: Select all

place = kSamplesPerCycle - offset;

this line contains a small bug in IMHO, it always believe that kSamplesPerCycle is going to be _LARGER_ than the host buffer size, this doesn't have to be always true.

so i changed that to this:

Code: Select all

if(frameToProcess <= kSamplesPerCycle){
    place = kSamplesPerCycle - offset;
}else{
    place = kSamplesPerCycle + offset;
}

doing this i've been able to get my plug to run smoothly in Ableton Live 7 (i don't have other hosts to try) and i had kSamplesPerCycle as low as 128 samples without any performance hit on my macbook

I'm happy now, if you want i can provide a patch fle but they are really 3 lines of code

Subsun · Post by **Subsun** » Fri Nov 13, 2009 4:09 am

Interesting stuff, thanks for posting.

eigentone · Post by **eigentone** » Fri Nov 13, 2009 6:25 am

EcHo2K wrote:i reply to myself:

the problem is that lowering kSamplesPerCycle _BELOW_ the frame lenght sent by the vst/au host crashes the host

i had ablton live set @ 512 samples for plugin buffer anf kSamplesPerCycle @ 256 and Live was crashing as soon as the second half f the block was being executed by sonicbirth. The i had a look at the vst runtime code:
...
this line contains a small bug in IMHO, it always believe that kSamplesPerCycle is going to be _LARGER_ than the host buffer size, this doesn't have to be always true.

so i changed that to this:
...
doing this i've been able to get my plug to run smoothly in Ableton Live 7 (i don't have other hosts to try) and i had kSamplesPerCycle as low as 128 samples without any performance hit on my macbook

I'm happy now, if you want i can provide a patch fle but they are really 3 lines of code

I can't remember if this would break anything - it may affect the behavior of a few elements.

The threshold of noticeable performance hit in this case is likely to be around 32 samples/invocation and increase quickly as you approach 1. There should be a performance hit now, but it is probably a few % (rel) because the number of additional function calls is a very small percentage of the real work.

There are a few cases (such as your current case) where 128 is useful, but the common threshold of application is at 1 sample, which I expect to be several times as cpu intensive.

I should do this test, I'm actually really curious, and 1 sample is where SB should ultimately be (in some form) for usability/complex circuits. I know it needs to be introduced, but I know there are people who will not be happy because the performance will be worse - the capability factor outweighs the performance factor. At this level, SB couldn't compete with commercial plugs wrt to performance, and it would take a good amount of time to get it near the same level as other realtime modulars.

Justin

EcHo2K · Post by **EcHo2K** » Fri Nov 13, 2009 4:52 pm

just to add that lowering to 64 samples causes a 4% performance hit...nothing scientific, just from observation, and BTW all my tests are done in my circuit so it may differ...i don't know...

eigentone · Post by **eigentone** » Fri Nov 13, 2009 5:03 pm

EcHo2K wrote:just to add that lowering to 64 samples causes a 4% performance hit...nothing scientific, just from observation, and BTW all my tests are done in my circuit so it may differ...i don't know...

To clarify, you do mean 4% relative? (i.e. it went from 50% to 52%, or it went from 50% to 54%)

It will vary greatly by circuit. It's really the proportional difference of what is being processed, so small functions, like multiply will do far worse (by proportion) than more complex elements which possess no state.

Thanks,

Justin

EcHo2K · Post by **EcHo2K** » Fri Nov 13, 2009 5:19 pm

yes, from 6% to 10%...and i'm full of mul

i was trying a feedback compressor, so i have muls everywhere

EcHo2K · Post by **EcHo2K** » Fri Nov 13, 2009 5:23 pm

oh btw i tried to set the constant to 1 sample...

i went from 4-6% in my compressor to 34%

that's not bad

eigentone · Post by **eigentone** » Fri Nov 13, 2009 5:45 pm

EcHo2K wrote:yes, from 6% to 10%...and i'm full of mul i was trying a feedback compressor, so i have muls everywhere

Hi EcHo2K,

Thanks a lot for doing the tests.

Oh, absolute, that's a more difficult measurement to use in this context. So the relative base is kSamplesPerCycle at its default value, if that is at 50% cpu consumption, then it is most meaningful to change the constant (kSamplesPerCycyle), measure the difference (assuming you have done everything in your power to evaluate the weight of the host and the rest of the processing), and use the equation:

Speed = New_CPU_Use / Orignal_CPU_Use

Using the numbers you measured at 1 sample:

Speed = 34 / 5

Dropping down to 1 sample in this case is 6.8x. There's actually a lot that can be done to optimize for per sample rendering - 6.8x is not what you should expect as a performance hit if you see it as a new feature someday, but it will be more than 1. The speed is actually better than I expected (though I think you are using 1.3).

Using higher percentages of CPU will give you more estimations of your evaluation, especially if you make a circuit larger, as opposed to simply creating more instances. Either way, no need to go crazy on this. We have programs to analyze performance at the low levels, so you don't need to try this, unless you're just curious.

J

EcHo2K · Post by **EcHo2K** » Sat Nov 14, 2009 3:17 am

yes i'm using 1.3 since i don't know the status of the 1.5 release and i was going to mess with some internal processing and didn't want to make stuff more complicated using an unstable release.
Btw, the numbers i gave you are the numbers reported by sonicbirth itself as the "audio cpu usage" for my circuit, and sorry but today i was at my dayjob and i forgot to mention that thos numbers are ceated with the _DEVELOPMENT_ compiler profile so no code optimization and alot of debug symbols

eigentone · Post by **eigentone** » Sat Nov 14, 2009 4:44 am

EcHo2K wrote:yes i'm using 1.3 since i don't know the status of the 1.5 release and i was going to mess with some internal processing and didn't want to make stuff more complicated using an unstable release.
Btw, the numbers i gave you are the numbers reported by sonicbirth itself as the "audio cpu usage" for my circuit, and sorry but today i was at my dayjob and i forgot to mention that thos numbers are ceated with the _DEVELOPMENT_ compiler profile so no code optimization and alot of debug symbols

If you don't want to check the whole thing out, the project state file is located at:
$(PROJECT_ROOT)/ProjectState.rtf

Currently (1.5.0 alpha rev2), that is:
http://sonicbirth.svn.sourceforge.net/v ... evision=86

rev 3 is in the cannon.

Thanks for clarifying the test environment, it does make a difference.

J

EcHo2K · Post by **EcHo2K** » Wed Nov 18, 2009 11:35 am

Hi i've found some time to compile and test 1.5_ar2, is this the right branch?

anyway, kSamplesPerCycle set to 64, i actually have _LESS_ performanche than with the 1.3 branch.

Both sonicbirth compiled with the deployment settings and tested with the same circuit and a costant sinewave.

1.3 reads between 2.5 and 3.4 audio process load
1.5_ar2 reads between 3 and 4.5 audio process load

is this expected?

Is there any documentation on the internal workinng of SonicBirth so i can have alook to potential bottlenecks?

Thank you
Saverio

eigentone · Post by **eigentone** » Thu Nov 19, 2009 6:13 am

EcHo2K wrote:Hi i've found some time to compile and test 1.5_ar2, is this the right branch?

anyway, kSamplesPerCycle set to 64, i actually have _LESS_ performanche than with the 1.3 branch.

Both sonicbirth compiled with the deployment settings and tested with the same circuit and a costant sinewave.

1.3 reads between 2.5 and 3.4 audio process load
1.5_ar2 reads between 3 and 4.5 audio process load

is this expected?

Is there any documentation on the internal workinng of SonicBirth so i can have alook to potential bottlenecks?

Thank you
Saverio

Hi Saverio,

That was the right branch when you wrote it. SonicBirth_1_5_ar3 is now live (by all means, a developer branch).

Speed: Whether that is expected, I really don't remember the project state, or build settings of that branch (it was the state as of 7-8 months ago). It was far from an official release, just a milestone commit. If you're looking to measure 'speed', then speed testing the circuit multiple times will be the a good measurement tool.

You can ask me about the inner workings (well, to an extent - I'll expect you to do some research before asking for a write up on any given topic). It's not documented well because it is in a transitionary state, and documentation is not needed internally. Since nobody will find transitional documentation useful, I won't add it, because it will only slow down development.

Regarding performance bottlenecks, yes, try:
$(DEVELOPER_DIR)/Applications/Performance Tools/Shark.app

where DEVELOPER_DIR is '/Developer/' by default, unless you installed Xcode elsewhere.

Today's commit isn't poised to be 'the fastest version'. The project has been off the mainline for some time. There has been many significant internal changes.

I've been building against the 10.6 CoreAudio dependent headers so... you'll likely need them installed (their distribution directory has changed), unless you alter the file references in Xcode. As a result, Xcode 3 is the minimum version.

J