Rewrote iterator implementation to support non-synced duplex streams and simplify handling of custom update rates.

[mitchmindtree]

This should fix the issues some linux users were experiencing with buffer over/underrun errors.

The SoundStream will convert any non-synced stream formats into a synced stream. The stream will always occur in order of In -> Out -> Update with matching formats and the exact number of frames specified by the user.

@niclashoyer hopefully this should fix the issues you were running into with the synth crate, lemme know how it goes :)

[niclashoyer]

I just had a quick test and I'm still getting underruns, so that the process exits. I get different errors upon running synth:

It begins!
note_on
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
An error occurred while writing to the output stream: The output stream has underflowed
Great success!

It begins!
note_on
ALSA lib pcm.c:7843:(snd_pcm_recover) overrun occurred
Process didn't exit successfully: `target/debug/examples/test` (signal: 11)

It begins!
note_on
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:7843:(snd_pcm_recover) overrun occurred
ALSA lib pcm.c:7846:(snd_pcm_recover) cannot recovery from overrun, prepare failed: Input/output error
Process didn't exit successfully: `target/debug/examples/test` (signal: 11)

It begins!
note_on
Assertion 'pa_atomic_load(&(c)->_ref) >= 1' failed at pulse/context.c:1012, function pa_context_get_state(). Aborting.
Process didn't exit successfully: `target/debug/examples/test` (signal: 6)

Output from the simple example:

2.993711
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
An error occurred while writing to the output stream: The output stream has underflowed

The advanced example sometimes runs fine, but most runs just break in the middle with an underrun.

[mitchmindtree]

Ahhh damn, I really wanted to try and keep the event ordering deterministic, but it looks like this might just not be realistic across platforms. I thought that that the changes would be enough to handle the non-synced stream, but the streams must more unrelated than I thought. Just to clarify, you were testing my branch right? (the PR wasn't merged when you commented last).

It's a long shot, but you could try changing this line to

if output_buffer.len() <= stream_settings.buffer_size() * 2 {

Otherwise, perhaps I should just move SoundStream over to an exclusively non-blocking stream implementation, and drop the blocking implementation from SoundStream altogether? It seems to run more consistently and probably suits most use cases better anyway.

[niclashoyer]

Yes, I added your repo and pulled from there. Unfortunately even the change in event.rs did not help.