Настройка airplay для onkyo

Airplay в ресивере ONKYO

Поток компьютер на основе аудио без проводов С помощью AirPlay, вы можете также транслировать каждую песню и список воспроизведения из библиотеки ITunes на вашем Mac или Windows PC к совместимой системе Onkyo. ITunes и Onkyo-схождение без использования кабелей.

Remote App для компьютерного аудио с помощью бесплатного приложения Remote Apple, вы можете превратить устройство ОС IOS в удобный пульт дистанционного управления для вашего компьютера на базе библиотеки ITunes. Обзор, чтобы найти свои любимые треки, даже если вы находитесь в другой комнате с вашего компьютера и системы привет-Fi.

Продукты поддерживающие технологию AirPlay:
ONKYO T-4070 — тюнер
ONKYO ABX-N300 — беспроводная музыкальная система
ONKYO DS-A5 — док станция для iPod/iPhone/iPad
ONKYO TX-NR545 — 7.2-канальный сетевой AV-ресивер
ONKYO TX-NR646 — 7.2-канальный сетевой AV-ресивер
ONKYO TX-NR747 — 7.2-канальный сетевой AV-ресивер
ONKYO TX-RZ800 — 7.2-канальный сетевой AV-ресивер
ONKYO TX-RZ900 — 7.2-канальный сетевой AV-ресивер
ONKYO TX-8150 — Сетевой стерео ресивер
ONKYO TX-NR555 — 7.2-канальный сетевой AV-ресивер
ONKYO TX-NR656 — 7.2-канальный сетевой AV-ресивер
ONKYO TX-RZ710 — 7.2-канальный сетевой AV-ресивер
ONKYO TX-RZ810 — 7.2-канальный сетевой AV-ресивер
ONKYO HT-S7805 — 5.1.2 комплект домашнего кинотеатра

Источник

Настройка airplay для onkyo

Первые анонсы Apple AirPlay 2 появились еще летом 2017 года, позже протокол заработал на умной колонке Apple HomePod, а теперь начал понемногу добираться до девайсов сторонних производителей. Наконец, мы решили познакомиться с ним и оценить все его возможности.

Теория

Фактически, Apple AirPlay — это такой вариант проприетарного DLNA. Раньше в нем было всего два звена: один источник и один приемник. Источником чаще всего был смартфон или ноутбук, а приемником — колонка или ресивер с поддержкой протокола. В этом плане от Bluetooth протокол отличался тем, что работал по Wi-Fi и потому несколько иначе модифицировал сигнал (@YG делал полноценное исследование о том, меняет ли AirPlay сигнал, и сначала получил данные об ухудшении, но после была обнаружена ошибка в процедуре теста — на самом деле, поток передается с побитовой точностью).

Во второй версии протокола добавился мультирум: теперь источник может одновременно передавать сигнал на несколько приемников. Источники, поддерживающие AirPlay 2, могут работать с приемниками с AirPlay старой версии, но вот добавить такие приемники в мультирумную систему не выйдет (на самом деле, это не всегда так, но об этом далее). В этом исследовании мы остановимся на мультируме.

Функция мультирума также позволяет собрать стереопару из двух умных колонок HomePod. Связать источник с приемником по протоколу можно как через системное меню, так и через приложения стриминговых сервисов, плееров и так далее. Правда, работает он только в iOS 12 и новее. То есть источниками могут быть iPhone не младше 5S, iPad с 2017 года, любые iPad Air и iPad Pro, iPad Mini 2, iPod Touch 2015 и старше, а также современные MacBook с MacOS 10.13.2 и новее и ПК с Windows на борту, использующие iTunes (которого скоро не будет). Приемниками могут стать Apple HomePod, а также устройства иных производителей, заявляющих о поддержке. Приставки Apple TV с tvOS 11.4 и новее поддерживают работу как в качестве источника, так и в качестве приемника.

Еще одно улучшение в AirPlay 2 — заявленная продвинутая буферизация, которая не дает сигналу рваться и пропадать. А еще все источники, находящиеся в одной домашней сети, могут контролировать воспроизведение на приемниках.

