The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Выпуск серверов для потокового вещания Roc 0.1, Ant 1.7 и Re..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Выпуск серверов для потокового вещания Roc 0.1, Ant 1.7 и Re..."  +/
Сообщение от opennews (??), 01-Июн-19, 11:43 
Доступно несколько новых выпусков открытых медаисерверов, предназначенных для организации потокового вещания в сети:

-  Представлен (https://gavv.github.io/articles/roc-0.1/) первый выпуск
Roc (https://roc-project.github.io/), тулкита для потоковой передачи звука по сети в режиме реального времени с гарантированным временем задержек и обеспечением качества на уровне звуковых компакт-дисков. При передаче учитывается отклонение времени  системных часов отправителя и получателя. Поддерживается восстановление потерянных пакетов при помощи кодов прямой коррекции ошибок (https://ru.wikipedia.org/wiki/%D0%9F%D1%... в реализации OpenFEC (http://openfec.org/) (в режиме минимальных задержек применяется код Рида — Соломона, а в режиме максимальной производительности - схема LDPC-Staircase (https://ru.wikipedia.org/wiki/%D0%9A%D0%.... При передаче используется протокол RTP (AVP L16, 44100Hz PCM 16-bit). В настоящее время пока поддерживается только передача звука, но в планах намечена поддержка трансляции видео и других типов контента.


Возможно мультиплексирование потока от нескольких отправителей для доставки одному получателю. Возможно подключение разных профилей настроек дискретизации, в зависимости от типа CPU и требованиям к задержкам при передаче. Поддерживается трансляции через различные типы сетей, включая локальную сеть, интернет и беспроводную сеть. В зависимости от настроек и качества сетевого соединения Roc автоматически выбирает необходимые параметры кодирования потока и в процессе передаче корректирует его интенсивность в зависимости от пропускной способности и потери пакетов.


Проект состоит из Си-библиотеки, инструментария (https://roc-project.github.io/roc/docs/running/command_line_... командной строки и набора модулей для звукового сервера PulseAudio (https://roc-project.github.io/roc/docs/running/pulseaudio_mo... для применения Roc в качестве транспорта. В простейшем случае доступный инструментарий позволяет направить звук из файла или звукового устройства на одном компьютере в файл или звуковое устройство другого компьютера. Поддерживаются различные звуковые бэкенды, включая ALSA, PulseAudio и CoreAudio. Код написан на языке C++ и распространяется (https://github.com/roc-project/roc/) под лицензией MPL-2.0.


-  Доступен (https://github.com/ant-media/Ant-Media-Server/releases) новый выпуск мультимедийного сервера Ant Media Server 1.7 (https://antmedia.io/), позволяющего организовать потоковое вещание через протоколы RTMP, RTSP и WebRTC с поддержкой режима адаптивного изменения битрейта. Ant также может применяться для организации сетевой записи видео в форматах MP4, HLS и FLV. Из возможностей можно отметить наличие конвертера WebRTC в RTMP, поддержку IP-камер и IPTV, распространение и записи live-потоков, организация стримминга в социальные сети, обеспечение масштабирования через развёртывание кластера, возможность массового вещания из одной точки многим получателям с задержками на уровне 500ms.


Продукт развивается в рамках модели Open Core, которая подразумевает разработку основной части под лицензией Apache 2.0 и поставку расширенных возможностей (например, стримминг в Youtube) в платной редакции. В новой версии на 40% повышена производительность вещания через WebRTC, добавлен просмотрщик логов, улучшена web-панель,  добавлен REST API для вывода статистики, оптимизировано потребление памяти, улучшена обработка ошибок и добавлена возможность отправки статистики в Apache Kafka.


-  Состоялся (https://github.com/Red5/red5-server/releases) релиз сервера потокового вещания Red5 (http://red5.org/), позволяющего передавать видео в форматах FLV, F4V, MP4 и 3GP, а также звук  в форматах MP3, F4A, M4A, AAC. Доступны режимы Live-вещания и работы в форме записывающей станции для приёма потоков от клиентов (FLV и AVC+AAC в контейнере FLV). Изначально проект был создан в 2005 году для создания альтернативы Flash Communication Server, использующей протокол RTMP. В дальнейшем в Red5 через плагины была обеспечена поддержка вещания с использованием HLS, WebSockets, RTSP и WebRTC.  


Red5 применяется в качестве сервера потоковой передачи в проекте Apache OpenMeetings (https://www.opennet.ru/opennews/art.shtml?num=46088) для организации видео- и аудиоконференций. Код написан на Java и поставляется (https://github.com/Red5/red5-server) под лицензией Apache 2.0. На базе Red5 построен проприетарный продукт Red5 Pro (https://www.red5pro.com/), обеспечивающий масштабирование до миллионов зрителей с задержками доставки на уровне 500ms и возможностью развёртывания в облаках AWS, Google Cloud и Azure.


URL: https://github.com/Red5/red5-server/releases
Новость: https://www.opennet.ru/opennews/art.shtml?num=50788

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (-), 01-Июн-19, 11:43   +2 +/
в первый раз слышу, но поздравляю причастных
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2

2. Сообщение от Аноним (2), 01-Июн-19, 11:51   –1 +/
Roc вроде пилит товарищ из России. Очень годный проект, судя по описанию. Задержки при передаче звука - больная тема для очень многих.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #6, #10

3. Сообщение от Аноним (3), 01-Июн-19, 12:45   –2 +/
А есть возможность организовать свой сервер с фоновой музыкой как у mpd?
Ответить | Правка | Наверх | Cообщить модератору

4. Сообщение от fgi (?), 01-Июн-19, 14:50   +1 +/
ant это форкнутый red5, какой смысл пиарить ред5 сразу два раза ?
Ответить | Правка | Наверх | Cообщить модератору

5. Сообщение от Вася (??), 01-Июн-19, 16:54   +2 +/
Про Roc не знал, интересно. Спасиб
Ответить | Правка | Наверх | Cообщить модератору

6. Сообщение от виндотролль (ok), 01-Июн-19, 22:03   –2 +/
Pulseaudio автоматически компенсирует задержки при передаче по сети.

Но исправно работающий пульсаудио на опеннете не любят. А альфаверсию экспериментальной либы называют годным проектом.

Почему?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #7, #8, #9, #22

7. Сообщение от Michael Shigorinemail (ok), 01-Июн-19, 22:36   +/
Возможно, потому, что вместо работы по сети или в режиме управляемого микширования приложений/выходов его запихивали примерно везде в режиме "всё равно придётся, ретрограды"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #17, #24

8. Сообщение от Аноним3 (?), 01-Июн-19, 22:48   –3 +/
а профи музыканты вообще не любят линух по одной простой причине - мало софта и тот без танца с бубном редко заводится. сам писал гитару , знаю о чем говорю. а если задуматься играть в линию компа, то вообще ужас. единственная попытка что то сделать это Jack, но и он работает с пинком только.про пульсу можно сказать только одно - она способна кое что делать, но только не микшировать )) вот если она работает простым мостом передачи это еще куда ни шло. но задержки звука это не та стихия. даже альса это ужас при игре в линию( а тут именно важны задержки). фишка в том , что мало софта , который был бы не очередным средненьким плеерком или текстовым редактором. но если тебе только мост нужен то пульса вполне себе перекинет тебе аудио на колонки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #11, #14, #21, #23, #25

9. Сообщение от Пользователь Debian (?), 01-Июн-19, 22:59   +1 +/
Вот тут https://gavv.github.io/articles/new-network-transport/ написано, что не так с задержками у пульсы (автор — главный разраб roc).

Кстати, у него в блоге есть эпик с описанием архитектуры пульсы в целом, если интересно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #12

10. Сообщение от Пользователь Debian (?), 01-Июн-19, 23:01   +/
Как минимум два товарища из России ;-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

11. Сообщение от виндотролль (ok), 01-Июн-19, 23:06   +/
Пульса никогда не позиционировалась как решения для проф работы со звуком.

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #39

12. Сообщение от виндотролль (ok), 01-Июн-19, 23:15   +/
Интересная статья, спасибо. И про пульсу будет интересно почитать.

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #15

13. Сообщение от gavv (?), 01-Июн-19, 23:21   +3 +/
> При передаче учитывается отклонение времени системных часов отправителя и получателя.

В оригинале имеются в виду не системные часы, а разница в частоте дискретизации отправителя и получателя. Эта разница всегда есть, и хоть она и небольшая, она накапливается.

Подробнее тут:
https://roc-project.github.io/roc/docs/internals/fe_resample...

> В зависимости от настроек, пропускной способности и потери пакетов Roc автоматически выбирает необходимые параметры кодирования потока и в процессе передаче корректирует его интенсивность.

Этого пока нет, только в планах. ПОка что настраивать нужно вручную.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16

14. Сообщение от виндотролль (ok), 01-Июн-19, 23:22   +1 +/
вот нашел, кто-то замерял задержку альсы
https://www.alsa-project.org/main/index.php/Test_latency.c

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

15. Сообщение от gavv (?), 01-Июн-19, 23:26   +1 +/
> Пока не понял, использует ли Roc кодирование с потерями для передачи (RTP предлагает разные кодеки,  я еще не смотрел, какой именно используется в Roc).

Пока только PCM 16 бит.

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

Пока в Roc этого нет. Это в планах на ближайшие несколько релизов.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

16. Сообщение от виндотролль (ok), 01-Июн-19, 23:29   +/
Прикольно, что об этом задумались. Но... а точно это надо?
Не проще ли увеличить задержку на тех самых 20µs (как указано в статье) и буфферизировать? 20µs вообще нереально услышать.

Более того, устройств с расбросом тактового генератор ±10Гц еще поискать надо, разве что с али по 5 штук на доллар заказать, так что в реальности буфер может быть еще короче.

Не, это, конечно, интересная задача поковырять, но имхо, с точки зрения пользователя — абсолютно бесполезная вещь.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #18

17. Сообщение от виндотролль (ok), 01-Июн-19, 23:39   +/
Вопрос «почему?» был риторический.

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #29, #31

18. Сообщение от gavv (?), 01-Июн-19, 23:40   +2 +/
Разница в частоте накапливается. Типичная скорость накопления - примерно 200 мс в час. То есть если вы выставили размер буфера в 200 мс и запустили проигрывание на час, через час вы получите либо пустой буфер (если ресивер чуть быстрее), либо 400 мс вместо 200 мс в буфере (если ресивер чуть медленнее).

Воспроизвести это можно взяв любые два кристалла :) Например два CPU на двух компьютерах или CPU и звуковая карта на одному компьютере. Если эту разницу не компенсировать, о фиксированном лейтенси говорить не приходится.

Эта проблема не нова. Она решается, в том числе, в штатных транспортах пульсаудио. native транспорт решает ее тактируя клиента клоком звуковухи. А RTP транспорт пульсы решает ее так же, как Roc - ресемплером.

Основная разница между штатными пульсовыми транспортами и роком - это восстановление потерь. Это актуально для Wi-Fi.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #19

19. Сообщение от виндотролль (ok), 01-Июн-19, 23:51   +/
> Эта проблема не нова. Она решается, в том числе, в штатных транспортах
> пульсаудио. native транспорт решает ее тактируя клиента клоком звуковухи. А RTP
> транспорт пульсы решает ее так же, как Roc - ресемплером.

Я, возможно, не обладаю пониманием проблемы. И не задумывался как именно проблема решается в pulseaudio, ваше объяснение много прояснило.

Правильно ли понимаю, что проблема актуальна только в случае если источник умеет исключительно синхронно генерировать поток?
Ну например, если у меня играет на ноутбуке mpd, то проблемы нету, т.к. я могу вычитывать с любой скоростью.
Но вот если я хочу музыку с mpd играть _одновременно_ на ноутбучных колонках и на колонках, подключенных к удаленному устройству, то решение tcp native приведет к underrun/overrun либо на одном, либо на другом устройстве (появятся щелчки). Либо, если я смотрю видео, то в случае tcp native у меня будут выпадать кадры или появляться паузы в видео.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #20

20. Сообщение от gavv (?), 02-Июн-19, 00:13   +1 +/
> Правильно ли понимаю, что проблема актуальна только в случае если источник умеет исключительно синхронно генерировать поток?

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

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #32

21. Сообщение от Annoynymous (ok), 02-Июн-19, 00:16   +2 +/
> даже альса это ужас при игре в линию
> единственная попытка что то сделать это Jack,

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #30

22. Сообщение от Аноним (2), 02-Июн-19, 06:23   +/
лично я не написал ничего плохого о пульсе. Что там любят/не любят на опеннете, меня мало волнует. И да, Roc - годный проект.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

23. Сообщение от Joshua (?), 02-Июн-19, 08:42   +1 +/
Профи музыканты используют профессиональную студийную аппаратуру для записи и сведения, если нет таковой то арендуют студии по часам. Домашние компы используют начинающие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #27

24. Сообщение от Аноним (24), 02-Июн-19, 12:51   +/
Т.е. системд который везде хороший. А пульс который пихают везде плохой?

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

25. Сообщение от Аноним (24), 02-Июн-19, 12:52   +/
Под звук надо реалтайм ядро. Почти уверен ты мало плясал с бубном.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #41

26. Сообщение от Аноним (26), 02-Июн-19, 14:23   –2 +/
ребята а как на googlechromocast передать фильмы с компа?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #28

27. Сообщение от виндотролль (ok), 02-Июн-19, 16:56   +1 +/
> Профи музыканты используют профессиональную студийную аппаратуру для записи и сведения,
> если нет таковой то арендуют студии по часам. Домашние компы используют
> начинающие.

Определение профи расплывчатое. Знаю музыкантов, которые производят очень хорошо продающиеся альбомы в домашних студиях.
Конечно, не знаю никого, кто бы при этом использовал линукс. Но большая студия от узнаваемого бренда с микшерами на 100500 каналов и '0 парами мониторов не нужна для продакшна уже много лет как. По крайней мере, в тех жанрах, где не нужна акустическая запись (хотя и здесь знаю пару очень продающихся примеров, когда только запись производилась на маленькой студии, а мастеринг — в домашних условиях).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

28. Сообщение от виндотролль (ok), 02-Июн-19, 16:57   +/
> ребята а как на googlechromocast передать фильмы с компа?

купить комп от гугла а хромосью

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

29. Сообщение от Аноним (29), 02-Июн-19, 19:33   +2 +/
> Т.е. на опеннете Roc хороший

Один аноним не является выразителем мнений всего опеннета. Большинство остальных просто остерегается давать оценки не глядя.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

30. Сообщение от Аноним3 (?), 02-Июн-19, 23:47   +/
тогда почему задержка jack меньше альсы? да добавлю пробовал и на винде с асио. короче задержка все равно есть. пока не купил лампу под гитару задержка всегда была.)) и она будет, поскольку сам принцип работы всех этих программных обработок требует времени. тут хоть что делай это не изменишь. вот если пишешь в линию с микрофона тогда все ок. поскольку все что идет, идет на простую запись в файл и он идет сплошным потоком.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #33, #34, #35

31. Сообщение от gsdh (?), 03-Июн-19, 04:18   +1 +/
> а не ретроградские обиды

есть 2 копии одной системы, на одной все ок, на другой пульса отваливается - просто пропадает звук, надо грохнуть демона и перезапустить сам процесс воспроизводящий звук, гемор. с альсой такого ни когда не было, тупо работало.

> Т.е. на опеннете Roc хороший, pulseaudio плохой.

Что странного, Stg-44 был хорошей винтовкой у плохих фашистов, как это связанно вообще.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

32. Сообщение от yaanon (?), 03-Июн-19, 12:31   +/
А для bluetooth наушников это тоже актуально? Слушаю с андроид.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

33. Сообщение от Аноним (33), 03-Июн-19, 14:13   +1 +/
> тогда почему задержка jack меньше альсы?

Потому что ты чего-то не учёл. Например, то, что jack тестировался на runtime-ядре, причём в ходе загрузки запускался волшебный скриптик, выставляющий приоритеты для прерываний.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #36

34. Сообщение от виндотролль (ok), 03-Июн-19, 20:35   +/
> тогда почему задержка jack меньше альсы? да добавлю пробовал и на винде
> с асио. короче задержка все равно есть. пока не купил лампу
> под гитару задержка всегда была.)) и она будет, поскольку сам принцип
> работы всех этих программных обработок требует времени. тут хоть что делай
> это не изменишь. вот если пишешь в линию с микрофона тогда
> все ок. поскольку все что идет, идет на простую запись в
> файл и он идет сплошным потоком.

