Здравствуйте.

 

Звуковой движок плеера использует один поток и он обычно загружает ядро менее чем на 1%. Да и декодеры, за исключением DSD, однопотоковые. Поэтому увеличение числа поддерживаемых аппаратно потоков скорее всего ничего не даст.

Большое спасибо за быстрый ответ !! Жду с нетерпением вашего плеера на линукс в финальном варианте с подробным мануалом по установке и настройке!! дай вам бог сил и терпения со всем этим разобраться. удачи !!

...И кто энтот самозванец покашь пальцем.

Вы, уж, сами там разбирайтесь.

 

 

<br />Ну, вот я думаю, что здесь как раз виден смысл маломощныхх процессорах, где помехи не так велики<br />

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

Изменено 28 апреля, 20179 г пользователем PolarLight

С этой минимизацией буферов люди иногда не задумываются, что вообще происходит и почему.

Например, на dastereo.ru была ссылка на статью о том, как Jack изобрел свой способ бороться с джиттером:

http://kokkinizita.linuxaudio.org/papers/usingdll.pdf

Но если эту статью посмотреть, то обнаруживается, что Jack борется только с тем джиттером, который он сам создает, неравномерно передавая драйверу отдельные семплы. А если передать туда данные сравнительно большими блоками, как это делают обычно, то и причины этой нет. Получается, что пресловутая low latency, за которую Jack борется сугубо для realtime коммутации, оказывается генератором джиттера.

Я сторонник концепции, что чем меньше загружен процессор во время воспроизведения трека, тем лучше.

Я так же сторонник этой концепции. Но и про МП забывать не следует, а то можно все испортить. И не только это, все качественное "железо" - залог успеха.

Изменено 28 апреля, 20179 г пользователем Evgen1

С этой минимизацией буферов люди иногда не задумываются, что вообще происходит и почему. Например, на dastereo.ru была ссылка на статью о том, как Jack изобрел свой способ бороться с джиттером: http://kokkinizita.l...rs/usingdll.pdf Но если эту статью посмотреть, то обнаруживается, что Jack борется только с тем джиттером, который он сам создает, неравномерно передавая драйверу отдельные семплы. А если передать туда данные сравнительно большими блоками, как это делают обычно, то и причины этой нет. Получается, что пресловутая low latency, за которую Jack борется сугубо для realtime коммутации, оказывается генератором джиттера.

 

Вот читаю тему, после упоминания в ней Linux - просто цирк какой-то.

Вы хотя бы разобрались, как устроена сама система Linux и звуковая система начиная с первого варианта OSS.

Потом, вы что не читаете соседнюю ветку ? Там сайт http://kokkinizita.linuxaudio.org/ и статья упомянутая вами обсуждалась раз двадцать ....

Про джитер создоваемый Jack, это в корне не правильно.

Изменено 29 апреля, 20179 г пользователем ampir-nn

@ampir-nn,

Соседнюю тему я читаю, просто на эту статью перешел, просматривая тему на другом сайте. Что можете возразить по существу проблемы? Каким образом Jack может влиять на равномерность передачи семплов от ALSA драйвера в USB контроллер, если он работает до ALSA? Есть единственный вариант - если драйвер работает с минимизированным до нуля буфером и его реакция на прерывание, запрашивающее данные зависит от равномерности подкачки отдельных семплов от Jack. Но это ситуация по сути аномальная, так как буферизация в технике для того и придумана, чтобы не было таких проблем.

Обнаружил, что тестовый движок не корректно работает на частотах 176 и 192

На 176 показывает период и буфер 12 и 24, ЦАП при этом показывает частоту 96 и звук замедленный

На 192 заикается, хотя mpd у меня играет 192 с параметрами буфера: период - 24 и буффер - 48

@m@jor, меньшая частота может включаться, если не поддерживается аппаратно заданная или если для минимального буфера не хватает производительности. Для 192KHz может повысить устойчивость воспроизведения запуск с правами root (sudo ap или из терминала, перейдя в root). Там какое значение периода?

