Skip to content
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

Refactor message passing #337

Merged
merged 19 commits into from
Jul 27, 2023
Merged

Conversation

b-ma
Copy link
Collaborator

@b-ma b-ma commented Jul 19, 2023

Work in progress regarding #315

@github-actions

This comment was marked as off-topic.

@github-actions

This comment was marked as off-topic.

@github-actions

This comment was marked as off-topic.

@github-actions

This comment was marked as off-topic.

@github-actions

This comment was marked as off-topic.

@b-ma b-ma marked this pull request as ready for review July 21, 2023 12:59
@b-ma
Copy link
Collaborator Author

b-ma commented Jul 21, 2023

Ok I think this is all done, just two notes on the PannerNode:

  • What I did is kind of dirty with the HrtfState, didn't want to fight with the borrow checker, and should be cleaned. But I think this is a good first step and the message channel has been removed.
  • Also added the set_orientation and set_position methods. I know they are marked as deprecated by they are used in the wpt, so it sounds quite logical to implement them I guess. In any case this is very easy to revert.

Edit: I tried to follow the pattern proposed by @uklotzde in the AudioBufferSourceNode, let me know if I misunderstood something

Copy link
Contributor

@uklotzde uklotzde left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be easier for review to refactor the node types one after another. All these changes are not dependent on each other.

atomic::{AtomicBool, Ordering},
Arc, Mutex,
};
use super::{AudioNode, ChannelConfig, ChannelConfigOptions, ChannelInterpretation};

/// Scale buffer by an equal-power normalization
fn normalization(buffer: &AudioBuffer) -> f32 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated: Why does this function name does not start with a verb as usual?

ref_distance: Arc<AtomicF64>,
max_distance: Arc<AtomicF64>,
rolloff_factor: Arc<AtomicF64>,
cone_inner_angle: AtomicF64,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why still individual atomics instead of an inner typed wrapped into a single RefCell as demonstrated in in the AudioBufferSourceNode? This also applies to all other node types as far as I could see.

@uklotzde
Copy link
Contributor

This PR does not seem to fix the soundness errors that are potentially causing inconsistencies in multi-threaded contexts.

@orottier
Copy link
Owner

orottier commented Jul 22, 2023

This PR does not seem to fix the soundness errors that are potentially causing inconsistencies in multi-threaded contexts.

Yeah, I think @b-ma is keeping these things separate for now.
This PR addresses the leftover nodes that do not use message passing yet, as described in #315
Indeed this introduces soundness issues, but let's decide on the way forward first in #344 . I won't release in the meantime
(I'm a bit busy at the moment but will propose something shortly)

Edit, I just read

Edit: I tried to follow the pattern proposed by @uklotzde in the AudioBufferSourceNode, let me know if I misunderstood something

but I still think it is fine to keep matters separate for now

@b-ma
Copy link
Collaborator Author

b-ma commented Jul 22, 2023

Edit, I just read

Edit: I tried to follow the pattern proposed by @uklotzde in the AudioBufferSourceNode, let me know if I misunderstood something

but I still think it is fine to keep matters separate for now

Yup that was the idea, I was actually thinking about the post_message / onmessage pattern used for the AudioBuffer and control messages

@@ -11,8 +11,11 @@ use super::{AudioNode, AudioScheduledSourceNode, ChannelConfig};
// dictionary ConstantSourceOptions {
// float offset = 1;
// };
// @note: this does not extend AudioNodeOptions in the spec, why?
// https://webaudio.github.io/web-audio-api/#ConstantSourceOptions
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AudioNodeOptions are useless for source nodes, because they instruct how to upmix the inputs.
This is a common source of confusion, see e.g. mdn/content#18472
Also for the spec editors because they accidentally let OscillatorOptions extend AudioNodeOptions

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added your note and link to the comment, so we don't forget again. I will try to align this to other nodes as well later

// dummy convolver used to init renderer
fn tombstone() -> Self {
// just use arbitrary common sample rate
let padded_buffer = AudioBuffer::from(vec![vec![0.; 0]; 1], 48000.);
Copy link
Owner

@orottier orottier Jul 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This allocates (non-empty vec). I think you can reuse the tombstone from AudioBufferSourceRenderer

Edit: oh this is not very important because we don't use it in the renderer..

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found a way to make it more clean in any case

@orottier
Copy link
Owner

I have improved the HRTF-loading in the panner node.
You ran into issues because the onmessage handler receives an &mut of the message. So if you need to take out a value that is not Copy or Clone, you need to place back a tombstone or, when that's not easily created, wrap the inner value in an Option so you can take it out.

I will have a closer look at the other changes tomorrow.

@b-ma
Copy link
Collaborator Author

b-ma commented Jul 23, 2023

I have improved the HRTF-loading in the panner node.
You ran into issues because the onmessage handler receives an &mut of the message. So if you need to take out a value that is not Copy or Clone, you need to place back a tombstone or, when that's not easily created, wrap the inner value in an Option so you can take it out.

Ok thanks! Think I got it (until next time borrow checker shows up :)

Copy link
Owner

@orottier orottier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the hard work. I will pick up the stuff I have mentioned.

})
});

