Вы во многом сами отвечаете на свой же вопрос :) По сути вы описываете MCU/SFU, просто размещённый не на сервере, а на устройстве одного из участников — ровно так работал Skype на супернодах‑релеях, о котором упоминали в комментариях выше.
В архитектуре звезды микширующая мастер‑нода физически получает чистый звук всех участников, сервер из разговора я убирал ровно ради этого — а тут посредник возвращается, только теперь это устройство одного из участников.
Нагрузка при таком строении не падает, а концентрируется: соединений действительно меньше (9 против 45 для комнаты на 10 человек), но платим мы не за соединения, а за потоки: мастер принимает 9 и раздаёт 9 разных миксов (каждому — без его собственного голоса), то есть ровно столько же, сколько нёс любой пир в mesh, плюс CPU на джиттер‑буферы. Они же дают и задержку: путь «я → мастер → слушатель» вместо одного прямого хопа. Общий микс вдобавок убивает per‑peer громкость. Не говоря уже о хрупкости всей комнаты, о которой вы и сами упомянули.
А если рассматривать такую архитектуру как задел для конференций на 50+ участников — то одна нода столько не вытянет, и полсотни человек будут зависеть от чьего‑то ноутбука и качества его сети. Если центральный микшер всё‑таки нужен, его место в дата‑центре, где есть аплоад, аптайм и резерв — а это и есть SFU :)
Спасибо, корень вы назвали верно, но при таком подходе есть несколько критических преград.
Во‑первых — лаг будет копиться по кольцу. Микшировать, не выравнивая пакеты — нельзя, а значит на каждом узле нужен джиттер‑буфер, и он (+сетевой хоп) добавляется на каждом узле. В mesh до собеседника один прямой хоп, в кольце голос до дальнего пойдет через всех, плюсом — пакет уйдет на воспроизведение, только собрав всех. Бюджет для комфортной беседы ~150-250 мс, дальше она рассыпается — и уже при 5–6 пирах сумма хопов с буферами его съедает.
Второе — хрупкость. Основная боль как раз в мобильных сетях и CG‑NAT — узлы моргают постоянно. В mesh сетевые проблемы конкретного пира бьют только по его паре, у остальных всё живет. В кольце же при любом чихе одного узла — пересборка кольца для всех. Два кольца это частично исправляют, но возвращают ту нагрузку и сложность, ради ухода от которых всё затевалось.
И еще момент: у меня громкость регулируется per‑peer, свой range на каждого. В предложенной архитектуре если смикшировать звук выше по кольцу — все получат общий микс, отдельного человека уже не убавишь. А для демонстрации экрана такая архитектура и вовсе неприменима (изображение не суммируется так же, как и звук).
P.S: про «после скайпа P2P деградировал» — тут, мне кажется, не только рынок. Централизованный SFU выигрывает на масштабе, устойчивости к CG‑NAT и надёжности; скайповский же P2P был на супернодах‑релеях, и его закопали как раз за нестабильность. Хотя коммерческий интерес тоже никто не отменял)
Спасибо за статью, не попадалась. Дух в самом деле схож, но развилки разные — челлендж больше про передачу текста через брокеры, в то время как Void — про голос с собственным сигналингом. Но это очередное подтверждение того, что многое уже придумано до нас, и не раз.
Проект вырос из того самого вечера и строился на ходу, и в тот момент эта статья пригодилась бы мне куда больше, чем всё, что я тогда нагуглил)
Вы во многом сами отвечаете на свой же вопрос :) По сути вы описываете MCU/SFU, просто размещённый не на сервере, а на устройстве одного из участников — ровно так работал Skype на супернодах‑релеях, о котором упоминали в комментариях выше.
В архитектуре звезды микширующая мастер‑нода физически получает чистый звук всех участников, сервер из разговора я убирал ровно ради этого — а тут посредник возвращается, только теперь это устройство одного из участников.
Нагрузка при таком строении не падает, а концентрируется: соединений действительно меньше (9 против 45 для комнаты на 10 человек), но платим мы не за соединения, а за потоки: мастер принимает 9 и раздаёт 9 разных миксов (каждому — без его собственного голоса), то есть ровно столько же, сколько нёс любой пир в mesh, плюс CPU на джиттер‑буферы. Они же дают и задержку: путь «я → мастер → слушатель» вместо одного прямого хопа. Общий микс вдобавок убивает per‑peer громкость. Не говоря уже о хрупкости всей комнаты, о которой вы и сами упомянули.
А если рассматривать такую архитектуру как задел для конференций на 50+ участников — то одна нода столько не вытянет, и полсотни человек будут зависеть от чьего‑то ноутбука и качества его сети. Если центральный микшер всё‑таки нужен, его место в дата‑центре, где есть аплоад, аптайм и резерв — а это и есть SFU :)
Спасибо, корень вы назвали верно, но при таком подходе есть несколько критических преград.
Во‑первых — лаг будет копиться по кольцу. Микшировать, не выравнивая пакеты — нельзя, а значит на каждом узле нужен джиттер‑буфер, и он (+сетевой хоп) добавляется на каждом узле. В mesh до собеседника один прямой хоп, в кольце голос до дальнего пойдет через всех, плюсом — пакет уйдет на воспроизведение, только собрав всех. Бюджет для комфортной беседы ~150-250 мс, дальше она рассыпается — и уже при 5–6 пирах сумма хопов с буферами его съедает.
Второе — хрупкость. Основная боль как раз в мобильных сетях и CG‑NAT — узлы моргают постоянно. В mesh сетевые проблемы конкретного пира бьют только по его паре, у остальных всё живет. В кольце же при любом чихе одного узла — пересборка кольца для всех. Два кольца это частично исправляют, но возвращают ту нагрузку и сложность, ради ухода от которых всё затевалось.
И еще момент: у меня громкость регулируется per‑peer, свой range на каждого. В предложенной архитектуре если смикшировать звук выше по кольцу — все получат общий микс, отдельного человека уже не убавишь. А для демонстрации экрана такая архитектура и вовсе неприменима (изображение не суммируется так же, как и звук).
P.S: про «после скайпа P2P деградировал» — тут, мне кажется, не только рынок. Централизованный SFU выигрывает на масштабе, устойчивости к CG‑NAT и надёжности; скайповский же P2P был на супернодах‑релеях, и его закопали как раз за нестабильность. Хотя коммерческий интерес тоже никто не отменял)
Спасибо за статью, не попадалась. Дух в самом деле схож, но развилки разные — челлендж больше про передачу текста через брокеры, в то время как Void — про голос с собственным сигналингом.
Но это очередное подтверждение того, что многое уже придумано до нас, и не раз.
Проект вырос из того самого вечера и строился на ходу, и в тот момент эта статья пригодилась бы мне куда больше, чем всё, что я тогда нагуглил)
Спасибо!
Да, в становлении итогового дизайн кода во многом помог Claude Design, а немалый вклад в разработку внес Opus 4.8
Прототип изначально выглядел так