What happened
Web Audio has always processed sound in fixed blocks of 128 sample frames, a unit the specification calls the render quantum. Chrome 153, stable since September 8, adds an optional renderSizeHint to AudioContext and OfflineAudioContext: a page can ask for a specific block size, keep the 128-frame default, or ask the browser to pick a size that suits the hardware.
On September 22 the W3C published a Web Audio 1.1 Working Draft, edited by Paul Adenot of Mozilla and Hongchan Choi of Google, that writes the same option into the standard. Browsers must accept block sizes from a single frame up to six times the sample rate; the draft also widens the required sample-rate range to 3,000–768,000 Hz and adds chunked offline rendering. Safari 27, detailed by WebKit on September 17, fixes a few Web Audio bugs but supports none of it.
The interesting bit
Hint is the load-bearing word. The page asks and the browser decides, so audio code now has to read the new renderQuantumSize attribute instead of assuming 128. Chrome's own feature entry says the “hardware” option has so far returned the default 128 anyway, because a device's real buffer size is one more signal that could help fingerprint a visitor.
It is a reasonable trade with an awkward result: the setting that would help most is the one privacy keeps switched off. Firefox and Safari have not signalled a position yet, although the change to the specification was written by a Firefox developer.