Чем меряли задержку?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #37

35. Сообщение от Annoynymous (ok), 03-Июн-19, 21:02   +/
Потому что задержка — это не только звуковая карта. Это ещё и весь процесс обработки звука. И тут можно либо монопольно захватить звуковую карту, либо использовать jack, архитектура которого позволяет обрабатывать в режиме мягкого реального времени. В Windows те же функции выполняет ASIO, до появления которой всё тоже захватывали звуковую карту монопольно.

Да, задержка всегда есть, даже в аппаратных процессорах, которые по сути всё те же специализированные DSP. Только в Jack можно играться размером буфера и добить задержку до приемлемых миллисекунд. На моём Ryzen 5 2600 и Focusrite Scarlett 2i2 я могу себе позволить 4мс, например. Твоё оборудование может дать больше или меньше.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

36. Сообщение от Аноним3 (?), 04-Июн-19, 02:45   +/
я не об этом. не проще ли напрямую заставить jack взять управлением звуковухи.в любом случае игра в линию не вариант. я еще не встречал достойного исполнения этой вещи. я всегда чувствовал задержку звука на слух. пока не прикупил аналогового оборудования конечно. а комп просто как записывающая станция и все.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

37. Сообщение от Аноним3 (?), 04-Июн-19, 02:50   +/
если уши не отдавлены, то всегда услышишь разницу между ударом по струне и выходом звука. в винде под асио тоже была хотя по ощущениям малость поменьше. знаешь когда играешь важно точно вывести звук в нужный момент, а получается что струна уже звучит а звук как будто только прорвался через барьер и вырвался. оч неприятно хочу сказать. нет подстроится можно и даже сыграть, но это не то что нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #38