Все это мы проверили, собравшись у MMS в шоуруме и обложившись двумя (а после и тремя) парами KEF LSX и новеньким Apple TV.

Практика

С интерфейсом и процессом работы AirPlay даже я, щупавшая iPhone в последний раз в 2013 году, разобралась практически мгновенно. Ищешь в любом приложении или в уголке главного экрана иконку протокола, жмешь, потом выбираешь приемники, на которые хочешь отправить сигнал, и ждешь, когда возле них появятся галочки. Одновременно с появлением галочек акустика начинает звучать. У каждого приемника есть собственный регулятор громкости, а под списком находится общий регулятор, который синхронно двигает ползунки. С любого источника в домашней сети можно приостановить воспроизведение и запустить его заново. Несколько устройств можно собрать в одну комнату в приложении Home.

Интерфейс меню AirPlay 2 при запуске через Tidal. На левом скриншоте видно, что регуляторы громкости отдельных приемников синхронизированы с мастер-регулятором

Основная фишка обновленного AirPlay — это все-таки мультирум, и именно эту функцию мы проверили первым делом. Для того, чтобы AirPlay увидел колонки KEF, необходимо сначала подружить их с домашней сетью. Для этого нужно поставить на смартфон приложение KEF Control и, следуя инструкциям, настроить акустику. В приложении для удобства можно задать колонкам какое-нибудь имя — например, указать цвет или название комнаты, в которой они стоят.

После настройки обе пары KEF LSX были видны и в меню iPad и iPhone, и в приложении Tidal (а Apple TV был виден и так). Сразу скажу, что в процессе теста мы для наглядности настраивали KEF несколько раз, поэтому на скриншотах имена у колонок разные — заданные нами и автоматически названные приложением. Сигнал можно отправить одновременно на все пары колонок.

Подключение колонок через интерфейс системы

Первый сценарий, который мы опробовали — запустить музыку в Tidal на iPad и отправить ее и на все LSX, и на систему с Apple TV. В последнем варианте иногда наблюдался рассинхрон по звуку — то одна, то другая пара колонок запаздывала, создавая абсолютно психоделичный эффект. В некоторых случаях задержка выравнивалась сама, в других же стоило помочь устройствам, поставив воспроизведение на паузу, подождав пару секунд и включив вновь.

Как и любой протокол на базе DLNA, работает AirPlay 2 с задержкой — между запуском трека на источнике и стартом воспроизведения проходит несколько секунд. Эти секунды, судя по всему, уходят на буферизацию сигнала. Видимо, на одном приемнике буферизация занимала больше времени, чем на другом — отсюда и рассинхрон. Из-за этой же буферизации, к примеру, не удастся играть по AirPlay на музыкальном инструменте.

Вот так можно перебить уже воспроизводящийся контент каким-нибудь своим

Что интересно, при работе с несколькими приемниками время задержки серьезно увеличивается, чем при подключении только к одному приемнику — секунды на две. Видимо, алгоритм задумывается.

Можно также запустить видео на Apple TV и отправить звук не на подключенную к нему систему, а на AirPlay-колонки в домашней сети. В этой ситуации рассинхронизации между звуком и видео не было. Главное — выбрать в меню Apple TV стереорежим воспроизведения вместо многоканального, иначе магии не будет. В такой ситуации, правда, сам Apple TV начинает достаточно долго думать перед тем, как воспроизвести видео — вновь вступает в силу буферизация аудио, требующая времени.

А еще можно бороться за власть, посылая на приемники сигналы из разных источников и перебивая друг друга. Защиты от этого никакой нет: если девайс в домашней сети хочет отправить песенку на колонки, то ему не помешает то, что колонки уже что-то воспроизводят — разве что интерфейс спросит, точно ли вы хотите заменить воспроизводящийся контент. Но можно и поделить сферы влияния.

Скриншоты интерфейса выбора на iPhone

