m@jor

Я единственный, кто не догадался, что "Select Card" - это кнопка? Спасибо. Всё работает. И DSD тоже.

Попробовал. После выбора карты плеер делает вид, что настройки сохранил Но после перезапуска: "File asound.conf not found" и всегда 48 кГц Файла etc/asound.conf действительно нет Плеер запущен под рутом А почему у меня в mpd ничего "не вклинивается"?

Понял. Спасибо. Попробую.

Спасибо всем за участие. Но пока не обнаружил запущенного pulseaudio ни в моей "базовой" конфигурации (с mpd), ни после запуска aplayer. Файла /etc/asound.conf тоже не обнаружил. "Выбор карты" в веб-интерфейсе вроде не делал. У меня в списке всего две и обе - Amanero. Звук и так есть. Веб интерфейс сейчас не доступен - проверю вечером.

У меня DSD DoP играет. Проверил актуальную версию на двух разных ЦАПах. Регулятор громкости должен быть или отключен, или в положении 100 %. Может быть, Pulseaudio не отключен и влезает в сигнал. На вкладке Status какая поддерживаемая разрядность выводится? Регулятор громкости отключен. Как проверить наличие pusleaudio? В mpd.conf audio_output установлен на alsa и всё работает Разрядность - 32 Кстати все форматы выводятся в 48 кГц

PCM играет. DSD DoP не играет. Идет ровный писк с частотой килогерц 10 (может чуть больше). ЦАП при этом показывает 48 кГц

Кстати, уважаемый Игорь! Было бы офигенно интересно увидеть аналогичные "замеры спектров" для Вашего нового линуксового движка. Сравнительные с разными размерами буферов (в том числе и с экстремально малыми) и в сравнении с виндовым плеером. И спасибо за ссылку. Неожиданно. И очень познавательно.

Вроде я начинаю понимать Вашу парадигму. Если кратко, то понял так: 1. На звук после Ц/А преобразования влияет джиттер. С этим согласен. 2. Джиттер на входе ЦАПа порождается ИСКЛЮЧИТЕЛЬНО СВЧ-помехами, которые производит ЦПУ при "процессинге" звука. 3. Влияние этих помех столь значимо, потому что они синхронизированы с "процессингом". Надеюсь понял верно. К сожалению, я не силён в схемотехнике USB контроллеров и соответствующих плат вывода. Но ведь тактирование сигнала в них далеко от абсолютного идеала. Не является идеальным и тактирование сигнала на шине PCI. Вы не допускаете, что качество выходного цифрового сигнала всё таки может зависеть от того, что и как попадает в плату USB-вывода по шине? п. 3 - интересная гипотеза. Её сложно как доказать так и опровергнуть. Конечно, на первый взгляд, сомнительно, что "случайный" рёв может быть менее заметен, чем постоянный лёгкий шум. Но мозг действительно штука сложная...

При аппаратном тактировании передачи аудиопотока и заполненном на опережение буфере какой-либо возможности прямого программного влияния на процесс этой передачи данных нет. А косвенное влияние - через помехи и наводки, естественно, тем сильнее, чем "шумнее" процессинг. Что то у меня не стыкуется. 1. Мы же видим, что при уменьшении размера буфера возрастает частота АППАРАТНЫХ прерываний от карты вывода для заполнения этого буфера. Прерывания обрабатываются программно. Почему же нет программного влияния? 2. Если всё плохое только от помех, то не понятно зачем вообще вся эта возня вокруг программных плееров. Ведь сейчас оптимизируя "процессинг" в плеере Вы оказываете микроскопическое влияние на общий уровень помех. Гораздо эффективнее было бы просто убить операционку, оставив минимальный код. Не говоря уже о том, что уровнем СВЧ шумов гораздо эффективнее можно бороться за счет аппаратных решений. А можно ссылку, если не затруднит? Пролистать сотни страниц напряжно.

