Я о Roc впервые узнал несколько дней назад, еще до публикации на opennet, из рассылки pulseaudio, где сам автор анонсировал плагин для pulseaudio на основе Roc.
Т.е. на опеннете Roc хороший, pulseaudio плохой. При этом сам автор Roc предлагает использовать его вместе c pulseaudio. Иронично, не находите?

Если б люди обсуждали технические аспекты, а не ретроградские обиды, то магически, уверен, пульса бы стала хорошей.

Хотя стоп системд тоже же плохой...

Но bit-perfect поток, будь-то по сети, или по usb, она гоняет отлично. Разная разрядность сигнала, разная частота дискретизации — пульса переключает устройство в нужный режим и выводит звук без потерь. Я не знаю, что может еще потребоваться.

По поводу софта, его, конечно, мало, это правда. И если вопрос DAW с появлением Bitwig можно считать решенным (я для себя так решил, по крайней мере), то вот с VSTi печаль.

А что у альсы с задержками? Я не мерял, но иногда играюсь с pianoteq через альсу, там декларируемая задержка при моем буффере составляет ~6мс, но она почему-то ощущается, что совсем не имеет смысла (постоянная времени человеческого слуха — 150мс, что на два порядка выше этого значения!), подозреваю, что альса может что-то добавлять и там действительно больше 6мс. Есть у вас замеры?

Короче, нету ее, задержки. Все, как и на винде при использовании ASIO.

Если у вас есть другие замеры — давайте сюда, посмотрим вместе.

А то, что jack работает поверх альзы, мы никому говорить не будем.

Пока не понял, использует ли Roc кодирование с потерями для передачи (RTP предлагает разные кодеки,  я еще не смотрел, какой именно используется в Roc).

В текущем виде native tcp пульсы для меня имеет огромное преимущество — поддерживает любые комбинации разрядности и частоты дискретизации. Так что на одном устройстве, без переконфигураций я могу и киношку посмотреть, и качественные записи в 24/96 послушать. При этом, обращаю внимание, устройство на приемной стороне переводится в режим, скоторым передается поток (ессно, если устройство поддерживает). Roc-овские 16/44 смотрятся на этом фоне бледно.

Единственная киллер фича из описания — нечувствительность к локальному времени на устройствах. Вот здесь пульса может доставить хлопот на пару вечеров, особенно, если не знать об этой особенности. Но решается один раз настройкой ntp. Короче, пока native tcp пульсы удобнее для домашнего применения. Посмотрим, что Roc предложит в будущем.

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

Roc написан из расчета на самый общий случай, когда отправитель и получатель могут иметь независимые клоки, поэтому он эту проблему решает.

В штатном RTP транспорте пульсы все также. Только немного другой алгоритм подстройки.

В native транспорте пульсы используется другой подход. Отправитель не решает сам, когда послать следующую пачку сэмплов. Вместо этого отправитель ждет, когда получатель запросит у него следующую пачку. Таким образом отправитель не имеет независимого клока, а тактируется клоком получателя.

Про то как это решается в штатных транспортах пульсы можно посмотреть тут:
https://gavv.github.io/articles/pulseaudio-under-the-hood/#time-management

> Но вот если я хочу музыку с mpd играть _одновременно_ на ноутбучных колонках и на колонках, подключенных к удаленному устройству

Это вообще еще одна проблема. Тут в дополнение к первой проблеме нужно еще синхронизировать между собой всех получателей, чтобы они играли не только с одной скоростью, но и с почти одинаковой задержкой относительно сендера. Чтобы вы слышали синхронное звучание из всех колонок. Этого пока в Roc нет. Возможно будет.