Перейти к содержанию

Final Audio - Эмоции в каждом прослушивании

sale50feb.webp

komplekti_dec122024.webp

sale50feb.webp

friends_club.webp

sale50feb.webp

aurian_jan23.jpg

Рекомендуемые сообщения

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

,


Куплю Шипы Soundcare SuperSpike 2 SA (комплект 3 шт.)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Изменено пользователем 8street

TDA1541, KGSSHV Carbon, SR-009 and the music was electric

Продам Wa6Se maxxed.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

- "мощный" ЦП с частотой от 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.

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

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

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

Изменено пользователем AleXH

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

m@jor

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

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

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

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

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


Audio PC [GA-H170M-D3H, Skylake G4400, SOtM tX-USB+ЛБП, Snakeoil 0.9.2], L.K.S. Audio MH-DA003 USB Upgrade Edition, Audio Note P2SE, Tannoy D500, наушников НЕТ

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

  • Нравится 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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


Audio PC [GA-H170M-D3H, Skylake G4400, SOtM tX-USB+ЛБП, Snakeoil 0.9.2], L.K.S. Audio MH-DA003 USB Upgrade Edition, Audio Note P2SE, Tannoy D500, наушников НЕТ

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

  • Нравится 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

 

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

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

cD5I78WYQPiBcCwUBHFg5A.png

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

Изменено пользователем m@jor

Audio PC [GA-H170M-D3H, Skylake G4400, SOtM tX-USB+ЛБП, Snakeoil 0.9.2], L.K.S. Audio MH-DA003 USB Upgrade Edition, Audio Note P2SE, Tannoy D500, наушников НЕТ

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

m@jor

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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


Audio PC [GA-H170M-D3H, Skylake G4400, SOtM tX-USB+ЛБП, Snakeoil 0.9.2], L.K.S. Audio MH-DA003 USB Upgrade Edition, Audio Note P2SE, Tannoy D500, наушников НЕТ

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

  • Нравится 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

@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) - абсолютно те же симптомы...

Изменено пользователем BSV

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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


Audio PC [GA-H170M-D3H, Skylake G4400, SOtM tX-USB+ЛБП, Snakeoil 0.9.2], L.K.S. Audio MH-DA003 USB Upgrade Edition, Audio Note P2SE, Tannoy D500, наушников НЕТ

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Изменено пользователем IgorA
  • Нравится 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

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

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


Audio PC [GA-H170M-D3H, Skylake G4400, SOtM tX-USB+ЛБП, Snakeoil 0.9.2], L.K.S. Audio MH-DA003 USB Upgrade Edition, Audio Note P2SE, Tannoy D500, наушников НЕТ

Поделиться сообщением


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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти

  • Последние посетители   0 пользователей онлайн

    Ни одного зарегистрированного пользователя не просматривает данную страницу

×
×
  • Создать...

Важная информация

Пользуясь форумом вы соглашаетесь с нашими Условия использования.