kSamplesPerCycle
-
- KVRist
- Topic Starter
- 302 posts since 19 Apr, 2005
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
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
-
- KVRist
- Topic Starter
- 302 posts since 19 Apr, 2005
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
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;
so i changed that to this:
Code: Select all
if(frameToProcess <= kSamplesPerCycle){
place = kSamplesPerCycle - offset;
}else{
place = kSamplesPerCycle + offset;
}
I'm happy now, if you want i can provide a patch fle but they are really 3 lines of code
-
- KVRer
- 8 posts since 10 Nov, 2009
-
- KVRist
- 277 posts since 3 Apr, 2007
I can't remember if this would break anything - it may affect the behavior of a few elements.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
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
-
- KVRist
- Topic Starter
- 302 posts since 19 Apr, 2005
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...
-
- KVRist
- 277 posts since 3 Apr, 2007
To clarify, you do mean 4% relative? (i.e. it went from 50% to 52%, or it went from 50% to 54%)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...
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
-
- KVRist
- Topic Starter
- 302 posts since 19 Apr, 2005
yes, from 6% to 10%...and i'm full of mul i was trying a feedback compressor, so i have muls everywhere
-
- KVRist
- Topic Starter
- 302 posts since 19 Apr, 2005
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
i went from 4-6% in my compressor to 34% that's not bad
-
- KVRist
- 277 posts since 3 Apr, 2007
Hi EcHo2K,EcHo2K wrote:yes, from 6% to 10%...and i'm full of mul i was trying a feedback compressor, so i have muls everywhere
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
-
- KVRist
- Topic Starter
- 302 posts since 19 Apr, 2005
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
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
-
- KVRist
- 277 posts since 3 Apr, 2007
If you don't want to check the whole thing out, the project state file is located at: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
$(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
-
- KVRist
- Topic Starter
- 302 posts since 19 Apr, 2005
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
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
-
- KVRist
- 277 posts since 3 Apr, 2007
Hi Saverio,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
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