Для тех, кто затрудняется работать в Линукс , а послушать плеер Игоря очень интересно. Выкладываю образ ОС линукс https://yadi.sk/d/O4w7ABey3HUEae . Как с ним работать. Записываете образ, с помощью Rufus , на флешку(объемом 2 гб и более). Перегружаетесь, с заходом в биос, устанавливаете загрузку с этой флешки(важно), сохраняете эти изменения с выходом и все. Выбираете 1 или 4 пункт в меню загрузки и все система загрузится в ОЗУ. Подключаете нужные диски. Правой кнопкой по экрану, выбираете "открыть каталог от администратора", выбираете папку zip ( обязательно папку с архивом плеера, а не извлеченную папку плеера - это важно) с плеером Игоря и извлекаете его в системную папку usr. С этого каталога от администратора заходите в папку usr, открываете папку плеера и в этой папке открываете терминал и в терминале записываете команду ./aplayer и жмете Enter или ./ap если это будет плеер ap . Дальше из открытых папок выбираете свой муз.файл и жмете Enter. И слушаете музыку. И еще-очень важно: зайдите в параметры звука и отключите все устройства, кроме своей звуковой карты(цапа). Все, что рекомендовал Игорь, по настройкам, не делаем, в этой системе лишнее(создавать, отключать). Единственное нужно использовать индексы i или d , если надо. Их назначение, это разные выводы. Игорь писал выше. Счастливого всем прослушивания. В этом варианте очень важен объем ОЗУ, в некоторых случ. и 4 гб будет маловато. Попробуйте...

Изменено 29 апреля, 20179 г пользователем Evgen1

....Выкладываю образ ОС....

Спасибо. Оччень интересно.

Соседнюю тему я читаю, просто на эту статью перешел, просматривая тему на другом сайте. Что можете возразить по существу проблемы? Каким образом Jack может влиять на равномерность передачи семплов от ALSA драйвера в USB контроллер, если он работает до ALSA? Есть единственный вариант - если драйвер работает с минимизированным до нуля буфером и его реакция на прерывание, запрашивающее данные зависит от равномерности подкачки отдельных семплов от Jack. Но это ситуация по сути аномальная, так как буферизация в технике для того и придумана, чтобы не было таких проблем.

 

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

ALSA не что иное как набор драйверов и примитивный микшер с утилитами.

Например истема OSS4 в отличее ALSA намного лучше устроенна из за работы с памятью, качественным микшером и ресемплером, хотя сами драйвера почти на 100% одинаковы в всех системах Unix.

В FreeBSD звуковая система - это полный аналог OSS т. е. дальнейшее её развитие разработчиками FreeBSD, тоже намного лучше организованна чем звуковая система ALSA, она ближе к Coreaudio.

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

Jack работает с драйвером ALSA на самом низком уровне. Вот вывод конфигурации драйвера ALSA с помощью Jack:

 

JACK server starting in realtime mode with priority 99

creating alsa driver ... hw:Audiophile192,1|-|32|8|44100|0|0|nomon|swmeter|-|32bit

configuring for 44100Hz, period = 32 frames (0.7 ms), buffer = 8 periods

 

Я не спорю, возможно сконфигурировать систему с помощью плеера, но это очень сложно и долго, хотя можно взять часть кода из Jack ... но какой смысл привязовать всю звуковую систему к одному пусть и очень хорошему плееру.

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

Сделайте пожалуйста модуль вывода в Jack, как у всех аудио плееров, в дальнейшем ...

Изменено 29 апреля, 20179 г пользователем ampir-nn

m@jor, меньшая частота может включаться, если не поддерживается аппаратно заданная или если для минимального буфера не хватает производительности. Для 192KHz может повысить устойчивость воспроизведения запуск с правами root (sudo ap или из терминала, перейдя в root). Там какое значение периода?

 

Тут что то другое. Ибо:

1. Запускаю я через sudo. Прав хватает.

2. У меня ЦАП поддерживает всю линейку стандартных частот до 384 кГц

