These changes were tested on two different amd64 machines, with several USB audio devices from consumer grade to professional multichannel audio interfaces. All tests happened on 13.2-RELEASE, it would be unreasonable to run CURRENT for my audio setups. That should be ok, according to git there were no significant changes regarding snd_uaudio.
**Buffer Length** changes to the `buffer_ms` sysctl will be effective when the pcm device is (re-)opened by an audio application. The driver side buffer size appears as a `[b:total_size/block_size/blocks|...]` triplet, e.g. `[b:1536/768/2|...]` in `/dev/sndstat`:
```
# sysctl hw.snd.verbose=2
# cat /dev/sndstat
```
In all tests the buffer size matched a double buffer of the specified `buffer_ms` length, as expected.
**Listening Tests** revealed no problems or regressions.
**Latency** was measured through JACK (audio/jack) and the `jack_iodelay` utility from jack-example-tools (audio/jack-example-tools). Some latency is introduced by the hardware, but the buffer-related parts come down to roughly:
| buffer_ms | playback buffer | playback transfer | recording transfer | total |
| 8 | 2 * 8ms | 8ms | 8ms | 32ms |
| 4 | 2 * 4ms | 4ms | 4ms | 16ms |
| 2 | 2 * 2ms | 2ms | 2ms | 8ms |
| 1 | 2 * 1ms | 1ms | 1ms | 4ms |
Prior to this change the default of 2ms for `buffer_ms` would result in 2 * 8ms playback buffer plus 2ms latency for both playback and recording USB transfers. This means that our new default of 4 reduces roundtrip latency to 16ms from previously 20ms.
**Power Consumption** from CPU wakeups was reduced by around 0.5W on my Thinkpad X230 with the new default of 4ms. Playback resulted in 8.2W (+0.9W) compared to previous 8.7W (+1.4W) on an otherwise idle machine. Measured through the battery info:
```
# acpiconf -i0 | grep rate
```