Album Player (Aplayer)

[BSV 35]

@IgorA, По этой логике на "чистоту" аудио-потока должна сильно влиять загрузка процессора в целом, а не только процессингом плеера. Но в реальности этого не наблюдается (по крайней мере в заметных масштабах). Думается, что дело все же не в электрических наводках, а в равномерности передачи потока данных драйверу.

[IgorA 1 949]

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

Изменено 20 июня, 2017 пользователем IgorA

[ampir-nn 121]

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

 

Это просто ваше мнение, ничем не обоснованное.

По вашим принципам, смартфон или корманный мп3 плеер - идеальный источник цифры.

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

А джитер всей системы влияет на звуковую систему, это факт .....

Софт плеер не может оказывать влияния на звук в правильно настоенной системе - тоже факт.

 

Неравномерность передачи потока данных драйверу поглощается уже на входе буфера драйвера и сопровождается равномерным считыванием из этого буфера по прерываниям от контроллера

 

А прерывания у вашего контроллера "равномерные" ? Вообще все что выше, каша из теории ....

[BSV 35]

@IgorA, Интересное предположение, не лишенное смысла. Если эту теорию удастся подтвердить научными методами, то думаю будет серьезное открытие в мире цифрового звука.

[IgorA 1 949]

Это просто ваше мнение, ничем не обоснованное.

Это азы информатики. Суть принципа буферизации.

По вашим принципам, смартфон или корманный мп3 плеер - идеальный источник цифры.

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

А джитер всей системы влияет на звуковую систему, это факт .....

Софт плеер не может оказывать влияния на звук в правильно настоенной системе - тоже факт.

Я-то как раз документировал влияние плееров на выходной сигнал с ЦАПа и прямо в этой теме весной картинки выкладывал.

В отличие Ваших сугубо умозрительных фантазий о влиянии на этот сигнал "джиттера всей системы".

Неравномерность передачи потока данных драйверу поглощается уже на входе буфера драйвера и сопровождается равномерным считыванием из этого буфера по прерываниям от контроллера

А прерывания у вашего контроллера "равномерные" ?

Да, прерывания у контроллера равномерные, поскольку синхронизируются аппаратно.

[BSV 35]

По вашим принципам, смартфон или корманный мп3 плеер - идеальный источник цифры.

Кстати, смартфон вполне может выступать в роли пусть не идеального, но очень хорошего источника цифры (проверено на практике). И в этом случае так же большое влияние на итоговый звук оказывает используемый программный плеер (по моим экспериментам наилучшие результаты показывает Onkyo HF Player). Причем оптимальное качество звука достигается в режиме полета, когда отключены все радио-модули, что подтверждает теорию о влиянии электромагнитных помех на цифровой аудио-поток.

[m@jor 10]

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

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

 

Что то у меня не стыкуется.

1. Мы же видим, что при уменьшении размера буфера возрастает частота АППАРАТНЫХ прерываний от карты вывода для заполнения этого буфера. Прерывания обрабатываются программно. Почему же нет программного влияния?

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

 

Я-то как раз документировал влияние плееров на выходной сигнал с ЦАПа и прямо в этой теме весной картинки выкладывал.

А можно ссылку, если не затруднит? Пролистать сотни страниц напряжно.

[IgorA 1 949]

Что то у меня не стыкуется.

1. Мы же видим, что при уменьшении размера буфера возрастает частота АППАРАТНЫХ прерываний от карты вывода для заполнения этого буфера. Прерывания обрабатываются программно. Почему же нет программного влияния?

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

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

И на это я конкретно вчера ответил в ответе BSV:

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

Я-то как раз документировал влияние плееров на выходной сигнал с ЦАПа и прямо в этой теме весной картинки выкладывал.

А можно ссылку, если не затруднит? Пролистать сотни страниц напряжно.

Вот:

http://forum.doctorh...525#entry947907

Ветка оказалась соседняя.

[m@jor 10]

Вроде я начинаю понимать Вашу парадигму. Если кратко, то понял так:

1. На звук после Ц/А преобразования влияет джиттер. С этим согласен.

2. Джиттер на входе ЦАПа порождается ИСКЛЮЧИТЕЛЬНО СВЧ-помехами, которые производит ЦПУ при "процессинге" звука.

3. Влияние этих помех столь значимо, потому что они синхронизированы с "процессингом".

Надеюсь понял верно.

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

п. 3 - интересная гипотеза. Её сложно как доказать так и опровергнуть. Конечно, на первый взгляд, сомнительно, что "случайный" рёв может быть менее заметен, чем постоянный лёгкий шум. Но мозг действительно штука сложная...

[m@jor 10]

Кстати, уважаемый Игорь!

Было бы офигенно интересно увидеть аналогичные "замеры спектров" для Вашего нового линуксового движка.

Сравнительные с разными размерами буферов (в том числе и с экстремально малыми) и в сравнении с виндовым плеером.

И спасибо за ссылку. Неожиданно. И очень познавательно.