Встречается и такое. Но подобные "впечатления" можно и отфильтровать, если есть достаточное количество информации об "контексте" - кому на чём и что "послышалось". Лично у меня сейчас два основных "критерия" - точность построения сцены и близость звука инструментов к натуральному - "подобие оригиналу". Хотя и тут конечно есть элементы субъективизма. Это в том случае, если "тихость" и "минимизация процессинга" не порождает искажений иного рода, о которых я написал выше. Но если не порождает, то конечно благо. Но ведь те самые "шумы процессинга" могут быть достаточно успешно отделены от Ц/А-преобразователя. Хотя и временные дефекты сигнала тоже могут быть в определенной степени скорректированы...

Так ведь нагрузка на процессор, синхронизированная с процессингом звука, это и есть та самая единственная ось зла, которую я могу представить в качестве возможного источника косвенных влияний на воспроизведение в условиях bit perfect передачи данных и опережающей буферизации с собственным клоком. Если есть какие-то другие идеи, предлагайте пожалуйста. Не могу согласиться. Если бы СВЧ-шумы процессора были бы ЕДИНСТВЕННЫМ фактором влияющим на звук, то всё бы решалось именно минимизацией этого фактора - снижением частот, напряжения, применением "маломощных" ЦПУ, итп. Но мой очень скромный опыт и большое количество чужих впечатлений и опытов, озвученных в интернетах, говорит о том, что более быстрые (и как следствие более шумные) процессоры зачастую полезнее для звука. Поэтому, я предполагаю, что существует как минимум ещё один фактор, лежащий в где то областях временной стабильности и "правильности" цифрового потока. Тут мы имеем классический "тришкин кафтан". И в какую сторону тянуть - вероятно зависит от схемотехники конкретной подсистемы "источник - приёмник" и степени минимизации в ней того или иного фактора. Общий рецепт, наверное, тут придумать не возможно. Могу сказать за свой частный случай. В качестве приёмника в ЦАПе - Аманеро (модернизированный - с осцилляторами Crystek). Вроде тут полный хороший "собственный" клок со своим собственным питанием. Но Всё таки ноут с на Атоме от аккумулятора звучит хуже чем источник на Пентиуме на 3 ГГц (правда через SOtM). Даёт ли уменьшение буферов увеличение этой самой временной стабильности - отдельный вопрос. Лично у себя я пока не разобрался. В силу хорошего внутреннего клока ЦАПа (и наверное совсем не золотых ушей) у меня все эти "софтвые игрища" находятся на грани слышимости. А иногда и за ней.

А что в этом не хорошего (за исключением роста нагрузки на процессор)?

Спасибо за разъяснения. Расширение вопроса на "плееры вообще" случилось как то "само собой". Про медленный (в сравнении с ОЗУ) интерфейс, я как то забыл. Вопрос быстродействия памяти отпадает. Но вопрос оптимальной передачи блоков данных через медленный интерфейс (PCI или PCIe) вроде как остаётся. А вот тут, извините, чутка не понятно. При уменьшении размера буфера драйвера, увеличивается суммарное время работы обработчика соответствующего прерывания. Поскольку один цикл работы обработчика условно постоянный, значит соответственно растёт количество прерываний. То есть данные в контроллер поступают чаще и мелкими порциями. Или я что то не так понимаю?

Но Вы можете говорить только за свой плеер, верно? В другом плеере никто не запрещает "переварить" и сложить в буфер значительно больший кусок данных и потом его мелкими порциями выплёвывать в буфер драйвера? Соответственно, чем меньше блок, тем быстрее контроллер "устройства вывода" получит из медленного ОЗУ блок данных в ответ на прерывание. Верно? А не может ли это быть причиной проявляющейся в некоторых случаях зависимости качества звука от размера буфера? И нет ли тут причин использовать память с максимальным быстродействием?

Ваш ответ породил целую кучу вопросов. Видимо по причине недостатка знаний. Уж извините за любознательность и настойчивость. Но уж очень хочется разобраться. Вы имеете ввиду использование кэша L1 при процессинге данных внутри плеера? Но разве на процессинг внутри плеера будет влиять размер буфера драйвера устройства вывода? Я предполагал, что этот процессинг (и соответственно, использование кэшей ЦПУ) определяется исключительно кодом плеера, а размер буфера драйвера определяет только параметры передачи данных из плеера в драйвер. Правильно ли я понимаю, что использование DMA означает, что блок данных попадает из драйвера в контроллер только физически из ОЗУ? А из плеера в драйвер?