// renderer has been sent to render thread, we can sent it messages
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// renderer has been sent to render thread, we can sent it messages
// renderer has been sent to render thread, we can send it messages

@@ -359,6 +345,17 @@ impl ConvolverRendererInner {
}
}

// dummy convolver used to init renderer
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I could better rewrite this like the HRTF-renderer. I'm not too sure what Fft::new(0), does behind the scenes. Also, it will make it more succinct and clear.

Stay tuned for updates

@@ -414,6 +411,11 @@ impl ConvolverRendererInner {
}
}

struct ConvolverRenderer {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As said, I will rewrite this.
A pattern of is_set and a tombstone value is way better represented as simply Option<ConvolverRendererInner>

Copy link
Collaborator Author

@b-ma b-ma Jul 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure this is a bit redondant

/// distortion curve
curve: Vec<f32>,
/// whether the distortion curve has been set
curve_set: bool,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar, I will rewrite this to simply curve: Option<Vec<f32>>

@@ -135,9 +128,7 @@ pub struct WaveShaperNode {
/// distortion curve
curve: OnceCell<Vec<f32>>,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I missed this node in #347 . I will need to rewrite this one to use a OnceLock instead

@orottier orottier force-pushed the refactor/message-passing branch from 483a22c to 13cda2c Compare July 24, 2023 19:34
@orottier
Copy link
Owner

/bench

@orottier orottier marked this pull request as draft July 24, 2023 19:35
@orottier
Copy link
Owner

Ready to merge but I want to publish a release before merging as we still have some bugfixes lined up.
Merging this will force us to address #344 to fix the logic bugs from the atomics

@github-actions
Copy link

Benchmark result:


bench_ctor
  Instructions:             4525410 (-1.308950%)
  L1 Accesses:              6722228 (-1.754016%)
  L2 Accesses:                54313 (+0.012890%)
  RAM Accesses:               61555 (+0.021124%)
  Estimated Cycles:         9148218 (-1.289678%)

bench_sine
  Instructions:            70988666 (-0.159642%)
  L1 Accesses:            103561106 (-0.177325%)
  L2 Accesses:               261179 (-0.916933%)
  RAM Accesses:               62423 (-0.182292%)
  Estimated Cycles:       107051806 (-0.186515%)

bench_sine_gain
  Instructions:            75902391 (-0.384479%)
  L1 Accesses:            110928371 (-0.448659%)
  L2 Accesses:               278610 (+1.632778%)
  RAM Accesses:               62527 (+0.017595%)
  Estimated Cycles:       114509866 (-0.414975%)

bench_sine_gain_delay
  Instructions:           150748566 (-0.258071%)
  L1 Accesses:            213321276 (-0.313888%)
  L2 Accesses:               557720 (+4.565311%)
  RAM Accesses:               64175 (+0.020261%)
  Estimated Cycles:       218356001 (-0.251019%)

bench_buffer_src
  Instructions:            17751855 (-0.743735%)
  L1 Accesses:             25542998 (-0.909105%)
  L2 Accesses:                86855 (-2.304733%)
  RAM Accesses:              100719 (+0.007944%)
  Estimated Cycles:        29502438 (-0.821293%)

bench_buffer_src_delay
  Instructions:            91325956 (-0.238735%)
  L1 Accesses:            126259309 (-0.259935%)
  L2 Accesses:               163412 (+0.060620%)
  RAM Accesses:              100913 (+0.013875%)
  Estimated Cycles:       130608324 (-0.250551%)

bench_buffer_src_iir
  Instructions:            41798280 (-0.568978%)
  L1 Accesses:             60559810 (-0.674354%)
  L2 Accesses:                87508 (+0.491502%)
  RAM Accesses:              100820 (+0.004960%)
  Estimated Cycles:        64526050 (-0.629623%)

bench_buffer_src_biquad
  Instructions:            37997279 (-1.323566%)
  L1 Accesses:             53218794 (-1.653817%)
  L2 Accesses:               136919 (+3.773685%)
  RAM Accesses:              100951 (+0.006935%)
  Estimated Cycles:        57436674 (-1.491776%)

bench_stereo_positional
  Instructions:            45023336 (-2.320743%)
  L1 Accesses:             66775237 (-2.693669%)
  L2 Accesses:               244593 (-7.271404%)
  RAM Accesses:              101035 (-0.049463%)
  Estimated Cycles:        71534427 (-2.648518%)

bench_stereo_panning_automation
  Instructions:            32367298 (-0.230654%)
  L1 Accesses:             48100703 (-0.280920%)
  L2 Accesses:               136328 (+0.529459%)
  RAM Accesses:              100830 (+0.009919%)
  Estimated Cycles:        52311393 (-0.250873%)

bench_analyser_node
  Instructions:            39553046 (+0.122918%)
  L1 Accesses:             55381910 (+0.174286%)
  L2 Accesses:               179841 (+0.356021%)
  RAM Accesses:              101376 (-0.000986%)
  Estimated Cycles:        59829275 (+0.166600%)


@orottier orottier marked this pull request as ready for review July 27, 2023 18:54
@orottier orottier merged commit 98bf467 into orottier:main Jul 27, 2023
@b-ma b-ma deleted the refactor/message-passing branch November 4, 2023 06:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants