Можно использовать временную конфигурацию с жесткой привязкой устройств к hw для проверки
В приведенной конфигурации по дефолту получается используется RK, а не usb. А что такое type asym? упс, уже нашел http://alsa.opensrc.org/Asym
Цитата:
Сообщение от HoSStiA
Запись короче исходной примерно на 0.5 сек, происходит потеря "фреймов". Что также видно, если следить за пиковыми амплитудами в начале записи.
ИМХО в эти 0,5 секунд в начале съедает Creative Audigy 2 NX, т.к. поток PCM детектируется не сразу (частоту, глубину), либо какая-то проблема буферизации. Для чистоты эксперимента надо сравнить побитово, взяв за "старт" одинаковые последовательности чуть дальше от начала. Могу сам сделать. Где там мой файлосравниватель..... :)
Цитата:
Сообщение от HoSStiA
На rk3066 наблюдались аналогичные проблемы именно при записи через USB-host, и их отсутствие при записи через USB-OTG.
:eek: это как? USB-Audio разве не host подразумевает? С одним только OTG (без поддержки USB-портом host) у нас уже получится Accessory Mode, когда хостом выступает юсб-цап, а android-девайс - рабской периферией, но этот режим стар и списан на пенсию. https://source.android.com/devices/audio/usb.html
---------- Сообщение добавлено 07.12.2015 в 23:43 ----------
пришлось поставить Audacity и вспомнить молодость :)
беглый анализ двух твоих дорожек дал понимание, что они различаются... барабанная дробь! частотой дискретизации! :laugh3:
то есть вернее, вторая, записанная через spdif дорожка потому короче оригинальной, что она попросту ускорена с соответствующим повышением частот (о чем свидетельствует сопоставление основных пиков частотного спектра дорожек), чему также свидетельством и соотношение длительностей полезного сигнала (разница 0,491сек). А вот виной может быть банальное воспроизведение дорожки с изначальной частотой 44.1 на "скорости" 48. Соотношение этих частот дискретизации получается в 0,01 приближении то же, что и длительностей, и пиковых частот спектрограммы, а именно 1,08-1,09. А также невооруженным глазом виден уменьшенный на 1,3дБ уровень громкости на записанной дорожке.
Вопчем, промашка вышла с технической чистотой записи по каким-то причинам. Разбираться надо, через что там звук шел.
Первое, что на ум приходит, это что воспроизводилось на 44.1 (рокчип её может :yes4: ), а записывалось в 48 герц (креатив только её и может :nea: )
08.12.2015, 01:38
HoSStiA
Вложений: 4
Цитата:
Сообщение от aluver
А также невооруженным глазом виден уменьшенный на 1,3дБ уровень громкости на записанной дорожке.
Цитата:
Сообщение от aluver
Первое, что на ум приходит, это что воспроизводилось на 44.1 (рокчип её может ), а записывалось в 48 герц (креатив только её и может )
Цитата:
Сообщение от aluver
Вопчем, промашка вышла с технической чистотой записи по каким-то причинам. Разбираться надо, через что там звук шел.
Creative пишет честно на 48kHz то, что ей приходит на SPDIF/In. В равных условиях, тот же оптический кабель. Без разницы, Windows или Linux. Вложение 908092Вложение 908094
Следовательно, не может без "танцев с бубном" именно сторона SoC RK, что печально.
Джиттер на столь малых промежутках также не успевает проявляеться, хотя о 100% совпадении говорить тоже рано - приходит все равно немного больше, чем отправлялось: Вложение 908098
:)
P.S.:
The Sony/Philips Digital Interface (SPDIF) timing is totally asynchronous, therefore there is no need for relationship with the clock.
Цитата:
Сообщение от aluver
это как? USB-Audio разве не host подразумевает? С одним только OTG (без поддержки USB-портом host) у нас уже получится Accessory Mode, когда хостом выступает юсб-цап, а android-девайс - рабской периферией, но этот режим стар и списан на пенсию. https://source.android.com/devices/audio/usb.html
Creative пишет честно на 48kHz то, что ей приходит на SPDIF/In. В равных условиях, тот же оптический кабель. Без разницы, Windows или Linux.
Следовательно, не может без "танцев с бубном" именно сторона SoC RK, что печально.
Предлагаю для первоначального "налаживания" контакта взять USB-DAC(SPDIF) и провести эксперимент с "прямым" воспроизведением без влияния андроида, а именно - посредством UAPP или другого аналогичного плеера, получить положительный результат, дабы быть уверенным в "железной" составляющей записи, а затем перейти к экспериментам с ядром.
Цитата:
Сообщение от HoSStiA
Джиттер на столь малых промежутках также не успевает проявляеться, хотя о 100% совпадении говорить тоже рано - приходит все равно немного больше, чем отправлялось
это могут быть и ошибки ресемплирования 48/44.1, пока о джиттере рано говорить, нужен "чистый" эксперимент.
Цитата:
Сообщение от HoSStiA
The Sony/Philips Digital Interface (SPDIF) timing is totally asynchronous, therefore there is no need for relationship with the clock.
правильнее сказать - самотактирующийся :) и relationship с клоком "на том конце" все же приходится иметь, и даже не отношения, а порой это уже переходит в определение "сношения" :D:D:D
а все из-за того, что ребята при разработке интерфейса лишний проводок зажали :D
ведь есть же I2S - замечательный интерфейс, где клок выделен в отдельную линию, и потому все при любой возможности используют именно его, а не SPDIF с его самотактированием.
Цитата:
Сообщение от HoSStiA
На уровне ядра Linux что-то не так, под Ubuntu-ARM ситуация полностью идентична включая rk3188.
говорю, надо провести "чистый" эксперимент. не должно так все плохо быть :)
тут не совсем понял, куда клонишь :)
во вложении - тест с Ubuntu?
08.12.2015, 22:29
rage2
Re: USB DAC и USB Audio для Android
Цитата:
Сообщение от rage2
Обновился UAPP до 2.2.9 , наконец то перестал лагать в проводнике локальной папки...сильно раздражало)
Беру свои слова обратно...всё равно тормозит.....вата...
Еще парни мне сказали, что он у них хуже играет чем Onkyo, сцена плывет аля "звук вокруг" ))
08.12.2015, 22:34
supermegauser
Re: USB DAC и USB Audio для Android
Цитата:
Сообщение от rage2
Беру свои слова обратно...всё равно тормозит.....вата...
Еще парни мне сказали, что он у них хуже играет чем Onkyo, сцена плывет аля "звук вокруг" ))
именно так! на старых версиях был немного ближе к онки, но сейчас г@вно!
08.12.2015, 22:50
rage2
Re: USB DAC и USB Audio для Android
Цитата:
Сообщение от HoSStiA
.... так как в USB могут сидеть старые "тараканы" от rk3066.....
Цитата:
Сообщение от aluver
:eek: это как?......
Да, с юсб у Рокчипа (rk3066\3188 точно) действительно не все так гладко... косяки c драйвером DWC USB. http://hwswbits.blogspot.com.es/2013...chip-socs.html http://www.freaktab.com/forum/develo...-dwc_otg-error
Например поэтому на нем USB EasyCap не работает.. USB UVC(вебкамеры) тоже могут не работать...и т.д. где нужна большая пропускная способность....
Вроде есть патчи на этот счет или ядра собранные из более свежих сорцов, где это пофиксили...
09.12.2015, 09:39
Shumik
Re: USB DAC и USB Audio для Android
Цитата:
Сообщение от supermegauser
именно так! на старых версиях был немного ближе к онки, но сейчас г@вно!
Я не пойму, у меня у одного Онкио вообще Сабру не видит? Не только на Китай-Г.У. но и на sgs4 и nexus 5.
09.12.2015, 10:01
Insomniac
Re: USB DAC и USB Audio для Android
Цитата:
Сообщение от rage2
Беру свои слова обратно...всё равно тормозит.....вата...
Еще парни мне сказали, что он у них хуже играет чем Onkyo, сцена плывет аля "звук вокруг" ))
А можно узнать что за парни? Случаем не Петр?
10.12.2015, 00:07
HoSStiA
Вложений: 14
Re: USB DAC и USB Audio для Android
Цитата:
Сообщение от aluver
говорю, надо провести "чистый" эксперимент. не должно так все плохо быть
Провел серию экспериментов.
При воспроизведении напрямую RKHDMISPDIF через ALSA страдает только битность, 16 bit => 24bit:
На данное преобразование у alsa_aplay уходит время, влекущее потерю порядка 580 семплов при старте воспроизведения. Но это не проблема для плееров с опережающей буферизацией и преобразованием в нужный формат. Аналогичная картина наблюдается и на Ubuntu при преобразовании из одного формата в другой командой aplay. Вложение 909638
Далее все проигрывается гладко, вплоть "до финальных аккордов". Вложение 909640Вложение 909642
Следовательно, с аппаратной частью rk3288 теперь больше ясности. 16bit/48KHz для этого SoC приемлемы.
Следующий момент - попытки командой alsa_aplay передать напрямую через S/PDIF-интерфейс поток 16bit/44.1KHz приводят к ошибке синхронизации
Цитата:
aplay: pcm_write:1604: write error: I/O error
Складывается впечатление, что Андроид знает как и пытается сформировать аудиопоток нужного формата (16bit/48kHz), но не успевает это делать "на лету".
Цитата:
Сообщение от aluver
Предлагаю для первоначального "налаживания" контакта взять USB-DAC(SPDIF) и провести эксперимент с "прямым" воспроизведением без влияния андроида, а именно - посредством UAPP или другого аналогичного плеера, получить положительный результат, дабы быть уверенным в "железной" составляющей записи, а затем перейти к экспериментам с ядром.
Вторая карта USB с S/PDIF (ASUS Xonar U3) категорически не хочет воспроизводить через Digital на Radxa с ядром 3.10.0. UAPP также этого сделать может. Вроде бы все распознается, S/PDIF активирован, воспроизведение идет, но на выходе нет сигнала. Нужна вторая карта, более совместимая с Linux и UAPP.
Под Ubuntu также не получилось воспроизвести через S/PDIF этого ASUS. Под Windows после установки новых драйверов ASUS и некоторой последовательности подключения Creative (перетыканий) одновременно с ней-таки удалось записать с USB-карты на USB-карту, но вдвоем + третья встроенная данная комбинация интерфейсов уживается очень плохо.
На rk3066 вроде бы это получалось с той же картой и с "патченным" ядром, но без этого ядра не удается активировать цифровой выход. А пересобирать пока нет времени.
Второй карты с S/PDIF-In тоже нету под рукой.
Цитата:
Сообщение от aluver
во вложении - тест с Ubuntu?
На Ubuntu все предсказуемо.
Это воспроизведение+запись командами aplay и arecord из разных терминалов: потребовалось конвертация S32_LE => S24_3, на что тоже ушло время, и часть семплов при старте потерялась: Вложение 909774Вложение 909780Вложение 909782