Меню Рубрики

Onkyo remote для windows

Onkyo remote для windows

Аудиоплеер от японского производителя высококачественной аудиотехники, предназначенный для проигрывания несжатой музыки.
Почти год назад появился для яблочек, и наконец дошел и до нас.

Поддерживаемые форматы:
• MP3, ALAC (до 48 kHz)
• DSF/DSD-IFF (2.8 MHz/5.6 MHz/11.2 MHz)
• FLAC, ALAC, WAV, AIFF, Ogg-Vorbis (до 192 kHz)
(Аудио с частотой дискретизации выше 88.2 kHz даунсемплится до 44.1 kHz или 48 kHz)
Также поддерживается вывод звука на некоторые usb-усилители, совместимые с Android Open Accessory Protocol 2.0.

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

Сообщение отредактировал iMiKED — 26.06.20, 21:19

maksnogin, скачать можно с торрент-трекеров. Вообще качество должно быть выше, но все зависит от используемого для прослушивания оборудования — понятно, что от Андроида ждать чудес не стоит. Так что выслушивайте разницу сами.
Для справки: https://ru.wikipedia.org/wiki/Сравнение_цифровых_аудиоформатов

Сообщение отредактировал Mozgovlom — 31.12.14, 17:33

Что нового
• Support for USB Host Audio Function. Digital connections to external devices such as USB DACs via OTG (On The Go) cables are enabled. Output is restricted to 48 kHz, but you can enjoy Hi-Res Audio by purchasing an Unlock Key application.
USB Host Audio Function is unlocked by the Unlock Key application.
*Hi-Res Audio output
*Upsampling function
*Support for native DSD playback via DoP output
• Save battery life when playback is paused

Не загружается на сайт, короче. Ссылка на Маркет в шапке

Сообщение отредактировал Эмир Бухарский — 04.02.15, 11:43

Это уже интересно — пробовал кто? Какие девайсы поддерживаются? У меня есть в заначке V-DAC II и усилитель для наушников Creek OBH-21 — было бы идеально! Надо поэкспериментировать! Если выйдет — вот оно решение для портативного Hi-Fi! Жаль, DLNA не умеет.
[Добавлено]Рискнул купить Unlocker.
Плеер сразу опознал мой ЦАП и стал играть. И играть неплохо! Таким образом, заявленный функционал присутствует.
Решение нельзя назвать совсем портабельным — не будешь же с собой таскать ЦАП, усилитель и наушники! Так же нельзя назвать решение на 100% удобным для дома — даже на быструю SD-карточку файлы копируются достаточно медленно, а сети плеер не понимает. Но факт есть факт — Hi-Fi звук с планшета.

Сообщение отредактировал alexeySTP — 11.02.15, 22:48

Источник

Onkyo Remote 2 (Updated: Mar 21, 2013)

Дата: 21.03.13 | Адрес: http://онкио.рф/articles/text.asp?id=639
Автор русского текста: Евгений Корнилов, специально для Онкио
По материалам сайта: iTunes | Onkyo Remote 2 / Open iTunes to buy and download apps

Onkyo Remote 2 от Onkyo Sound & Vision Corporation

Описание: Onkyo Remote Control App – официальное приложение от компании Onkyo под iPhone/iPod touch, позволяющее с легкостью управлять сетевыми AV-продуктами Onkyo. Приложение бесплатно и совместимо со всеми сетевыми AV-ресиверами Onkyo, а также с некоторыми другими сетевыми продуктами, выпущенными в 2010 году и позже.

Функции, осуществляемые Onkyo Remote 2
(1) Работа с Интернет-радио. Станции можно выбирать с сенсорного экрана, экран ТВ больше не нужен;
(2) Управление передачей аудиофайлов с DLNA-сервера. Вы можете выбирать музыку прямо с сервера с помощью своего iPhone/iPod touch;
(3) Общие функции дистанционного управления и воспроизведения;
(4) Изменение звука;
(5) Отображение различной информации при прослушивании радио, включая частоту станции (доступно только на продуктах со встроенным тюнером радио);
(6) Беспроводная передача музыки с iPod touch/iPhone (добавлена возможность воспроизведения музыки с совместимых моделей iPod touch/iPhone на сетевых AV-ресиверах 2012 года).
(7) Поддержка Spotify (в зависимости от региона)
(8) Поддержка файлов FLAC, DSD и Apple Lossless с помощью функции Home Media (зависит от модели)

Совместимые модели iPhone/iPod touch: iPhone 3GS и выше с iOS 5.0 и выше; iPod touch 3-го поколения и выше.

Совместимые продукты Onkyo:
• Модели 2012 года: все сетевые AV-ресиверы (TX-NR414 и выше), T-4070 и CR-N755.
• Модели 2011 года: все сетевые AV-ресиверы, выпущенные в 2011 году, сетевой стерео-ресивер TX-8050.
• Модели 2010 года: все сетевые AV-ресиверы, выпущенные в 2010 году.
(Для всех моделей необходимо обновление прошивки).

Наслаждайтесь новой степенью аудио-свободы с этим бесплатным приложением.

Новое в версии 1.50 (Updated: Mar 21, 2013 Size: 9.6 MB)

  1. Добавлена совместимость с AV-ресиверами 2013 года.
  2. Добавлена совместимость с iPhone5 и iPod touch 5-го поколения.

Onkyo Remote 2 для Android (ТРЕБУЕТСЯ ANDROID ВЕРСИИ 2.1 и выше)

Источник

Протокол 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 команд из этого документа. То есть как набор команд, так и допустимые параметры зависят от конкретного устройства.

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

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

    • 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, просто мизерный. В спецификации протокола нет ни слова о том, когда и при каких условиях плеер посылает ту или иную информацию. Поэтому здесь пришлось достаточно долго экспериментировать самому, чтобы мобильный клиент всегда имел всю необходимую информацию о текущем состоянии устройства.

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

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

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

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

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

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

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

      состояние и управление воспроизведением. Хочу обратить внимание, что сам плеер не поддерживает регулировку громкости. Поэтому кнопки управления громкостью будут работать, только если к плееру при помощи кабеля RI подключен внешний усилитель от Onkyo. Сообщения, которое позволяет проверить наличие такого подключения, к сожалению, нет.



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



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


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

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

    Источник

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Onkyo hf player для windows
  • Onext модем eg210u windows 7
  • Onenote что это за программа windows 7
  • Onenote не синхронизируется windows 10
  • Onekey theater windows 10 z580