Веб-аудио Api Realtime streaming PCM ADPCM

Question

У меня есть сервер, который передает данные PCM клиента или ADPCM.

Первоначально я решил использовать PCM, потому что я не хотел иметь дело с кодированием и декодированием.

я получил PCM работать, однако между каждым куском аудио я слышал глюков. (Вроде как отсечение)

Так что я подумал, может быть, причина задержки/высокое качество звука и все прочее.

Поэтому я решил использовать ADPCM для уменьшения объема данных. Я написал adpcm для pcm-декодера в javascript. Это был хлопот. Я надеялся, что, поскольку количество данных уменьшилось, возможно, это остановит глюки (данные будут догонять то, что воспроизводится)

Но я был неправ. У меня все еще есть глюки.

Можно ли это сделать с помощью TCP? Или это потерянное дело. У меня нет UDP через websockets.

Нужно ли мне реализовать алгоритм буферизации? Я не хочу делать это, поскольку это аудио в реальном времени, и я просто хочу обрабатывать его как можно быстрее.

Вы, ребята, знаете хорошую ссылку, чтобы читать о аудио в реальном времени через Интернет.

Я могу привести пример кода, но это вопрос высокого уровня.

PS: Я пытался использовать вкладки, но мы получаем проблему с буферизацией, и мы не можем ее контролировать. Я также не получаю никакого контроля потока с сервера. Он не говорит, что звуковой стартер или аудио остановили нашу паузу. Это протокол push, и все, что я получаю, это данные ADPCM и PCM.

Answer 1

Да, конечно, вы можете использовать TCP. UDP часто используется в приложениях телефонии, поскольку более низкие накладные расходы делают все быстрее, и для этого приложения не имеет значения, упали ли пакеты или пришли в неправильном порядке. Но поскольку UDP не является вариантом, вы можете использовать TCP.

Как вы подозревали, мне кажется, что ваша проблема заключается в недостаточности буфера. Либо ваше соединение с сервером не достаточно быстро (или, по крайней мере, достаточно быстро), либо вы не предоставляете данные из кодировщика с достаточно высокой скоростью. Это может произойти, если вы записываете данные в реальном времени и пытаетесь воспроизвести их в реальном времени.

Решение направлено на отправку данных на серверную серверу перед отправкой его клиенту. Имейте такой большой буфер, как позволяют ваши требования к задержке. Для целей интернет-радио я обычно выбираю 30-секундный буфер, так как латентность не имеет значения. Для ваших целей вам, вероятно, понадобится буфер не менее 64 КБ. Это максимальный размер, разрешенный в TCP-пакете. Этот пакет будет фрагментироваться, но это нормально.

Вы также можете посмотреть, как ваш сервер отправляет данные. Поэкспериментируйте с отключением алгоритма Nagle, чтобы ваш сервер не ожидал ACK перед отправкой большего количества данных.