Comments 27
Постоянно о таком думал во время бесконечных созвонов. Жалко, что реально используемые средства (Zoom, Teams) не используют такой подход.
Вот только помимо громкости, стоило бы добавлять фазовый сдвиг, чтобы виртуально располагать собеседников в пространстве. Это, кажется, даже более важно для того, чтобы слышать всех разборчиво.
Раз такое дело, дополню. Подобие стереопанорамы можно получить, добавив зависимость сдвига фазы между воспроизведением на левом и правом каналах от угла источника звука относительно направления взгляда. Сдвиг там совсем небольшой, порядка единиц миллисекунд, это всё легко считается через скорость звука и расстояние до левого и правого уха.
Но кроме этого, для более правдоподобной картины стоит рассмотреть ещё параметрическую эквализацию, ведь если мы берём первое приближение головы идеальной сферой, то мощность звука на ухо зависит от частоты этого сигнала и угла относительно уха. Если низкие частоты с длиной волны сильно больше диаметра сферы будут регистрироваться почти вне зависимости от направления звука, то средне- и высокочастотные уже не способны огибать такие препятствия и будут значительная разница между каналами. Это более правильная регулировка, нежели просто уровнем сигнала. Частоту среза не скажу, но что-то порядка единицы кГц, плюс минус. Ну это если не брать АЧХ реального уха и его зависимость от этих углов. В реальном ухе ещё и нелинейности ярко выраженные есть, зависящие от направления на источник, но там уже совсем мрак. Имхо в чатах и "округления" будет достаточно более чем.
Насколько я понимаю добавление фазового сдвига соответствует идее регулирования громкости звука всех пользователей у каждого участника независимо (будь то в реальном времени или уже в записи).
Это интересный подход, но я не думаю, что он пересекается с нашим: в проекте все перемещения кружков (а соответственно и громкости между каждой парой участников) синхронизированы между пользователями, чтобы было понятно какие конкретно пользователи образуют компании.
Как я вижу интегрирование вашей идеи: помимо основного интерфейса можно сделать дополнительный, в котором только сам пользователь может регулировать громкость всех участников конкретно для себя, например уже передвигая любые кружки. В принципе, это возможное развитие приложения. Спасибо за идею)
Неправильно вы понимаете, добавление фазового сдвига как раз и соответствует идее расположения участников в пространстве. И неважно, индивидуально они регулируются или одинаково для всех.
Хм, а можете подробнее объяснить идею с фазовым сдвигом? Пока что неясно как это соответствует расположению участников в пространстве.
Наткнулся на старый вопрос...
Вот представьте, вы стоите в комнате, а сбоку вам что-то говорят. В таком случае звук сначала попадает в одно ухо, а только через 0,41-0,83 мс доходит до другого уха. Соответственно, если комната виртуальная, а вы в наушниках — то организовав подобную задержку между каналами можно добиться более качественной иллюзии что ваш собеседник стоит сбоку от вас.
А вот если ваш собеседник стоит в двух метрах спереди от вас и чуть-чуть сбоку — может потребоваться задержка уже на какие-нибудь 0,024 мс. Такая задержка при частоте дискретизации в 144 кГц составит 3,5 такта, и тут для большей плавности может потребоваться сдвинуть звук на нецелое число тактов во времени. Это и делается фазовым сдвигом.
И определяется величина сдвига, как видно, строго исходя из расположения виртуального собеседника.
Интересный проект, еще бы CI прикрутили там actions на коммиты было бы еще лучше. Что касается идея, то я думаю проблема многоголосия в чатах из-за того что звук если груба становиться двумерным - все говорят с разной громкостью но из одной точки 3х мерного пространства. Если говорить про переход между группами собеседников - то для этого и создают отдельные каналы в чатах.
Так умел( и умеет ) ещё TeamSpeak, причём там ещё делалась попытка имитировать направление на источник звука.
В целом, точности современного "3D" аудио сильно не хватает, и когда людей больше 3-4, то угадать направление становится очень сложно
Можно посмотреть на https://spatial.chat/ как на коммерческую реализацию вашей идеи в продукт.
А можно и на эту идею посмотреть как на открытую и бесплатную альтернативу spatial.chat :)
Да, вы правы, в Spatial chat используется та же идея с динамическим звуком, что и в нашем проекте и еще много классных фич. К сожалению, мы не знали об этом приложении на старте.
Кстати, есть еще аналоги нашего проекта, например: gatherly и kinspray graffiti
В целом годно, но есть проблемы с подачей материала - слишком сильно торчат уши дипломной/курсовой работы, с формальным вступлением/заключением...
И еще, перемещаться будет удобнее через WASD или стрелках. Так можно будет просто прогуляться по комнате.
Описание интегрирования этой идеи в наш проект я дал выше в комментарии
Использовать ZMQ конечно оригинально, и в целом не лишено смысла, но почему не рассматривали вариант взять готовую библиотеку для передачи мультимедиа, которая умеет в какой-нибудь современный Opus, автоматическую подстройку задержки и обработку проблем соединения? И использовать какой-нибудь стандартный для передачи потока аудио протокол :-).
Безотносительно этого вопроса, ребята и ментор - молодцы, нормальная работа.
Решение взять готовые библиотеки и применить их несомненно хорошо. Но мы с ребятами были поставлены в жесткие рамки успеть написать готовое приложение до защит проектов. Поэтому было принято решение реализовать базовый функционал каким-нибудь не особо сложным способом, чтобы не закопаться в изучении/применении готовых библиотек и точно успеть.
Честно говоря мы не знали о таком приложении для позиционировании звука. Выглядит весьма интересно) Вообще есть множество приложений с похожей идеей динамического звука. Аналоги я привел в комментарии выше.
Идея интересная.
Не понятно, почему решили микшировать на сервере? Есть предложение, что при масштабировании это станет очень узким местом.
Второй момент как согласуются маппинги пользователей? Т.е. тип А у себя настроил 100% слышимость типа В, а тот в свою очередь убрал А "в дальний угол". Пошла разобщённость и ноль диалога.
Имхо нужно виртуальное согласованное пространство с координатами каждого участников.
Сервер в этом случае должен определить какие звуковые потоки попали в "зону" слышимости конкретного пользователя и передать их на клиента.
Клиент уже смикшировать по установкам пользователя.
Да, клиент при этом станет более ресурсоемким, но в целом приложение стабильнее и функциональнее.
Смотрите, перемещение аватаров пользователей в нашем проекте уже синхронизировано между всеми клиентами. Поэтому не будет такой ситуации, что один пользователь слышит другого, а второй — нет. Возможно, стоило написать это в тексте статьи более явно.
У нас нет как таковых "зон" слышимости конкретного пользователя. Сервер передает микшеру вообще все аудиосообщения. Но если расстояния между пользователями достаточно большое, то они перестают слышать друг друга.
Сейчас объясню почему мы микшируем именно на сервере. Пусть подключено n клиентов. Микшеру нужно для каждого клиента выдать свою уникальную аудиодорожку.
Если микширование исполняется на сервере, то передач аудиосообщений по сети происходит всего O(n) штук. Каждый клиент передал одно свое аудисообщение и после микширования на сервере получил одну готовую аудиодорожку с голосами всех других пользователей. Стоит отметить, что сам микшер все же выполняет O(n^2) действий.
Если же микширование сделать на каждом из клиентов, то передач аудиосообщений по сети потребуется O(n^2) штук: каждому из n микшеров на клиентах нужно знать все (n - 1) аудисообщения от других пользователей. При этом суммарно все микшеры выполнят те же O(n^2) действий.
Получаем, что микшировать на сервере эффективнее с точки зрения количества аудиосообщений, передающихся по сети.
Не могли бы вы дополнительно пояснить почему микширование на сервере может стать узким местом при масштабировании?
На небольших объемах - Вы правы.
Но если вы собираетесь провести он-лайн конференцию/митап с 1000+ участников?
В любом случае вы будете либо делить участников на группы (что снижает "реализм" платформы), либо ограничивать "зону слышимости" участников.
В противном случае вам надо будет микшировать 1000^2 потоков в рантайме...
Второй момент: ваша платформа вырастает до 10м+ одновременных сессий. "Комнаты" - по 10 участников в среднем. Итого 1млн комнат, для каждой нужно "микшировать" 10*10 =100. Т.е. 100 млн "миксов" вам надо "готовить" на сервер сайде. Можете прикинуть мощности, которые вам потребуются для реализации? Сможете оставить платформу условно бесплатной (а-ля зум)?
Вы сыграли существенно в пользу снижения утилизации сетевого ресурса, но пожертвовали при этом ресурсами вычислительными. Тут надо оценить - что для вас "дороже" - масштабировать "канал" передачи данных практически линейно с ростом пользователей, или квадратично наращивать ресурсы сервера?
И позволю "замкнуть" обсуждение на первый тезис: "реалистичность". Представьте он-лайн митап, где участники свободно перемещаются по он-лайн пространству, в различных точках которого идут доклады / выступления / дискуссии и человек волен сам выбирать где ему "оказаться" в каждый момент времени - он может подобраться ближе "к площадке" выступающего с интересным докладом или находится между двух площадок одновременно, он может объединится с коллегами комментируя по ходу доклад, но не мешая при этом другим участникам. И все это позволяет сделать механизм "области слышимости".
И как раз этот механизм позволит "ограничить" рост передачи количества "дорожек" по сети и нагрузку на "один пользовательский канал".
Согласен, на сервер действительно выйдет много нагрузки при наличии множества комнат.
Давайте сравним оба подхода. Пусть у нас есть k комнат в каждой из которых по n участников. Когда микшер на сервере, то получаем передачу по сети O(kn) сообщений и микширование O(kn^2) сообщений на сервере.
Когда микшер на каждом из клиентов, то получаем передачу по сети O(k * n^2) сообщений и микширование O(n) сообщений на каждом из (n * k) микшеров, установленных на клиентах.
Получаем, что в первом случае нужно наращивать ресурсы сервера в (n * k) раз, а во втором масштабировать канал передачи данных в n раз. Действительно, при большом количестве комнат второй способ явно привлекательнее.
Отмечу еще, что в первом способе можно сделать систему из нескольких серверов, которая будет перекидывать участников между серверами, если нагрузка на каком-то сервере превысила определенный предел.
Также, про митап с 1000+ участников согласен. При масштабировании определенно стоит добавить зону слышимости. Она действительно должна ограничить количество сообщений, передающихся по сети.
"масштабировать канал передачи данных в n раз"
а вот тут можно попробовать посмотреть в сторону P2P протоколов обмена между участниками, а сервер использовать исключительно как "координатор".
и минимизировать утилизацию ресурсов на серверном уровне.
В целом еще раз отмечу - идея интересная и перспективная. Я бы на вашем месте ее развивал именно в сторону массовых он-лайн мероприятий в "виртуальной реальности".
Сейчас КОВИД ограничения этому благотворствуют. Как минимум хайп на проведении "он-лайн корпоративов" обеспечен: собрать сотни сотрудников на одной он-лайн площадке, дать им возможность виртуального перемещения, встроить игровые механики, поставить "сцены" с выступлением приглашенных "групп" - имхо, потенциал огромен. Удачи!
В целом согласен с вами. Кстати, уже есть достаточное количество аналогов с такой же фишкой со звуком, что и у нас. Можно почитать эту ветку комментариев.
Спасибо вам за фидбек!
Это SpatialChat, но системный? Занятно.
Приложение для аудиозвонков с регулировкой звука, как в реальной жизни