Связующим звеном между двумя поколениями AirPlay оказался MacBook. С помощью него, как выяснилось, можно организовать мультирум между устройствами, поддерживающими разные версии AirPlay — то есть одновременно отправить сигнал и на LSX, работающие с AirPlay 2, и на Apple TV, и на интегральник с функциями сетевого плеера с AirPlay первого поколения. При этом задержки и рассинхронизации между системами разных эпох нет. Скорее всего такой несанкционированный мультирум получилось организовать из-за того, что в ноутбуке стоит более продвинутый чип Wi-Fi, чем в смартфонах.

«Комната для отдыха» — это зона из компонентов Primare в шоуруме MMS, которая работала только с первой версией AirPlay. Тем не менее, она доступна для подключения на MacBook и может играть совместно с другими приемниками

У протокола, конечно, есть свои ограничения. Отправить с одного источника разные сигналы на разные приемники нельзя — то есть, например, сделать так, чтобы запущенные на одном и том же смартфоне Tidal и Spotify играли в разных комнатах не выйдет. Отправить, к примеру, звук на LSX, а фотографию на Apple TV тоже не получится.

В идеале домашняя сеть должна быть построена на хорошем роутере, чтобы все устройства в ней чувствовали себя стабильно — DLNA, конечно, подстраховывается буферизацией, но чем хуже сеть, тем дольше думает протокол. Предыдущая версия AirPlay страдала заметными выпадениями и заиканиями, и, хоть во втором поколении мы с таким не сталкивались, лучше все-таки подстраховаться.

Вывод

Apple немного припозднилась с выходом на рынок мультирума, но у нее есть одно большое преимущество перед конкурентами — уже готовая экосистема, в рамках которой этот мультирум работает без всяких проблем.

Реализация протокола у сторонних производителей в первых прошивках может быть шероховатой, но мы с проблемами не столкнулись. Собрать разноцветный и звучащий мультирум из KEF LSX удалось буквально за минуту, поэтому еще один плюсик в карму Apple получает за простоту работы AirPlay 2.

Сам протокол имеет несколько ограничений. Буферизация, например, может немного раздражать, причем как при воспроизведении музыки со смартфонов, так и при воспроизведении аудиодорожки в фильмах при работе с Apple TV. Радость от мультирумного использования может подпортить периодическая рассинхронизация, которая, правда, легко лечится, но предугадать, когда один из приемников вдруг решит задуматься посильнее, нельзя.

Для того, чтобы собрать мультирум, в котором в одной комнате играет одна мелодия, а в другой — другая, потребуются два источника. Да и в принципе посылать одновременно с одного источника разный контент на разные приемники нельзя.

Часть редакции Stereo.ru борется за то, чтобы играл тот источник, который у него в руках

Но система вышла удобной. Простой, действительно интуитивной и все-таки более качественной в плане звучания, чем Bluetooth. И добавлю: через фирменное приложение KEF те же LSX можно подружить с домашней сетью по DLNA даже с Android-смартфона, но мультирума там не будет.

Благодарим компанию MMS за предоставленную технику для тестирования.

Источник

Протокол ISCP/eISCP от Onkyo: управление устройствами Onkyo по сети

Я уверен, что многие из читателей Хабра знают, или хотя бы слышали, об аудио-аппаратуре компании Onkyo. Современные сетевые плееры и A/V ресиверы имеют на борту Линукс, а также возможность проводного/беспроводного подключения к сети. Компания Onkyo предоставляет своё фирменное мобильное приложение для удалённого управления подобным устройством — Onkyo Controller. Информации, как это приложение работает, практически нет — есть крохи на форумах, а также несколько проектов на github.

Но можно отыскать в сети описание протокола Integra Serial Communication Protocol over Ethernet (eISCP), который и лежит в основе этого приложения. Протокол интересный. На Хабре ни одной статьи по этому протоколу найти не удалось. С одной стороны, ничего трагичного в этом нет, так как эта проприетарщина нигде, кроме Onkyo, вроде бы и не используется. С другой стороны есть шанс, что найдутся энтузиасты, которые захотят самостоятельно порулить своим плеером или ресивером Onkyo. Также статья может быть интересна тем, кто чисто из теоретического любопытства коллекционирует знания по различным сетевым протоколам. Если заинтересовал, прошу под кат.

