limit-buffersize

[yara-blue]

fixes #853

huge cpal default buffer sizes (due to weirdly set up systems) are a footgun.

This makes from_device replace BufferSize::Default with a fixed 4096 samples. This affects from_default_device & open_default_sink.

[roderickvd]

I suggest to use the sample rate and channel count to calculate an audio latency of ~100 ms. Almost everywhere there's a double-buffering scheme, so that means that one buffer should represent ~50 ms.

For bonus points the buffer sizes are rounded to a safe and performant power of two.

[yara-blue]

I suggest to use the sample rate to calculate an audio latency of ~100 ms. Almost everywhere there's a double-buffering scheme, so that means that one buffer should represent ~50 ms.

For bonus points the buffer sizes are rounded to a safe and performant power of two.

yes that makes way more sense :) I'll do that and merge. Shall we put out a new patch release after that?

[roderickvd]

Yeah.

Edit: sample rate and channel count

[yara-blue]

overhauled the experimental new device opening API (working title: speakers), it now does this nicely. The change to the stable API is just 17 lines.

[yara-blue]

opportunity for a really nice refactor appeared. I'm looking into that

[yara-blue]

Merging this so I can easily see what it does to #853 feel free to discuss/review further here if you want too

[roderickvd]

We probably should document that Rodio configures a default buffer with a latency near 100 ms:

• regardless of system defaults
• unless a buffer size is specified manually

Before cpal changed this behavior, users found it surprising that their system settings were ignored.

[yara-blue]

We probably should document that Rodio configures a default buffer with a latency near 100 ms:

* regardless of system defaults

* unless a buffer size is specified manually

Before cpal changed this behavior, users found it surprising that their system settings were ignored.

done in 1cd15f8