Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upSupport for BaseAudioContext.currentTime and state changes #32
Conversation
|
r? @Manishearth |
| use std::thread::Builder; | ||
|
|
||
| static NEXT_NODE_ID: AtomicUsize = ATOMIC_USIZE_INIT; | ||
|
|
||
| pub struct AudioGraph { | ||
| sender: Sender<AudioRenderThreadMsg>, | ||
| sample_rate: f32, | ||
| current_time: Arc<RwLock<f64>>, |
This comment has been minimized.
This comment has been minimized.
Manishearth
May 29, 2018
Member
does the AudioGraph need this? I'd rather have this be owned by the actual render thread without an RWLock
This comment has been minimized.
This comment has been minimized.
Manishearth
May 29, 2018
Member
overall we should clean up the mutability story here but I have a plan for that
This comment has been minimized.
This comment has been minimized.
ferjm
May 29, 2018
•
Author
Member
The WebAudio API exposes sync getters for these values, so I figured that we should make the control thread own them. I guess we can have a sync channel with buffer size 0 for these getters (?).
| @@ -117,7 +121,12 @@ impl AudioRenderThread { | |||
| } | |||
| // and push into the audio sink the result of processing a | |||
| // render quantum. | |||
| let _ = self.sink.push_data(self.process()); | |||
| if let Ok(duration) = self.sink.push_data(self.process()) { | |||
This comment has been minimized.
This comment has been minimized.
Manishearth
May 29, 2018
Member
we shouldn't need to ask the sink for the duration; we know how long it is. The sink calculates the duration from information on the buffer that we provided.
|
Perhaps yeah.
…On Tue, May 29, 2018, 12:15 PM Fernando Jiménez Moreno < ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/audio/graph.rs
<#32 (comment)>:
> use std:
|
ferjm
changed the title
|
I don't think we need a sync sender here, we can use the same one -- just block on the receiver end. |
ferjm commentedMay 28, 2018
•
edited
Fixes #22 and #23