2017-07-01 14:57:59 +00:00
|
|
|
use std::io::BufReader;
|
|
|
|
use std::thread;
|
|
|
|
use std::time::Duration;
|
|
|
|
|
Force `queue` to play sources on frame boundaries (#455)
As I understand it, this is the issue:
* Previously, when a queue has `keep_alive_if_empty` set to true, and it becomes empty, then it will push a silence lasting 10ms onto the queue.
* This is an issue because `current_frame_len` would have returned the worst case, `512`, and the silence lasts less than that.
* This means that unless the source is added immediately to the queue, and so a silence is never played, then the first actual source could start playing at a frame that is not aligned to its channels, or play at the wrong sample rate.
* This is only determined by when the source is added to the queue after its initialization. This explains why the issue was inconsistent, as it relied on the speed of execution of code which is basically random.
Solution
* Change the functionality of `Zero` to add a method to create a silence with a certain number of frames.
* Replace the 10ms silence with a silence the length of `THRESHOLD`
* Change queue's `current_frame_len` to return `THRESHOLD` if a silence will be played next.
2022-11-23 00:36:57 +00:00
|
|
|
use rodio::Source;
|
|
|
|
|
2017-07-01 14:57:59 +00:00
|
|
|
fn main() {
|
Force `queue` to play sources on frame boundaries (#455)
As I understand it, this is the issue:
* Previously, when a queue has `keep_alive_if_empty` set to true, and it becomes empty, then it will push a silence lasting 10ms onto the queue.
* This is an issue because `current_frame_len` would have returned the worst case, `512`, and the silence lasts less than that.
* This means that unless the source is added immediately to the queue, and so a silence is never played, then the first actual source could start playing at a frame that is not aligned to its channels, or play at the wrong sample rate.
* This is only determined by when the source is added to the queue after its initialization. This explains why the issue was inconsistent, as it relied on the speed of execution of code which is basically random.
Solution
* Change the functionality of `Zero` to add a method to create a silence with a certain number of frames.
* Replace the 10ms silence with a silence the length of `THRESHOLD`
* Change queue's `current_frame_len` to return `THRESHOLD` if a silence will be played next.
2022-11-23 00:36:57 +00:00
|
|
|
let iter_duration = Duration::from_secs(5);
|
|
|
|
let iter_distance = 5.;
|
|
|
|
|
|
|
|
let refresh_duration = Duration::from_millis(10);
|
|
|
|
|
|
|
|
let num_steps = iter_duration.as_secs_f32() / refresh_duration.as_secs_f32();
|
|
|
|
let step_distance = iter_distance / num_steps;
|
|
|
|
let num_steps = num_steps as u32;
|
|
|
|
|
|
|
|
let repeats = 5;
|
|
|
|
|
|
|
|
let total_duration = iter_duration * 2 * repeats;
|
|
|
|
|
2024-09-23 21:01:10 +00:00
|
|
|
let (_stream, handle) = rodio::OutputStream::default().unwrap();
|
Force `queue` to play sources on frame boundaries (#455)
As I understand it, this is the issue:
* Previously, when a queue has `keep_alive_if_empty` set to true, and it becomes empty, then it will push a silence lasting 10ms onto the queue.
* This is an issue because `current_frame_len` would have returned the worst case, `512`, and the silence lasts less than that.
* This means that unless the source is added immediately to the queue, and so a silence is never played, then the first actual source could start playing at a frame that is not aligned to its channels, or play at the wrong sample rate.
* This is only determined by when the source is added to the queue after its initialization. This explains why the issue was inconsistent, as it relied on the speed of execution of code which is basically random.
Solution
* Change the functionality of `Zero` to add a method to create a silence with a certain number of frames.
* Replace the 10ms silence with a silence the length of `THRESHOLD`
* Change queue's `current_frame_len` to return `THRESHOLD` if a silence will be played next.
2022-11-23 00:36:57 +00:00
|
|
|
let mut positions = ([0., 0., 0.], [-1., 0., 0.], [1., 0., 0.]);
|
|
|
|
let sink = rodio::SpatialSink::try_new(&handle, positions.0, positions.1, positions.2).unwrap();
|
2017-07-01 14:57:59 +00:00
|
|
|
|
2022-03-26 19:15:18 +00:00
|
|
|
let file = std::fs::File::open("assets/music.ogg").unwrap();
|
Force `queue` to play sources on frame boundaries (#455)
As I understand it, this is the issue:
* Previously, when a queue has `keep_alive_if_empty` set to true, and it becomes empty, then it will push a silence lasting 10ms onto the queue.
* This is an issue because `current_frame_len` would have returned the worst case, `512`, and the silence lasts less than that.
* This means that unless the source is added immediately to the queue, and so a silence is never played, then the first actual source could start playing at a frame that is not aligned to its channels, or play at the wrong sample rate.
* This is only determined by when the source is added to the queue after its initialization. This explains why the issue was inconsistent, as it relied on the speed of execution of code which is basically random.
Solution
* Change the functionality of `Zero` to add a method to create a silence with a certain number of frames.
* Replace the 10ms silence with a silence the length of `THRESHOLD`
* Change queue's `current_frame_len` to return `THRESHOLD` if a silence will be played next.
2022-11-23 00:36:57 +00:00
|
|
|
let source = rodio::Decoder::new(BufReader::new(file))
|
|
|
|
.unwrap()
|
|
|
|
.repeat_infinite()
|
|
|
|
.take_duration(total_duration);
|
2017-07-01 14:57:59 +00:00
|
|
|
sink.append(source);
|
Force `queue` to play sources on frame boundaries (#455)
As I understand it, this is the issue:
* Previously, when a queue has `keep_alive_if_empty` set to true, and it becomes empty, then it will push a silence lasting 10ms onto the queue.
* This is an issue because `current_frame_len` would have returned the worst case, `512`, and the silence lasts less than that.
* This means that unless the source is added immediately to the queue, and so a silence is never played, then the first actual source could start playing at a frame that is not aligned to its channels, or play at the wrong sample rate.
* This is only determined by when the source is added to the queue after its initialization. This explains why the issue was inconsistent, as it relied on the speed of execution of code which is basically random.
Solution
* Change the functionality of `Zero` to add a method to create a silence with a certain number of frames.
* Replace the 10ms silence with a silence the length of `THRESHOLD`
* Change queue's `current_frame_len` to return `THRESHOLD` if a silence will be played next.
2022-11-23 00:36:57 +00:00
|
|
|
// A sound emitter playing the music starting at the centre gradually moves to the right
|
2017-07-03 08:09:10 +00:00
|
|
|
// until it stops and begins traveling to the left, it will eventually pass through the
|
Force `queue` to play sources on frame boundaries (#455)
As I understand it, this is the issue:
* Previously, when a queue has `keep_alive_if_empty` set to true, and it becomes empty, then it will push a silence lasting 10ms onto the queue.
* This is an issue because `current_frame_len` would have returned the worst case, `512`, and the silence lasts less than that.
* This means that unless the source is added immediately to the queue, and so a silence is never played, then the first actual source could start playing at a frame that is not aligned to its channels, or play at the wrong sample rate.
* This is only determined by when the source is added to the queue after its initialization. This explains why the issue was inconsistent, as it relied on the speed of execution of code which is basically random.
Solution
* Change the functionality of `Zero` to add a method to create a silence with a certain number of frames.
* Replace the 10ms silence with a silence the length of `THRESHOLD`
* Change queue's `current_frame_len` to return `THRESHOLD` if a silence will be played next.
2022-11-23 00:36:57 +00:00
|
|
|
// listener again and go to the far left.
|
2017-07-01 14:57:59 +00:00
|
|
|
// This is repeated 5 times.
|
Force `queue` to play sources on frame boundaries (#455)
As I understand it, this is the issue:
* Previously, when a queue has `keep_alive_if_empty` set to true, and it becomes empty, then it will push a silence lasting 10ms onto the queue.
* This is an issue because `current_frame_len` would have returned the worst case, `512`, and the silence lasts less than that.
* This means that unless the source is added immediately to the queue, and so a silence is never played, then the first actual source could start playing at a frame that is not aligned to its channels, or play at the wrong sample rate.
* This is only determined by when the source is added to the queue after its initialization. This explains why the issue was inconsistent, as it relied on the speed of execution of code which is basically random.
Solution
* Change the functionality of `Zero` to add a method to create a silence with a certain number of frames.
* Replace the 10ms silence with a silence the length of `THRESHOLD`
* Change queue's `current_frame_len` to return `THRESHOLD` if a silence will be played next.
2022-11-23 00:36:57 +00:00
|
|
|
for _ in 0..repeats {
|
|
|
|
for _ in 0..num_steps {
|
|
|
|
thread::sleep(refresh_duration);
|
|
|
|
positions.0[0] += step_distance;
|
|
|
|
sink.set_emitter_position(positions.0);
|
|
|
|
}
|
|
|
|
for _ in 0..(num_steps * 2) {
|
|
|
|
thread::sleep(refresh_duration);
|
|
|
|
positions.0[0] -= step_distance;
|
|
|
|
sink.set_emitter_position(positions.0);
|
2017-07-01 14:57:59 +00:00
|
|
|
}
|
Force `queue` to play sources on frame boundaries (#455)
As I understand it, this is the issue:
* Previously, when a queue has `keep_alive_if_empty` set to true, and it becomes empty, then it will push a silence lasting 10ms onto the queue.
* This is an issue because `current_frame_len` would have returned the worst case, `512`, and the silence lasts less than that.
* This means that unless the source is added immediately to the queue, and so a silence is never played, then the first actual source could start playing at a frame that is not aligned to its channels, or play at the wrong sample rate.
* This is only determined by when the source is added to the queue after its initialization. This explains why the issue was inconsistent, as it relied on the speed of execution of code which is basically random.
Solution
* Change the functionality of `Zero` to add a method to create a silence with a certain number of frames.
* Replace the 10ms silence with a silence the length of `THRESHOLD`
* Change queue's `current_frame_len` to return `THRESHOLD` if a silence will be played next.
2022-11-23 00:36:57 +00:00
|
|
|
for _ in 0..num_steps {
|
|
|
|
thread::sleep(refresh_duration);
|
|
|
|
positions.0[0] += step_distance;
|
|
|
|
sink.set_emitter_position(positions.0);
|
2017-07-01 14:57:59 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
sink.sleep_until_end();
|
|
|
|
}
|