3. MPD у меня воспроизводит 176.4 кГц с параметрами period_size = 23, buffer_size = 69. Причём period_size выставляет драйвер сам, если в конфиге MPD задать period_time заведомо меньше возможного. А вот buffer_size приходится рассчитывать самостоятельно.

4. 192 кГц MPD воспроизводит с параметрами period_size = 24, buffer_size = 72 и более.

 

В общем MPD у меня воспроизводит 176 и 192 с минимальным периодом (23 и 24 семпла соответственно) и буфером равным 3 периода и более (можно не кратно). С буфером равным 2 периода - этих частот не воспроизводит.

Частоты 44, 48 MPD воспроизводит (как и Ваш движок) с периодом 8 и размером буфера ровно два периода или 3 и более

Частоты 88, 96 MPD воспроизводит (как и Ваш движок) с периодом 12 и размером буфера ровно два периода или 3 и более

С размером буфера больше двух и меньше трёх периодов MPD не работает. Наверно это как то связано с циклом работы буфера ALSA.

 

Ваш же движок при воспроизведении 176 кГц пишет

period_size - 12

period_size - 24

А это параметры для частот 88 или 96. И воспроизводит всё сильно замедленно. То есть на частоте 96 кГц. И на ЦАПе - 96 кГц.

Я это пишу не потому, что мне остро необходимо, чтобы тестовый движок заработал на этих частотах и буферах. А потому, что возможно в коде есть какая то ошибка. И лучше её выявить сейчас, пока она не закопалась или не растиражировалась. Ну и если вдруг Вы линию минимальных буферов будете прорабатывать, Вам пригодятся сведения по Amanero.

@m@jor, дело все-таки в том, что драйвер по запросу возвращает минимальную длительность периода, которая не для всех частот подходит. Вот устойчивый вариант для Amanero (64 разр.), где зашиты периоды 8, 23 , 24 для 44, 176 и 192KHz. Он играет 176.

ap.tar.gz

m@jor, дело все-таки в том, что драйвер по запросу возвращает минимальную длительность периода, которая не для всех частот подходит.

 

Независимую от samplerate? В семплах или в микросекундах?

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

 

Теперь 176400 воспроизводит с буфером 23/46

А на 192000 с буфером 24/48 уже почему то затыкается и захрюкивается. MPD ведет себя также. Да ну и фиг уже с ним. Цели добиться воспроизведения 192 не было.

На частотах 44, 48, 88, 96 всё работает нормально с буфером 8/16 и 12/24 соответственно.

А в MPD оставил себе buffer_time 545 µs. Это ровно три периода для частот кратных 44100. Для частот кратных 48 000 чуть три периода с хвостиком. Вроде и неплохо

Изменено 30 апреля, 20179 г пользователем m@jor

@m@jor, в API ALSA есть функции, задающие минимально допустимый период. Они должны быть адаптивны к samplerate. Ими я и пользовался. Но в любом случае в дальнейшем период будет настраиваться пользователем. Да и минимальный период, возможно, скорее фетиш, чем реальная польза для звука. Возможно, как и RT ядро. Я поставил Debian с RT ядром, но в звуке явных преимуществ не обнаружил. Зато загрузка процессора при воспроизведении вместо 0% на обычном ядре стала 7%.

Собственно, "последняя миля", когда аудиопоток отдается на USB шину USB контроллером, синхронизируется уже не софтом, а чисто аппаратно. С использованием все той же предварительной буферизации. И в отношении джиттера здесь, видимо, гораздо важнее стабильность клока на плате, чем версия ядра.

Прикрепленные файлы Прикрепленный файл ap.tar.gz 433.63К

Спасибо. Играет 24.192 , с буфером 24/72 . 384 еще не пробовал и DSD. Звук стал еще лучше, чем в первой версии.

 

с 32.... и 16.44.1 проблема выдает буфер 1/5 и все.....ноль.

Изменено 30 апреля, 20179 г пользователем Evgen1

