Аудио разговор в реальном времени iOS

Question

Я разрабатываю приложение для iOS для клиента, который хочет разрешать разговоры между пользователями в режиме реального времени (с минимальной задержкой, максимум 50 мс) (своего рода Teamspeak). Задержка должна быть низкой, потому что аудио также может быть живой музыкой, которую играют на инструментах, поэтому все пользователи должны синхронизироваться. Мне нужен сервер, который будет запрашивать аудиозаписи каждому клиенту и отправлять другим (и заставлять их слышать один и тот же звук в одно и то же время). HTTP прост в управлении / реализации и легко масштабируется, но очень низкоэффективен, потому что средний HTTP-запрос занимает> 50 мс... (с оборудованием среднего уровня), поэтому я думал о TCP/UDP-соединениях, открытых между клиентами и сервер. Но у меня есть несколько вопросов:

• Если я разрабатываю сервер на Python (например, используя TwistedMatrix), как его производительность?
• Я не могу разработать сервер на C++, потому что им трудно управлять (масштабировать) и разрабатывать.
• Кто-нибудь использовал Nodejs (который легко масштабируется) для управления соединениями TCP/UDP?
• Если я буду использовать HTTP, будет ли это достаточно быстро с Keep-Alive? Так как обычно время, необходимое для выполнения HTTP-запроса, составляет> 50 мс (так как открывать-закрывать соединение сложно), и я хочу, чтобы общая процедура была меньше, чем это время.
• Сервер будет работать на компьютере с Linux.

И наконец: какой тип сжатия вы можете мне предложить? Я думал, что Ogg Vorbis был бы хорош, но если есть что-то лучше (и может быть использовано в iOS), я открыт для изменений.

Спасибо, Умар.

Answer 1

Во-первых, вы не собираетесь получать задержку менее 50 мс. Другие попробовали это. Посмотрите, например, http://ejamming.com/ сервис, который пытается делать то, что вы делаете, но имеет заметную музыкальную задержку по линии и поэтому, на слух многих, совершенно непригоден для использования. Они используют специальные методы маршрутизации, чтобы максимально снизить задержку, и, как я слышал, их служба не работает с некоторыми конфигурациями маршрутизатора.

Во-вторых, какой язык вы используете на сервере, вероятно, не имеет большого значения, так как задержка от клиента к серверу будет хуже, чем любая задержка, вызванная вашим сервисом, но если я правильно понимаю ваш сервис, вам понадобится много серверы (или серверные потоки) просто передают аудиоданные между клиентами или выполняют какое-то минимальное микширование. Это небольшое количество работы для каждого соединения, но много соединений, поэтому вам нужно что-то, что может с этим справиться. Я бы склонялся к чему-то вроде Java, Scala или, возможно, Go. Я могу ошибаться, но я не думаю, что это хороший вариант использования для узла, который, насколько я понимаю, в настоящее время не справляется с многопоточностью. Кроме того, не какайте C++, масштабируемые сервисы были созданы C++. Вы также можете создать ретрансляционную часть сервиса в C++, а остальное - во что угодно.

В-третьих, при выборе формата сжатия вы должны будете выбрать тот, который сможет пережить потерю пакетов, если вы планируете использовать UDP, и я думаю, что UDP - единственный способ сделать это. Я не думаю, что Ворбис справляется с этой задачей, но я могу ошибаться. Вдобавок ко всему, я не уверен ни в чем, что работает на iPhone и подходит для UDP, но я уверен, что есть много вещей. Speex является примером и с открытым исходным кодом. Не уверен, что время ожидания и качество соответствуют вашим потребностям.

Наконец, чтобы быть грубым, я думаю, что есть некоторые другие вещи, которые вы должны исследовать немного больше. например. DNS обычно кэшируется локально и не проверяется при каждом вызове http (хотя это может зависеть от системы / библиотеки. По крайней мере, большинство систем кэширует DNS локально). Также нет такого протокола как TCP/UDP. Есть TCP/IP (иногда просто называемый TCP) и UDP/IP (иногда просто называемый UDP). Вы, кажется, относитесь к двум, как будто они одно. Разница очень важна для того, что вы делаете. Например, HTTP работает поверх TCP, а не UDP, а UDP считается "ненадежным", но имеет меньше накладных расходов, поэтому он хорош для потоковой передачи.

Редактировать: speex

Answer 2

Что касается сервера, то сам запрос не является узким местом. Я думаю, у вас есть достаточно времени, чтобы установить соединение, как это происходит только в начале сеанса. Поэтому протокол не имеет большого значения.

Но учтите, что HTTP является протоколом без сохранения состояния и не подходит для потоковой передачи звука. Есть несколько потоковых протоколов в реальном времени, которые вы можете выбрать. Все они будут работать через TCP или UDP (например, использовать необработанные сокеты), и существует множество реализаций.

В вашем случае узким местом с задержкой является не сервер, а сама сеть. Соединение между устройством iOS и точкой беспроводного доступа (AP) израсходует около 40 мсек, если точка доступа не настроена неправильно и соединение хорошее. (пингуйте свой iPhone.) В общей сложности у вас будет минимум 80 мс для пути iOS -> AP -> Сервер -> AP -> iOS. Но трудно удержать эту задержку стабильной. (Типичная задержка AirPlay в моей локальной сети составляет около 300 мс.)

Я думаю, что живая музыка на устройствах iOS сегодня неосуществима. Попробуйте скайп между двумя устройствами iOS и посмотрите, как близко вы можете добраться до 50 мс. Держу пари, что никто не может сделать это значительно лучше, что касается задержки.

Обновление: новый результат исследования!

Я должен пересмотреть свои требования, касающиеся задержки подключений Wi-Fi iDevice. Очевидно, когда вы впервые пингуете свое устройство, задержка будет плохой. Но если я снова пингуюсь не позднее, чем через 200 мс после этого, я вижу среднюю задержку 2 мс-3 мс между AP и iDevice.

Моя интерпретация заключается в том, что если между AP и iDevice нет связи более 200 мс, сетевой адаптер iDevice перейдет в менее адаптивный режим ожидания, возможно, для экономии заряда батареи.

Кажется, живая музыка снова в пределах досягаемости...:-)

Обновление 2

Интервал ping, необходимый для поддержания низкой задержки, очевидно, отличается от устройства к устройству. Сообщенные 200 мс для 3-го поколения. IPAD. Для моего iPhone 4 это больше похоже на 50 мс.

Во время потоковой передачи аудио вам, вероятно, не нужно беспокоиться об этом, поскольку обмен данными происходит чаще. В моем собственном контексте у меня есть редкая связь между iDevice и сервером, но низкая задержка крайне важна. Поэтому поддерживать жизнь - это путь.

Лучший, Питер