Для DI и FM, я думаю, нет принципиальной разницы - 3 или 8MB кэш.

Игорь, раз немного отклонились в "железо", Ваше мнение касательно частоты ЦП, что предпочтительнее по Вашему для нашего дела:

- "мощный" ЦП с частотой от 3 Ггц, но которую задавили до, например, 800 Мгц

- тот же ЦП с частотой от 3 Ггц, которую не уменьшали

,

@IgorA, хотел попробовать новую версию, где полностью 64битные декодеры SACD. Опять столкнулся с тем, что образы SACD загружаются в Full memory по 10 минут. Использую конфигурацию SACD: вывод 176,4 кГц с FIR фильтром от S-audio, все это конвертится плеером в меньшую частоту 88,2кГц, поэтому времени занимает порядком! Почему я так слушаю - это отдельный разговор, но пользоваться плеером совершенно невозможно, когда SACD плагин работает с частотами выше 44кгц из-за времени загрузки. Можно как-то сделать, чтобы воспроизведение начиналось сразу же с загрузкой файла в память, как это было в 32битных приложениям? Тем более, я не выбирал "Полную предзагрузку" в настройках.

Изменено 15 июня, 20179 г пользователем 8street

Игорь, раз немного отклонились в "железо", Ваше мнение касательно частоты ЦП, что предпочтительнее по Вашему для нашего дела:

- "мощный" ЦП с частотой от 3 Ггц, но которую задавили до, например, 800 Мгц

- тот же ЦП с частотой от 3 Ггц, которую не уменьшали

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

@IgorA, хотел попробовать новую версию, где полностью 64битные декодеры SACD. Опять столкнулся с тем, что образы SACD загружаются в Full memory по 10 минут. Использую конфигурацию SACD: вывод 176,4 кГц с FIR фильтром от S-audio, все это конвертится плеером в меньшую частоту 88,2кГц, поэтому времени занимает порядком! Почему я так слушаю - это отдельный разговор, но пользоваться плеером совершенно невозможно, когда SACD плагин работает с частотами выше 44кгц из-за времени загрузки. Можно как-то сделать, чтобы воспроизведение начиналось сразу же с загрузкой файла в память, как это было в 32битных приложениям? Тем более, я не выбирал "Полную предзагрузку" в настройках.

Если в стандартном режиме вывода выбрать максимальный буфер предзагрузки, то работать будет подобно Full Memory - предзагружаться большими блоками, но играть будет сразу. В дальнейшем, скорее всего, в настройки добавится выбор режима загрузки диска целиком или по трекам. Впрочем, если начинать слушать с первого трека альбома, то и сейчас Full Memory x64 должен начинать играть сразу.

Спустя 2 недели экипаж станции (так они представились, sectorradio, видимо ушли в далёкий космос ) ответил:

Проблем с тегами в этих форматах нет (они в Vorbis-файлах называются

"Комментариями"). Проблемы возникают при обработке этих самых

комментариев в ретранслирующей среде IceCast.

Надеемся, что пробела будет решена в обозримом будущем, разработчиками

сторонних продуктов.

С нашей стороны все данные передаются корректно.

Изменено 16 июня, 20179 г пользователем AleXH

m@jor

Я имел ввиду кэш L1. Что касается прерываний от контроллера, то при передаче ему данных драйвером стандартным является использование DMA. В этом случае данные считываются из памяти, а не из кэша. Основной процессинг данных, скорее всего, происходит в контексте плеера и его потоков, включая работу кода ядра при приеме драйвером этих данных.

Ваш ответ породил целую кучу вопросов. Видимо по причине недостатка знаний. Уж извините за любознательность и настойчивость. Но уж очень хочется разобраться.

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

Правильно ли я понимаю, что использование DMA означает, что блок данных попадает из драйвера в контроллер только физически из ОЗУ?

А из плеера в драйвер?

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

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

При использовании DMA данные передаются только из ОЗУ. Из плеера в драйвер блок передается программно и кэширование работает.

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

Но Вы можете говорить только за свой плеер, верно? В другом плеере никто не запрещает "переварить" и сложить в буфер значительно больший кусок данных и потом его мелкими порциями выплёвывать в буфер драйвера?

 

При использовании DMA данные передаются только из ОЗУ.

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

Но Вы можете говорить только за свой плеер, верно? В другом плеере никто не запрещает "переварить" и сложить в буфер значительно больший кусок данных и потом его мелкими порциями выплёвывать в буфер драйвера?

Так и вопрос, с которого обсуждение началось, был задан о настройке буферов для этого плеера. В linux версии в DI весь процессинг синхронизирован с подкачкой этих блоков, а в FM вынесен во времени за рамки их передачи. В других плеерах собственный буфер тоже может регулироваться.

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

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

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