38. Сообщение от виндотролль (ok), 04-Июн-19, 04:04   +/
Понимаю, знакомый эффект.

Буфер в винде и в Альсе при этом был одинаковый, как понимаю?

На самом деле, это чертовски интересный вопрос, и очень не хватает компетентных ответов.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #40

39. Сообщение от Аноним (39), 04-Июн-19, 10:00   +/
А вы как звук выводите? Через line-out или ещё как-то?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #42

40. Сообщение от Аноним3 (?), 05-Июн-19, 01:23   +/
какая разница какой он был. они оба дают ощутимую задержку. вот в чем вопрос. и этот вопрос практически нерешаемый. разве что попытаться приблизиться к норме на профи звуковом оборудовании, но оч дорогом)) касательно Roc и прочих ничего не скажу, так как лаг задержки потока в сеть можно скомпенсировать . главное чтоб шло сплошным потоком и обычный человек уловит лаг только при запуске соединения и не будет обращать внимания. ну естественно это при нормальной скорости сети. а то в стране еще сохраняются тарифы с 1 мбит.))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

41. Сообщение от Аноним3 (?), 05-Июн-19, 01:30   +/
нет бубн тут не поможет.только реальная аналоговая аппаратура. проверена муками настройки и с асио и с jack. как итог пришел к мнению хочешь звук - бери ламповый усилок и играй. а писать через микрофон в комп. запись в файл без обработок потоком идет и проблем нет. но пропуск сигнала , допустим с гитары, для обработки программными дисторшенами и дилеями и вывод их на колонки не катит. не в смысле звука нет, он есть ,но когда ты дернул струну и уже приготовился чеканить следующую ноту, а звук только вышел на колонки это бесит.звук должен быть одновременно с касанием струны или нажатием клавиши(как угодно). и бесит всех музыкантов поверь. хотя я не профи так развлекаюсь.))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