@IgorA, По поводу синхронизации и буферизации при передаче аудио по USB: недавно заинтересовался этой темой и, по наводке участника одного известного аудио-форума, почитал спецификацию стандарта USB Audio. К своему большому удивлению обнаружил, что в данном случае используется только изохронная передача, не предполагающая контроль целостности данных и, судя по всему, буферизацию тоже. Теперь становится более понятным факт влияния качества USB-кабелей на звук (помимо влияния качества передачи питания по тому же кабелю). Про изохронную передачу можно подробнее почитать здесь: http://usb.fober.net/teoriya/Tipy-peredachi-dannyx/

Скажите, а в линуксе, вторая версия ар (мин. буфера) в режиме full mem. декодирует исходник в *.wav перед воспроизведением?

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

А на мой взгляд кабель в этой ситуации вторичен. От него мало что зависит, если он не слишком длинный и удовлетворяет спецификации. Считаю, что первичны USB контроллеры стоящие на выходе из источника и на входе ЦАПа. А кабель, кабель должен быть покороче и серебряный.

@IgorA, По поводу синхронизации и буферизации при передаче аудио по USB: недавно заинтересовался этой темой и, по наводке участника одного известного аудио-форума, почитал спецификацию стандарта USB Audio. К своему большому удивлению обнаружил, что в данном случае используется только изохронная передача, не предполагающая контроль целостности данных и, судя по всему, буферизацию тоже. Теперь становится более понятным факт влияния качества USB-кабелей на звук (помимо влияния качества передачи питания по тому же кабелю). Про изохронную передачу можно подробнее почитать здесь: http://usb.fober.net...redachi-dannyx/

Без буферизации передачи по стандартным интерфейсам не бывает. И при изохронной передаче по USB передаются фреймы, содержащие десятки байтов, и, естественно, эти фреймы предварительно буферизуются в контроллере USB и последовательность их передачи синхронизируется аппаратно. Что касается влияния кабелей на звук, то если бы при передаче сыпались биты, это был бы конкретный треск, а не влияние на окраску звука. Когда влияние есть, это скорее разная чувствительность к наводкам, влияющая на тот же джиттер.

 

Скажите, а в линуксе, вторая версия ар (мин. буфера) в режиме full mem. декодирует исходник в *.wav перед воспроизведением?

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

Игорь ! У меня последняя версия играет только 24.192 , все остальное, практически ноль. Но то, что играет - это очень хорошо, первая версия отдыхает.

Изменено 30 апреля, 20179 г пользователем Evgen1

Вот универсальный вариант ap с ручной регулировкой размеров периода и буфера. Выбранные настройки сохраняются и используются при следующих запусках.

В состоянии, когда нет воспроизведения, доступны команды

pf - размер периода в фреймах,

pt - размер периода в микросекундах,

bf - размер буфера в фреймах,

bt - размер буфера в микросекундах.

После команды без пробела вводится число, например

pf1024

- это период 1024 фрейма.

Для сброса на значение драйвера по умолчанию вводится -1 :

pf-1

ap.tar.gz

@IgorA, здравствуйте. В отсутствие в настоящее время усилителя, слушаю вторую версию АПлеера с подключёнными библиотеками на встроенном реалтеке. Настройки согласно Вашим рекомендациям. В качестве ОС актуальный Snakeoil.

 

При прослушивании треков wav 24-192, после перехода на сл. трек получаю сильное заикание на сильно замедленном воспроизведении. Выручает только ручное переключение через N, в этом случае трек воспроизводится нормально, но до следующего перехода.

wav 24-176 скорость воспроизведения завышена. После перехода на сл. трек, такое же заикание как и у 24-192.

wav 24-96 скорость воспроизведения экстремально высокая. После перехода на сл. трек, такое же заикание как и у 24-192. Только скорость воспроизведения с заиканием чуть выше.

wav 24-88,2 и 16-44,1 всё нормально.

Вот что значит встроенный реалтек.

 

Но, объективности ради хочу заметить, что родной плеер Snakeoil-а MPD (dsd-rt) воспроизводит все эти форматы корректно.