0.16.0

Fixed

• Choppy AirPlay playback (timusus/Shuttle2#1064). The feeder kept a fixed lead of about two seconds of audio. AirPlay receivers buffer more than the latency they report, so the renderer ran dry and audio was dropped silently, with no stall reported. The feeder now writes while the renderer is ready for more media data, woken by requestMediaDataWhenReady, and keeps at most 30 s of media written ahead. That cap is a time bound: about 11 MB at 48 kHz stereo Float32, and more at higher sample rates or channel counts.

Changed

• Start and rebuffer depth. Playback starts once 0.5 s (scaled by rate) is queued. After an underrun it waits for 2 s, or starts as soon as the output reports full.
• Effect changes flush. With up to 30 s queued ahead, draining the old chain would delay a change too long. setProcessors now flushes and re-feeds from the frame being heard, which shows as a brief buffering, as a seek does. This doesn't happen after .ended.
• New processorsChanged() on Transport and Player (public API). Call it after changing a live processor parameter, such as an EQ gain or a Voice Boost amount, so the change is heard at once. It does nothing while the transport is failed or ended.
• Playback rate is still applied by the synchronizer, so speed changes take effect at once with no flush.

Migrating from 0.15.0

• If your processors read parameters that change while playing, call player.processorsChanged() after each change. Without it, the change is heard only after the audio already queued (up to 30 s) has played.
• Code that relied on setProcessors never flushing will now see a short buffering state.