Спасибо за разъяснения.

Расширение вопроса на "плееры вообще" случилось как то "само собой".

Про медленный (в сравнении с ОЗУ) интерфейс, я как то забыл. Вопрос быстродействия памяти отпадает. Но вопрос оптимальной передачи блоков данных через медленный интерфейс (PCI или PCIe) вроде как остаётся.

 

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

А вот тут, извините, чутка не понятно. При уменьшении размера буфера драйвера, увеличивается суммарное время работы обработчика соответствующего прерывания.

Поскольку один цикл работы обработчика условно постоянный, значит соответственно растёт количество прерываний. То есть данные в контроллер поступают чаще и мелкими порциями. Или я что то не так понимаю?

Изменено 16 июня, 20179 г пользователем m@jor

m@jor

Видимо, только когда буфер драйвера становится меньше буфера контроллера (который и так небольшой - сотни байт), он начинает лимитировать размер передаваемого блока и возникает такая ситуация. Но по моим представлениям в этом нет ничего хорошего.

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

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

Так ведь нагрузка на процессор, синхронизированная с процессингом звука, это и есть та самая единственная ось зла, которую я могу представить в качестве возможного источника косвенных влияний на воспроизведение в условиях bit perfect передачи данных и опережающей буферизации с собственным клоком. Если есть какие-то другие идеи, предлагайте пожалуйста.

@IgorA, В последней версии AP x64 от 17.06 наблюдается следующая проблема: при использовании модифицированной двухканальной сборки approxy64 воспроизводится только первый трек многоканального SACD-диска (режим - Full Memory без полной предзагрузки и с выключенной опцией "Full disc playback mode"). Любой другой трек воспроизвести не удается с падением процесса approxy64.exe. Причем, если мы начали воспроизведение с первого трека, то падение approxy64.exe происходит после его полной буферизации. При ручном выборе, скажем, второго трека происходит довольно долгая буферизация без воспроизведения, после чего следует падение указанного процесса и пустой перебор всех оставшихся треков диска. Возможно, модифицированная сборка approxy64 нуждается в синхронизации с последними изменениями?

@BSV, да, ведь approxy64 обновлялся.

Попробуйте этот вариант.

approxy64_.zip

@IgorA, Спасибо за сборку, но и с этим вариантом, к сожалению, те же проблемы( Единственное замеченное изменение - после буферизации первого трека диска процесс approxy64.exe не падает, а просто завершает свою работу. Также попробовал другие режимы (стандартный с обоими вариантами опции "gapless mode" и direct input) - абсолютно те же симптомы...

Изменено 18 июня, 20179 г пользователем BSV

@BSV, а папки SACD были пересканированы после переключения опции "Full disc playback mode"?

@IgorA, Вот этот момент упустил... Спасибо за подсказку, попробую пересканировать.

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

Так ведь нагрузка на процессор, синхронизированная с процессингом звука, это и есть та самая единственная ось зла, которую я могу представить в качестве возможного источника косвенных влияний на воспроизведение в условиях bit perfect передачи данных и опережающей буферизации с собственным клоком. Если есть какие-то другие идеи, предлагайте пожалуйста.

 

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

Здесь еще есть вопрос по объективности самого ощущения лучше-хуже. Звук после эквалайзера часто лучше на слух, но хуже, если нас интересует подобие оригиналу. Кто сказал, что любого характера привнесенный в сигнал джиттер будет всегда восприниматься слушателем как "хуже", а не как более объемный и наполненный звук? У некоторых на слух и фубар всех обыгрывает по звуку. Я думаю, что в точных сравнительных измерениях соответствия копии оригиналу выиграют именно самые "тихие" варианты воспроизведения.

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

Изменено 19 июня, 20179 г пользователем IgorA

@IgorA, не могу запустить плеер в windows server 2016 без GUI, настройки открываются, есть проблемы с отображением галочек, но все видно и понятно, но сам плеер запускаться никак не хочет.

Чтобы плеер запускался, в ap2config надо отключить опцию "Управлять системной громкостью". Она не работает и плеер аварийно завершается, так как в Server 2016 Core нет службы Windows Audio.

@IgorA, На офисном компе пересканирование папки SACD помогло решить проблему!) Думаю, что и на домашнем должно помочь. Еще раз большое спасибо!

Здесь еще есть вопрос по объективности самого ощущения лучше-хуже. Звук после эквалайзера часто лучше на слух, но хуже, если нас интересует подобие оригиналу. Кто сказал, что любого характера привнесенный в сигнал джиттер будет всегда восприниматься слушателем как "хуже", а не как более объемный и наполненный звук?

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

 

Я думаю, что в точных сравнительных измерениях соответствия копии оригиналу выиграют именно самые "тихие" варианты воспроизведения.

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

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

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

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

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