[IgorA 1 949]

Вроде я начинаю понимать Вашу парадигму. Если кратко, то понял так:

1. На звук после Ц/А преобразования влияет джиттер. С этим согласен.

2. Джиттер на входе ЦАПа порождается ИСКЛЮЧИТЕЛЬНО СВЧ-помехами, которые производит ЦПУ при "процессинге" звука.

3. Влияние этих помех столь значимо, потому что они синхронизированы с "процессингом".

Надеюсь понял верно.

1. Остается надеяться, что основной вклад вносит джиттер на входе/выходе ЦАПа. Поскольку есть шанс какими-то способами его оценить. Хуже, если определенные паттерны помех влияют прямо на сигнальный процессор мозга.

2. В основном, видимо, да, но шине тоже могут пролезать помехи, в том числе, программно индуцированные.

3. Это какой-то шанс объяснить, почему влияние плееров заметно в столь шумном устройстве,

 

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

При передаче через S/PDIF это тоже может влиять на клок ЦАПа. В асинхронном USB не должно, пока биты не начнут теряться. А это уже щелчки.

[IgorA 1 949]

Кстати, уважаемый Игорь!

Было бы офигенно интересно увидеть аналогичные "замеры спектров" для Вашего нового линуксового движка.

Сравнительные с разными размерами буферов (в том числе и с экстремально малыми) и в сравнении с виндовым плеером.

И спасибо за ссылку. Неожиданно. И очень познавательно.

К измерениям я еще вернусь, но сейчас надо находить время для занятий самим плеером.

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

Изменено 20 июня, 2017 пользователем IgorA

[BSV 35]

@IgorA, Вынужден констатировать, что проблема с SACD в последней x64-сборке у меня все еще не решена. Только сейчас добрался до проверки на домашнем компе и результат таков: пересканирование папки с SACD ничего не дает. Но появилась новая информация о проблеме: добавление образа в плеер работает только при установленной галке "Full disc playback mode". При снятой же перетаскивание iso-файла из окна проводника на окно плеера приводит к его закрытию с завершением процесса APlayer.exe, но процесс ap2decoder.exe остается висеть в памяти. Это все проявляется под Windows 10 Enterprise x64. На рабочем ПК с Windows 7 Pro x64 все работает как часы. Причем звучание SACD заметно улучшилось по сравнению с предыдущими сборками.

Изменено 21 июня, 2017 пользователем BSV

[IgorA 1 949]

@BSV, в коде сканирования SACD дисков для потрекового режима была ошибка в операции с адресом памяти, которая может иногда приводить к аварии.

Проверьте пожалуйста вариант с исправлением (надо заменить файл in_sacd.dll в папке плеера):

in_sacd_x64.zip

[BSV 35]

@IgorA, Спасибо, вечером проверю.

[PilyaSega 75]

@IgorA, в конфигураторе плеера 2110 есть опция "Инвертировать фазу". Является ли это тем же, если я поменяю + на - в чашках наушниках?

[IgorA 1 949]

@PilyaSega, да, является.

[BSV 35]

@IgorA, Игорь, проверил исправленный вариант модуля in_sacd на машине с Windows 10. Все работает как положено, большое спасибо!)

Изменено 23 июня, 2017 пользователем BSV

[fenrirs 7]

Album Player очень порадовал, ничего лишнего даже со звуковухи

[BSV 35]

@fenrirs, Скажу больше: даже со встройки Realtek весьма прилично)

[ppy 5]

Игорь, Avira ложноположительно срабатывает на ap2decoder.exe.

06/24/2017,11-27-21 [iNFO] Файл "c:\ap2110-mini_x64\waveout\ap2decoder.exe" был просканирован с помощью Protection Cloud. SHA256 = 7523BC1700ECFF4DD4210E33F30B9E3A65F87DFD1435343885F242E700AFBE1A
06/24/2017,11-27-21 [iNFO] c:\ap2110-mini_x64\waveout\ap2decoder.exe
06/24/2017,11-27-21 [iNFO] [DETECTION] file contains 'HEUR/APC'

Сообщите им, как разработчик. А то эта инфа скоро по всем антивирусам расползётся.

 

Последнюю неделю плеер стал безбожно глючить и падать. Оказалось ,что антивирус периодически блокировал.

Изменено 24 июня, 2017 пользователем ppy

[AleXH 286]

А то эта инфа скоро по всем антивирусам расползётся.

Она не расползается, она появляется у "антивирусов", имеющих недостаточно толковый движок.

[IgorA 1 949]

@ppy, я отправил. Но на virustotal.com на этот файл 0/61 детектов, включая Avira.

[audioshock 1 391]

На аудио компе не должно быть ни антивирусов, ни других прог(офис, наприсем, браузер и пр.)

[kleymor.metal 4 776 4 Тракты]

На аудио компе не должно быть ни антивирусов, ни других прог(офис, наприсем, браузер и пр.)

Почему? А как музыку доставать без браузера?