-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prevent data races in napaudio #31
Conversation
Thanks for this change, looking good! Unfortunately all builds are currently failing (GCC & MSVC) with the following message, which should be trivial to fix:
|
Sorry, something went wrong merging audiopin.h during the git rebase, it should be fixed now. There is one more change I should note: we decided to remove the |
Build keeps failing unfortunately, I recommend building your changes on a linux / windows machine to validate your changes:
|
It has been 2 weeks and no changes - the build is still broken. Do you expect to fix the builld for this review to continue or should I close it? Quick note on our review policy: We welcome changes but the changes must pass the build checks in order for them to be reviewed in the first place, that's what the build system is for: it ensures your code doesn't break core functionality, which it does. Simply letting the PR hang isn't very good practice either: close it if you don't wish to continue or notify us when you do. If no changes are submitted and @stijnvanbeek hasn't reviewed this change in the next two weeks I will close this PR - feel free to open a new one when ready. |
Will look at it this week! |
Hey Coen, of course, totally understand this policy. Apologies for the delay & silence, @stijnvanbeek will review it this week. For next time, I'll make sure I can test all targets on Windows myself before making a PR. |
Thanks for taking the time to fix the build, all checks pass including package validation (where all demos are tested in every environment). So probably good if @stijnvanbeek reviews this code, I'll also take a look at it after he is done, merci! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the sum buffer in the LevelMeterNode can be refactored away.
For the rest all good!
I understand the use of the sum buffer now, so all great to me. |
Only thing important to note is to mention the breaking changes:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good change, thanks & congrats on your new contributor status ;) See comments for future PRs
for (auto& sample : *inputBuffer) | ||
{ | ||
// keep track of peak, sample by sample | ||
float newValue = sample; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For future reference, local variables are never camelCase
, they are separated using an underscore: float new_value
, this allows you to differentiate between arguments and local variables, which is currently not the case. This is part of the official style guide.
@@ -27,7 +27,7 @@ namespace nap | |||
|
|||
static std::mt19937& getGenerator() | |||
{ | |||
static std::unique_ptr<std::mt19937> generator = nullptr; | |||
static thread_local std::unique_ptr<std::mt19937> generator = nullptr; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this is ok, assuming we want different random sequences for every thread. I can't think of a situation where this would be a problem atm, but considering the current implementation is not thread safe this solutions outweighs the other.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interestingly, declaring something static
in the cpp (such as the generator) is thread safe since C++ 11. Also, looking at the implementation it can be simplified to:
static std::mt19937& getGenerator()
{
static thread_local std::mt19937 generator(time(0));
return generator;
}
I'll implement and test that some other time.
These changes prevent data races warnings that were reported by the Thread Sanitizer when running our 4DSOUND software.
Changes in napaudio:
Change in napmath: