Имеешь в виду, чтобы можно было менять в процессе работы? Есть некоторые сложности с сохранностью данных при этом. То-есть, во время изменения размера могут быть артефакты воспроизведения. Я вообще не специалист по звуку, но мне показалось, что размер буфера в общем не является важным показателем. Так как это никак не влияет на синхронизацию скорости генерации/воспроизведения. Он просто помогает накапливать данные при колебаниях скорости (при сохранении средней скорости). От его размера при неодинаковых скоростях будет зависеть только насколько быстро он опустеет или переполнится.

Тут такая штука получилась: в выложенном коде я забыл включить критическую секцию. К ошибкам это похоже не приводит (так как нет выделения/уничтожения памяти в процессе работы), но чисто логически это некорректно и может приводить к артефактам звука (или к редким другим ошибкам).
Net2Com, в hiSoundBuffer.pas строку 4 приведи к виду {$define THREAD_SAFE}.
В строке 229:
Потестируй, не будет ли падения производительности.

У меня есть портативная сборка среды с включенными моими компонентами для личного пользования. Но в общем, то, что стоит внимания, я выкладываю на форуме.
Это раздел "Компоненты" и тема "Компоненты"->"Моды стандартных компонентов". Плюс ещё несколько компонентов правились в разных темах, как в этой.

Раздел "Компоненты"->Альтернативные компоненты сервера и клиента TCP

Пусть Net2Com отпишется о результатах с THREAD_SAFE и тогда я выложу финальную версию.