В целом согласен с вами. Кстати, уже есть достаточное количество аналогов с такой же фишкой со звуком, что и у нас. Можно почитать эту ветку комментариев.
Согласен, на сервер действительно выйдет много нагрузки при наличии множества комнат.
Давайте сравним оба подхода. Пусть у нас есть k комнат в каждой из которых по n участников. Когда микшер на сервере, то получаем передачу по сети O(kn) сообщений и микширование O(kn^2) сообщений на сервере.
Когда микшер на каждом из клиентов, то получаем передачу по сети O(k * n^2) сообщений и микширование O(n) сообщений на каждом из (n * k) микшеров, установленных на клиентах.
Получаем, что в первом случае нужно наращивать ресурсы сервера в (n * k) раз, а во втором масштабировать канал передачи данных в n раз. Действительно, при большом количестве комнат второй способ явно привлекательнее.
Отмечу еще, что в первом способе можно сделать систему из нескольких серверов, которая будет перекидывать участников между серверами, если нагрузка на каком-то сервере превысила определенный предел.
Также, про митап с 1000+ участников согласен. При масштабировании определенно стоит добавить зону слышимости. Она действительно должна ограничить количество сообщений, передающихся по сети.
Смотрите, перемещение аватаров пользователей в нашем проекте уже синхронизировано между всеми клиентами. Поэтому не будет такой ситуации, что один пользователь слышит другого, а второй — нет. Возможно, стоило написать это в тексте статьи более явно.
У нас нет как таковых "зон" слышимости конкретного пользователя. Сервер передает микшеру вообще все аудиосообщения. Но если расстояния между пользователями достаточно большое, то они перестают слышать друг друга.
Сейчас объясню почему мы микшируем именно на сервере. Пусть подключено n клиентов. Микшеру нужно для каждого клиента выдать свою уникальную аудиодорожку.
Если микширование исполняется на сервере, то передач аудиосообщений по сети происходит всего O(n) штук. Каждый клиент передал одно свое аудисообщение и после микширования на сервере получил одну готовую аудиодорожку с голосами всех других пользователей. Стоит отметить, что сам микшер все же выполняет O(n^2) действий.
Если же микширование сделать на каждом из клиентов, то передач аудиосообщений по сети потребуется O(n^2) штук: каждому из n микшеров на клиентах нужно знать все (n - 1) аудисообщения от других пользователей. При этом суммарно все микшеры выполнят те же O(n^2) действий.
Получаем, что микшировать на сервере эффективнее с точки зрения количества аудиосообщений, передающихся по сети.
Не могли бы вы дополнительно пояснить почему микширование на сервере может стать узким местом при масштабировании?
Честно говоря мы не знали о таком приложении для позиционировании звука. Выглядит весьма интересно) Вообще есть множество приложений с похожей идеей динамического звука. Аналоги я привел в комментарии выше.
Решение взять готовые библиотеки и применить их несомненно хорошо. Но мы с ребятами были поставлены в жесткие рамки успеть написать готовое приложение до защит проектов. Поэтому было принято решение реализовать базовый функционал каким-нибудь не особо сложным способом, чтобы не закопаться в изучении/применении готовых библиотек и точно успеть.
Да, вы правы, в Spatial chat используется та же идея с динамическим звуком, что и в нашем проекте и еще много классных фич. К сожалению, мы не знали об этом приложении на старте.
Насколько я понимаю добавление фазового сдвига соответствует идее регулирования громкости звука всех пользователей у каждого участника независимо (будь то в реальном времени или уже в записи).
Это интересный подход, но я не думаю, что он пересекается с нашим: в проекте все перемещения кружков (а соответственно и громкости между каждой парой участников) синхронизированы между пользователями, чтобы было понятно какие конкретно пользователи образуют компании.
Как я вижу интегрирование вашей идеи: помимо основного интерфейса можно сделать дополнительный, в котором только сам пользователь может регулировать громкость всех участников конкретно для себя, например уже передвигая любые кружки. В принципе, это возможное развитие приложения. Спасибо за идею)
Спасибо за ответ! Стало гораздо понятнее про фазовый сдвиг: идея действительно классная)
В целом согласен с вами. Кстати, уже есть достаточное количество аналогов с такой же фишкой со звуком, что и у нас. Можно почитать эту ветку комментариев.
Спасибо вам за фидбек!
Согласен, на сервер действительно выйдет много нагрузки при наличии множества комнат.
Давайте сравним оба подхода. Пусть у нас есть k комнат в каждой из которых по n участников. Когда микшер на сервере, то получаем передачу по сети O(kn) сообщений и микширование O(kn^2) сообщений на сервере.
Когда микшер на каждом из клиентов, то получаем передачу по сети O(k * n^2) сообщений и микширование O(n) сообщений на каждом из (n * k) микшеров, установленных на клиентах.
Получаем, что в первом случае нужно наращивать ресурсы сервера в (n * k) раз, а во втором масштабировать канал передачи данных в n раз. Действительно, при большом количестве комнат второй способ явно привлекательнее.
Отмечу еще, что в первом способе можно сделать систему из нескольких серверов, которая будет перекидывать участников между серверами, если нагрузка на каком-то сервере превысила определенный предел.
Также, про митап с 1000+ участников согласен. При масштабировании определенно стоит добавить зону слышимости. Она действительно должна ограничить количество сообщений, передающихся по сети.
Смотрите, перемещение аватаров пользователей в нашем проекте уже синхронизировано между всеми клиентами. Поэтому не будет такой ситуации, что один пользователь слышит другого, а второй — нет. Возможно, стоило написать это в тексте статьи более явно.
У нас нет как таковых "зон" слышимости конкретного пользователя. Сервер передает микшеру вообще все аудиосообщения. Но если расстояния между пользователями достаточно большое, то они перестают слышать друг друга.
Сейчас объясню почему мы микшируем именно на сервере. Пусть подключено n клиентов. Микшеру нужно для каждого клиента выдать свою уникальную аудиодорожку.
Если микширование исполняется на сервере, то передач аудиосообщений по сети происходит всего O(n) штук. Каждый клиент передал одно свое аудисообщение и после микширования на сервере получил одну готовую аудиодорожку с голосами всех других пользователей. Стоит отметить, что сам микшер все же выполняет O(n^2) действий.
Если же микширование сделать на каждом из клиентов, то передач аудиосообщений по сети потребуется O(n^2) штук: каждому из n микшеров на клиентах нужно знать все (n - 1) аудисообщения от других пользователей. При этом суммарно все микшеры выполнят те же O(n^2) действий.
Получаем, что микшировать на сервере эффективнее с точки зрения количества аудиосообщений, передающихся по сети.
Не могли бы вы дополнительно пояснить почему микширование на сервере может стать узким местом при масштабировании?
Описание интегрирования этой идеи в наш проект я дал выше в комментарии
Хм, а можете подробнее объяснить идею с фазовым сдвигом? Пока что неясно как это соответствует расположению участников в пространстве.
Честно говоря мы не знали о таком приложении для позиционировании звука. Выглядит весьма интересно) Вообще есть множество приложений с похожей идеей динамического звука. Аналоги я привел в комментарии выше.
Решение взять готовые библиотеки и применить их несомненно хорошо. Но мы с ребятами были поставлены в жесткие рамки успеть написать готовое приложение до защит проектов. Поэтому было принято решение реализовать базовый функционал каким-нибудь не особо сложным способом, чтобы не закопаться в изучении/применении готовых библиотек и точно успеть.
Да, вы правы, в Spatial chat используется та же идея с динамическим звуком, что и в нашем проекте и еще много классных фич. К сожалению, мы не знали об этом приложении на старте.
Кстати, есть еще аналоги нашего проекта, например: gatherly и kinspray graffiti
Насколько я понимаю добавление фазового сдвига соответствует идее регулирования громкости звука всех пользователей у каждого участника независимо (будь то в реальном времени или уже в записи).
Это интересный подход, но я не думаю, что он пересекается с нашим: в проекте все перемещения кружков (а соответственно и громкости между каждой парой участников) синхронизированы между пользователями, чтобы было понятно какие конкретно пользователи образуют компании.
Как я вижу интегрирование вашей идеи: помимо основного интерфейса можно сделать дополнительный, в котором только сам пользователь может регулировать громкость всех участников конкретно для себя, например уже передвигая любые кружки. В принципе, это возможное развитие приложения. Спасибо за идею)