Официальной информации по теме статьи мало. Поэтому я буду опираться не только на найденную документацию, так как она описывает исключительно команды протокола, но ничего не говорит об особенностях их использования. Много информации удалось получить как из анализа сетевого трафика с использованием tcpdump/wireshark, так и исследования прошивки устройства. Именно с этого я и начну.

Конкретная модель моего устройства не важна. Скажу только, что это сетевой плеер, похожий на тот, что на картинке для привлечения внимания. Он может проигрывать музыку не только с внешних USB-носителей, но и с музыкального сервера (DLNA), а также поддерживает интернет-радио и потоковые сервисы типа Spotify, Deezer и ещё что-то. Естественно, протокол должен всё это разнообразие поддерживать.

Анализ портов

Для того чтобы начать задавать правильные вопросы в поисковике, пришлось сначала понять, что за протокол вообще используется. То есть первый шаг — анализ портов. Итак, устройство в сети, его адрес — 192.168.1.80. Сканируем весь диапазон портов:

Открыто много чего интересного:

80/tcp понятно — это страница настройки устройства. В моей модели здесь только настройка сети и обновление прошивки. Никакого управления воспроизведением нет. Через него же по динамическим ссылкам вида «http://192.168.1.80/album_art.cgi» можно получить доступ к картинке трека, который в данный момент играет.
4545/tcp — появился после самого последнего обновления прошивки. Nmap про него ничего не знает. При попытке соединения сразу же посылает json с текущим статусом воспроизведения и каждую секунду высылает обновление

Анализ трафика

Теперь проверим, по какому порту и как именно общается с устройством официальное приложение. Проще всего сделать это на каком-нибудь рутованом Андроиде (но не в эмуляторе, так как официальное приложение требует наличия управляемого устройства в той же локальной подсети). Для этого:

Установим Android tcpdump на Андроид-устройстве, где уже установлено приложение Onkyo Controller
Заходим на Андроид-устройство через adb как root:

переходим в любой каталог встроенной SD-карты:

запускаем tcpdump (с записью в файл)

Запускаем приложение Onkyo, и оттуда запускаем воспроизведение музыки

Когда наберётся несколько сотен пакетов, останавливаем tcpdump по Cttl+C

Возвращаемся в терминал, откуда запустили ADB и копируем файл на рабочий компьютер

Запустим wireshark и смотрим, что там происходит

И действительно, общение идёт по 60128 порту. Например, приложение посылает запрос на плеер:

А тот на него отвечает:

Вот мы и подошли к самой сути статьи, а именно: что же это на картинках выше за буквы такие — ISCP? Эта аббревиатура означает Integra Serial Control Protocol, изначально разработанный для управления устройствами Onkyo через порт RS-232 (есть старая интересная статья по этому поводу). Позже его расширили добавлением префикса «е» и получилось eISCP — Integra Serial Communication Protocol over Ethernet. Обе версии протокола описаны в документе «Technical Documentation: Integrated Serial Communication Protocol for AV Receiver». Первая версия документа датирована 31 октября 2012 года, последняя, которую удалось найти — 4 сентября 2017. Все версии, которые я нашёл, собраны в моём репозитории демонстрационного проекта, о котором я расскажу попозже. Дальнейшее изложение будет базироваться как на этом документе, так и на опытах с моим плеером (который, правда, в этом документе явно не упоминается).

Спецификация сообщений

Клиент (например, мобильное приложение) и устройство обмениваются короткими текстовыми сообщениями. Если в нем присутствуют цифры, то они представлены, как правило, в шестнадцатеричном виде.

Формат сообщения от клиента к устройству очень простой:

Сообщение начинается с символа «!», потом идёт код целевого устройства, после чего три буквы команды, и затем строка параметров произвольной длины. Оканчивается символом CR (0x0D) или LF (0x0A), или комбинацией CR+LF.