42. Сообщение от виндотролль (ok), 05-Июн-19, 05:59   +1 +/
> А вы как звук выводите? Через line-out или ещё как-то?

line-out, конечно. Звуковуха E-MU 0404, в которой сигнал, насколько знаю, роутится как-то очень правильно, с использованием специального FPGA, так что в самой карточке задержки минимальны. Pianoteq в сравнении со встренным тембром рояля, казалось, играл немного с опозданием (играть можно было вполне, но, как будто, какая-то "вязкость" была, уж простите за такой термин).

Но я не утверждаю, что виновато ядро, альса, или еще что-то. Этому всему может быть много объяснений, включая то, что никакой задержки на самом деле нету, эффект субъективный, вызванный разницей в тембрах цифрового пианино и Pianoteq.

Надо мерять. Измерениям на слух (даже если это мой личный слух) я не верю.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

43. Сообщение от klalafuda (?), 08-Июн-19, 18:19   +/
Открытый Ant не впечатлил. Вещания через WebRTC нет - собственно основная вкусная вещь - а через HLS с естественной дикой задержкой и так каждый дурак может. Только в Enterprise. Низачет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #44

44. Сообщение от klalafuda (?), 08-Июн-19, 18:32   +/
> В дальнейшем в Red5 через плагины была обеспечена поддержка вещания с использованием HLS, WebSockets, RTSP и WebRTC.

Что-то я не замечаю WebRTC в Red5. Только в коммерческом Red5Pro. В результате в коре точно также грустно и скучно как и в анте.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру