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 означает, что блок данных попадает из драйвера в контроллер только физически из ОЗУ? А из плеера в драйвер?

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

Если задать в семплах и period_size, и buffer_size как period_size * 3, то так и будет. Ну собственно я как раз и имел в виду, что задавать эти параметры в сэмплах (как в конфигураторе Джека) удобнее, чем в микросекундах (как это сделано у mpd). Только тогда получается, что всё таки эти параметры (как минимум period_size) будут разными для разных частот.

Но ведь при использовании в настройках интервалов времени "адаптивность" получается несколько кривоватая. Вот мой частный случай для минимальных рабочих значений значений period_time buffet_time пришлось брать как period_time*3. Имхо, было бы проще задать period_size в сэмплах (или получить минимальный от драйвера), а buffer_size задавать через множитель к period_size. То есть так, как это сделано в настройках Джека (параметры Frames/Period и Periods/Buffer) Я согласен с полной ненужностью Джека, как лишней прокладки, но, имхо, настройки у него сделаны более логично, чем в mpd (через задание времени).

В режиме FM играет как и предыдущая версия с достаточно маленькими буферами: 8, 12, 24 фрейма для частот 44/48, 88/96, 176/192 соответственно. bf=3*pf. При bf=2*pf иногда играет иногда нет. При pf=24 и bf=48 тоже играет всё. В режиме DI устанавливает period time чуть больше 5000 µs, pf - соответсвенно, bf - совсем большой

Стандартное поле для номера трека - вроде TRACK. Так что Ваши TRCK и ITRK не очень понятны. Возможно некоторые плееры отдают приоритет тегам ID3V1. MP3tag имеет настройки - какие теги (ID3V1 или ID3V2) читать/писать/удалять.

Однозначна! Однака, ещё важнее стабильность клока в USB-приёмнике ЦАПа Но это уже тема не этой темы

Независимую от 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 чуть три периода с хвостиком. Вроде и неплохо

Тут что то другое. Ибо: 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.

Обнаружил, что тестовый движок не корректно работает на частотах 176 и 192 На 176 показывает период и буфер 12 и 24, ЦАП при этом показывает частоту 96 и звук замедленный На 192 заикается, хотя mpd у меня играет 192 с параметрами буфера: период - 24 и буффер - 48

Всячески поддерживаю. Помниться с год назад я предлагал Игорю подумать над аналогичной идеей применительно к винде. Но там до фига сложностей. И фиг с ней. Мне вот тут не так давно довелось послушать KODI на Openelec. Так вот этот "видеоплеер" звучал чище и яснее, чем AVLinux с Клементинами, Джеками и кучей всяких ненужных приблуд. Это я к тому, что может стоит глянуть не в сторону монструозных дистрибутивов, коих великое множество, а в сторону так называемых Just enough operating system То есть ОС для запуска одного приложения. Или каких то иных минималистичных ОС типа упомянутого TinyCore. Я не спец по ОС, но имхо именно этот путь позволит получить максимальный результат.