В зависимости от команды, устройство отвечает либо тем же типом сообщения (если это был запрос какого-либо параметра), либо другим типом или даже комбинацией сообщений (если это была команда на сложное действие типа переключения трека). Формат сообщений, посылаемых устройством на клиента, такой же. Отличие только в последнем байте:

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

Команды можно сгруппировать в логические группы. В качестве примера, я бы выделил такие:

Общее управление устройством:
- NDN: имя устройства.
- UPD: проверка и установка обновления прошивки.
- PWR: включение/выключение питания.
- NRI: расширенная информация об устройстве.
- NTC: команды стандартного пульта дистанционного управления (в т.ч. управление воспроизведением).
- CAP: команды управления внешним усилителем, подключённым к разъёму RI.
Информация о воспроизводимом треке:
- NAL: имя альбома.
- NAT: имя артиста.
- NTI: название трека.
- NFI: информация о файле трека (формат, битрейт).
- NJA: картинка, привязанная к треку (например, эмблема радиостанции, если выбрано интернет-радио).
- NTM: текущая временная позиция в треке.
- NTS: статус, разрешена «перемотка» или нет (для интернет-радио, например, не разрешена).
- NST: управление повтором и случайным воспроизведением.
Навигация по фонотеке и управление ей:

SLI: выбор источника (например, USB, сетевые сервисы).
NSV: выбор конкретного сетевого сервиса (например интернет-радио, музыкальный сервер). Плейлист на моём устройстве также относится к сетевым сервисам, хоть это и не совсем очевидно с точки зрения пользовательского интерфейса. Причём при отключении питания (выдёргивании из розетки) этот плейлист удаляется!
NLT, NLA: навигация по разделам (папкам) фонотеки.
PQA, PQR, PQO: управление плейлистом: добавление, удаление, изменение порядка.

Естественно, этот список далеко не полный, я привёл его только ради того, чтобы показать охват и возможности данного протокола.

С точки зрения параметров, все сообщения можно разделить на две группы. В первую группу входит большая часть сообщений. Для этой группы строка параметров содержит данные в буквенном или шестнадцатеричном виде и разбирается побайтно. Например, при переходе в сервис TuneIn Radio плеер высылает сообщение NLT — информацию о заголовке текущего списка с параметром «0E01000000090100FF0E00TuneIn Radio», который, будучи декодирован в соответствии со спецификацией, даёт такую информацию:

Практически все сообщения имеют параметр «QSTN», например «!1NLTQSTN». Этот запрос означает просьбу к плееру вернуть актуальную статусную информацию, соответствующую этому типу сообщений. Работает практически всегда, но есть редкие исключения, когда плеер, в зависимости от своего внутреннего настроения, игнорирует такие запросы.

Вторая группа — это сообщения, где параметром является XML, который нужно разбирать с использованием XML-парсера. Из примера выше, находясь с разделе TuneIn Radio, можно послать запрос NLA, на который ответом придёт информация об активном списке в формате XML:

То есть плеер не только предоставляет текстовую информацию (которая, кстати, отображается в данный момент на дисплее самого плеера), но также и советует адекватную иконку (папка, музыкальный трек, проигрываемый в данный момент трек).

В некоторых случаях плеер хочет показать в клентском приложении текстовое сообщение или запросить дополнительные параметры типа имени пользователя. Для этого плеер посылает универсальное сообщение NCP (универсальный диалог), где в XML описана структура того, что нужно показать пользователю:

В ответ плеер ожидает это же самое сообщение с заполненными полями (или нажатой кнопкой).

Также в XML формате представлено достаточно важное сообщение NRI — общая информация о плеере. Сообщение достаточно большое, поэтому прячу его под спойлер.

Набор команд, который придётся задействовать для управления устройством, во многом зависит от того, что находится с секциях zonelist и controllist этого сообщения.

ISCP over Ethernet (eISCP)

