Вадим, рендерер реализует стандартный протокол DLNA/UPnP. Да, он получает ссылку на http-источник потока, загружает его, декодирует и воспроизводит. Поэтому для полного комплекта рендереру нужны управлялка (контрольная точка) DLNA/UPnP и http-сервер. Иногда эти функции совмещены в одном приложении, иногда это отдельные приложения.
2 лайка
Обновлен до версии 3.2 драйвер asioscream для Windows в архиве asioscream3.zip. Устранена недоработка из-за которой сетевые пакеты с аудиоданными передавались недостаточно равномерно. Равномерность передачи пакетов может влиять на качество результата. Там, где драйвер уже установлен, достаточно заменить файл asioscream.dll на новый вариант.
14 лайков
Драйвер asioscream обновлен до версии 3.3. Оптимизирован код драйвера, снижена нагрузка на процессор. Повышена точность синхронизации при передаче пакетов в сеть. Исправлен выбор выходной разрядности аудиоданных. Там, где драйвер уже установлен, достаточно заменить файл asioscream.dll на новый вариант.
12 лайков
Здравствуйте, Игорь!
Огромное Вам Спасибо за очередное обновление.
Заметил интересную особенность. Если возможно, поясните пожалуйста.
При трансляции потока с запущенным asioscream с Win DLNA/UPnP сервера (minimserver & Linn Kinsky) на (YoctoAP & aprenderer & screamap) и дальше на endpoint (YoctoAP & apscream) с сервера поток отправляется явно выраженной “пилой” формируемой minimserver.
Т.е. в такой конфигурации включение asioscream фактически теряет смысл.
Но в тоже время, при использовании aprenderer на стороне Win DLNA/UPnP сервера с использованием тех же minimserver & Linn Kinsky и дальше сразу на endpoint (YoctoAP & apscream), выходящий поток идеально ровный. То есть в этом случае asioscream перехватывает управление потоком.
Интересует вопрос. Насколько это критично в первом случае, когда основная работа по декодированию и воспроизведению осуществляется на следующем плече (YoctoAP & aprenderer & screamap) → endpoint (YoctoAP & apscream). Возможно в этом случае вообще нет смысла запускать asioscream?
Можно ли реализовать чтобы asioscream выполнял свои функции без запущенного на стороне Windows рендерера\плеера.
Спасибо.
Здравствуйте, Игорь!
Хотел спросить почему в “коробочных” настройках для всех платформ период и буфер альсы Вы задаете в фреймах, а не в микросекундах? Это как-то связано с тем, что буфер предзагрузки стандартного режима воспроизведения использует именно фреймы? Например, я уже давно заметил, что если выставить период и буфер альсы в микросекундах (100000 и 500000, соответственно), то при проигрывании файла 44.1 КГц на вкладке" Status" период альсы будет 4410 фреймов:
если 48 КГц, то 4800 фреймов:
то есть, между ними существует некая корреляция, чего нет если задавать период и буфер альсы в фреймах.
Ещё заметил, что обычно (для ARM) период и буфер альсы в плеере и рендерере 512 и 8192, то есть значение для буфера в 16 раз больше, а в приемнике ScreamAP эти значения 1024 и 32768, то есть, тут буфер больше периода в 32 раза. Это сделано же явно не с проста? И какое, все-таки, оптимальное соотношение периода к буферу альсы? Например, для MPD в микросекундах 5 раз (100000 и 500000), у Вас они разнятся.
Просто, мне показалось, что у меня эти значения влияют на звук при использовании ScreamAP, в отличии от Аплеера и рендерера, пытаюсь понять, хоть в каких значения играться с этими параметрами.
Юрий, последнее звено должно буферизовать неравномерность загрузки в рендерер и передавать в конечную точку равномерный поток. Загрузку в рендерер можно сделать более равномерной в режиме Direct Input с небольшим буфером. При трансляции с Windows компьютера на рендерер используется протокол DLNA/UPnP, а не scream, поэтому asioscream в таком сценарии не используется.
Сервер отдаёт только по UPnP, поэтому либо рендерер, либо плеер нужен, чтобы использовался asioscream. Можно при желании организовать конвейер на трёх устройствах asioscream->apscream+ScreamAP->apscream, но насколько это будет хорошо и стабильно, заранее не знаю.
Сегодня asioscream обновился на 3.4, там убрано лишнее копирование выводимых данных.
4 лайка
Так сделано для предсказуемой точной пропорциональности буферов.
Оптимальным считается соотношение от 4 до 10. Однако период подразумевает передачу этих порций данных аппаратным контроллером через DMA буфер, который на приемной стороне может быть ограничен какими-то килобайтами.
Большой размер буфера в apscream связан с его дополнительной ролью - компенсировать неизбежное расхождение часов приемника и передатчика протокола scream, которое на длинной дистанции неизбежно приведёт к исчерпанию или переполнению буфера.
4 лайка
У меня именно так и реализовано. Работает очень хорошо и стабильно даже на Wi-Fi подключении endpoint.
Игорь, спасибо Вам за развёрнутый ответ.