Сжатие / распаковка аудиоданных

Я бы подумал, что вам нужно будет дозировать эти 150-байтовые куски, чтобы улучшить сжатие.
Хотя даже при небольших размерах буфера вы все равно можете получить некоторое сжатие.

Если встроенный GZipStream не работает, вы можете попробовать GZipStream, который включен в DotNetZip. Существует также класс ZlibCodec, доступный в DotNetZip, который реализует шаблон Codec - это может облегчить сжатие в 150-байтных блоках.

150 байт - невероятно маленький буфер для аудиоданных - менее 5 миллисекунд, например. 16 кГц моно. Я не эксперт, но я думаю, что независимо от выбранной вами схемы сжатия коэффициент сжатия будет сильно зависеть от использования такого небольшого буфера. Кроме того, для каждого отправляемого пакета имеются значительные накладные расходы.

Тем не менее, если вы отправляете речевые данные, посмотрите Speex для сжатия с потерями (я нашел его очень эффективным при сжатии речи, но качество звука ужасно для музыки.)

Как было сказано выше, я бы посмотрел на Speex. Он хорошо поддерживается, и теперь стандарт defacto для Flash Player.

Я предполагаю, что по размеру вы устанавливаете свои буферы, что латентность является проблемой (чем больше буфер, тем больше латентность), поэтому не следует использовать кодек с высоким размером распакованного кадра, поскольку он вводит высокая латентность. Это более или менее исключает MP3... для голоса с частотой дискретизации 5 кГц (это не принесет большой пользы), минимальный размер распакованного кадра составляет 576 выборок или ~ 100 мс данных, которые должны быть закодированы до отправки, Это означает, что время ожидания более 200 мс до того, как вы даже рассмотрели сетевую часть проблемы.

Компонент, который вы ищете, более известен как кодер/декодер или codec, и есть много варианты, когда дело доходит до выбора.