Сообщения в том виде, как я писал выше, предназначены для передачи по кабелю (RS-232). Старые модели ресиверов оснащались для этого 9-контактным разъёмом RS-232. Когда же вместо этого разъёма стали использовать подключение к сети (проводное или беспроводное), то пришлось завернуть эти сообщения в обёртку для передачи по TCP/IP. Так появился протокол eISCP, где ISCP-сообщение завёрнуто в такой пакет:

Под спойлером код процедуры, которая полностью формирует такой пакет для сообщения с заданным кодом (переменная code), сформированной строкой параметров (переменная parameters) и заданной версией протокола (переменная version). Так как процедура достаточно простая, то, мне кажется, код на Джаве скажет много больше, чем тысячи слов.

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

Реализация обмена информацией

Сами сообщения, изначально разработанные для передачи по низкоскоростному кабелю, достаточно маленькие. Более того, ещё и сам плеер достаточно скромен — на фоне огромного объёма статистики, отсылаемой куда-то на сервера условного «Амазона», объём информации, которую плеер добровольно отдаёт клиенту по ISCP, просто мизерный. В спецификации протокола нет ни слова о том, когда и при каких условиях плеер посылает ту или иную информацию. Поэтому здесь пришлось достаточно долго экспериментировать самому, чтобы мобильный клиент всегда имел всю необходимую информацию о текущем состоянии устройства.

В целом, общение с плеером строится по схеме запрос/ответ. Причём в определённых ситуациях одним запросом ограничится не получится. Для моего плеера есть несколько ключевых событий, которые нужно обрабатывать:

Поэтому сразу же после установки соединения имеет смысл отправить запросы PWR (активен или в состоянии ожидания), UPD (есть ли обновление прошивки), NRI (общая информация об устройстве), SLI (положение переключателя входа), NJA (режим передачи картинки трека — по ссылке или потоком). Состояние воспроизведения и текущее положение мой конкретно плеер высылает по собственной инициативе.
Начало воспроизведения. В этой ситуации плеер высылает всю информацию о треке. Но при установке соединения, когда плеер уже что-то воспроизводит, плеер не высылает ничего. Кроме того, когда плеер переключает трек, высылается не вся информация.

Универсальным, хоть и ресурсоёмким решением оказалось отслеживать сообщение NST (состояние воспроизведения), и, если это состояние переключилось на «Play», то сразу отправлять 7 запросов: NAT (исполнитель), NAL (заголовок альбома), NTI (заголовок трека), NFI (информация о файле), NTR (номер трека), NTM (текущее время воспроизведения), NMS (меню трека). Есть особенности в прошивке плеера. Например, при воспроизведении плейлиста плеер ну ни в какую не хочет отдавать номер воспроизводимого трека. Но в целом, можно достаточно подробно узнать текущее состояние воспроизведения.
Плеер воспроизводит альбом (или плейлист) и переходит на новый трек. Тут у него начинается какой-то словесный вулкан. Под спойлером я спрятал фрагмент лога входящих сообщений, которые плеер высылает в момент переключения трека. Обратите внимание на временной маркер — весь процесс занимает около 14 секунд!

Пример приложения

В качестве примера дам ссылку на мой репозиторий с Андроид-приложением для дистанционного управления плеером Onkyo NS-6130. Есть шанс, что оно будет также работать с Onkyo NS-6170. Но использовать его с каким-нибудь ресивером Onkyo не получится, так как весь интерфейс приложения заточен именно на воспроизведение и управление фонотекой, чего на ресиверах, как правило, нет. Поэтому у меня нет планов как-нибудь это приложение распространять, здесь я пишу о нём только в качестве примера реализации данного протокола.

Структура приложения простейшая, дизайн минималистический. В наличии всего три вкладки:

навигация по фонотеке и управление плейлистом

информация об устройстве

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

Если после прочтения этой статьи кто-то из владельцев Onkyo устройств захочет поэкспериментировать со своим экземпляром, я надеюсь, что этот материал и мой пример приложения снизят порог вхождения в тему.

Источник