@IgorA,

Суть то в том, что Zita сделана для адаптивного ресемплинга (смотрите все публикации о Zita, у которых это в названии) и его отключение переводит Zita в режим дополнительного буфера, ничего в джиттере не меняющего и бесполезного. Кстати в справке про опцию -S сказано, что она для случая, когда JACK тактируется одним клоком с картой:

 

The -S option disables resampling. This requires that the device is synced via word-clock to the one used by Jack.

 

Насколько корректно будет работать с этой опцией Zita при невыполнении этого условия - неизвестно.

 

Что касается перехода на клок Джека при включении адаптивного ресемплинга - это факт.

 

Вы пишите какие то свои выводы и доводы, ничем необоснованные. Для некоторых вы авторитет, вас читают и вам верят.

Что переходит на клок Jack? Неужели звуковая карта?

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

Изменено 16 ноября, 20178 г пользователем ampir-nnn

При включенном адаптивном ресемплинге в zita-j2a семплы, передаваемые в карту, корректируются так, чтобы воспроизводимый сигнал выровнялся по меткам времени, получаемым от JACK. То есть, если в карте время чуть медленнее, чем в таймере Джека, семплы для нее чуть ужимаются на шкале времени, если чуть быстрее, семплы чуть растягиваются. Это и есть адаптивный ресемплинг. Если темп времени источника чуть плавает, то в стабильную карту переносится эта нестабильность, поскольку источник - эталон, к которому подстраивается темп звучания. Зачем это делать? А иначе просто не синхронизировать две карты с отдельными кварцами. То есть, это плата за саму возможность синхронизации нескольких устройств.

<p>

При включенном адаптивном ресемплинге в zita-j2a семплы, передаваемые в карту, корректируются так, чтобы воспроизводимый сигнал выровнялся по меткам времени, получаемым от JACK. То есть, если в карте время чуть медленнее, чем в таймере Джека, семплы для нее чуть ужимаются на шкале времени, если чуть быстрее, семплы чуть растягиваются. Это и есть адаптивный ресемплинг. Если темп времени источника чуть плавает, то в стабильную карту переносится эта нестабильность, поскольку источник - эталон, к которому подстраивается темп звучания. Зачем это делать? А иначе просто не синхронизировать две карты с отдельными кварцами. То есть, это плата за саму возможность синхронизации нескольких устройств.

 

А причем здесь принцип работы zita-j2a, я использовал её как монитор фазы "источника".

 

Обсуждать принцип работы программы у меня нет желания, это к разработчику он наверное что-то не догоняет.

Fons Adriaensen, или ищите здесь, его доки http://kokkinizita.l...pers/index.html

Fons Adriaensen - звукорежиссер из Антверпена, Бельгия, в настоящее время проживающий в Парме, Италия.

Его основной интерес к Linux-аудио - это программное обеспечение для разработки и использование его как для частного, так и для профессионального использования.

Как разработчик, я часто писал вещи только потому, что я нуждался в них сам. Для записи классической музыки и пост-продакшн вы просто не можете идти на компромисс по техническому качеству. При работе с естественными звуками и очень широким динамическим диапазоном любые дефекты будут отображаться немедленно. Почти каждый раз, когда мне нужен эквалайзер, реверберация или динамический процессор, все плагины, которые я нашел, каким-то образом не сработали. Поэтому я написал свое собственное, обычно как приложение JACK, а не плагин. Между тем у меня есть довольно хорошая коллекция из них, но только некоторые из них были выпущены. Еще одна интересная область - акустические и звуковые измерения, а также математические алгоритмы «строительного блока», такие как повторная выборка или свертка, которые часто необходимы для реализации других.

http://libremusicpro...fons-adriaensen

 

Если темп времени источника чуть плавает, то в стабильную карту переносится эта нестабильность - я и показал как у источника, плавает. На разных ядрах и буфере. Как это исправить, дело хозяйское ..... Или вы думаете что XMOS PLL, микроконтроллер E-MU, DSP ЗК - все исправит

Изменено 16 ноября, 20178 г пользователем ampir-nnn

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

Осталось понять самую малость - //////////////////////////////////////////////

И что Вы там собрались мерять аналоговым частотомером, и главное - где, вот еще одна загадка для детей.

 

Читайте доки, экспериментируйте.

И причем здесь дети, и буфер ALSA, DMA ?

"синхронизируется аппаратно контроллером прямого доступа к памяти, никак не зависящем от этой фазы"

Давайте если будем, то так. Завернули умный словесный оборот - дали ссылку откуда это у вас. Ваши труды, лично для меня не показатель вашей гениальности как программиста и тем более как теоретика.

Изменено 16 ноября, 20178 г пользователем ampir-nnn

Дети к слову. А доки я читаю постоянно, как и экспериментирую. Чего и Вам...

 

Только осознанно, насколько получится.

Вы пишите какие то свои выводы и доводы, ничем необоснованные. Для некоторых вы авторитет, вас читают и вам верят.

ampir-nnn, приветствую. Игорь всегда, на все вопросы отвечает максимально развёрнуто, академически аргументировано, часто, как и положено, приводя ссылки на используемый материал, который изучил готовясь к ответу. В ответ,как правило, получает очередной "наводящий" вопрос типа "Столько текста, написать не разобравшись, и так везде ....." Ваша дискуссия очень интересная и поучительная для остальных, но хочется чтобы позиция второй стороны была максимально развёрнута и аргументирована.

Для начала например поясните, как Вы видите функционирование zita-j2a и в чём Ваше видение теории вопроса расходится с описанием Игоря. Спасибо.

 

Надеюсь на понимание.

С уважением, Юрий.

Можно попроще, я привел доказательства факта повышения стабильности фазы от простого ядра к RT ядру, от большего буфера к меньшему.

А к какому буферу и драйверу это привязано можно наверное опустить, есть сам факт. У меня даже станок ЧПУ от нормальной системы работает "ровнее".

И дабы не впадать в высокие материи.

 

@PolarLight

http://kokkinizita.linuxaudio.org/papers/adapt-resamp.pdf

http://kokkinizita.l...rs/usingdll.pdf

Я вижу функционирование zita-j2a так как описано на сайте разработчика.

Она была запущенна как индикатор, монитор - без своей основной функции

Я не собирался и не собираюсь обсуждать работу этой программы это займет еще 25 страниц, мне есть чем заняться, спасибо.

Изменено 16 ноября, 20178 г пользователем ampir-nnn

Давайте конкретно разбираться.

 

Вот ключевой тезис ampir-nnn:

 

"я привел доказательства факта повышения стабильности фазы от простого ядра к RT ядру"

 

Стабильность фазы чего именно повысилась и какое это имеет отношение к воспроизведению звука?

 

В документе про метод DLL по последней ссылке от ampir-nnn читаем:

 

New mechanism to obtain an accurate mapping between samples and system time was recently in troduced into JACK

 

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

А теперь, внимание, задумайтесь пожалуйста все - зачем нужно точное системное время программе воспроизведения звука?

Если время между семплами однозначно задается частотой дискретизации потока и больше ЦАПу ничего не надо знать про время,

чтобы корректно всё воспроизвести?

Правильный ответ - незачем.

Почему же тогда в статье это рассматривается как актуальная задача?

Ответ:

Потому, что это в самом деле актуально, но только для тех, кто занимается синхронизацией различных потоков.

В этом случае, да, их взаимный сдвиг во времени задает отклонение синхронизации от идеала и является минусом.

И именно он является фазовой ошибкой, о которой идет речь.

Почему этот фазовый сдвиг начинает волновать ampir-nnn и принимает какой-то ценностный смысл для него, сопровождаемый пропагандой этого решения в форуме?

Спрашивайте у ampir-nnn.

Мой ответ: от непонимания сути происходящего.

 

Что рассказано в статье про DLL по последней ссылке ampir-nnn?

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

Формулы в конце иллюстрируют следующее:

Банальное предсказание времени следующего блока - это число семплов в периоде поделить на частоту дискретизации.

Это идеальное время. Если например, период содержит 4410 семплов, а частота дискретизации - 44100, то время до следующего периода - 100 мс.

Реальный запрос на следующий период приходит в приложение с другой периодичностью.

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

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

 

Возвращаемся к исходному вопросу: зачем надо знать точные (реальные, а не вычисленные) интервалы до следующего периода и минимизировать ошибку их предсказания (ту самую loop error, которую измеряет и гордо демонстрирует всем ampir-nnn)?

Ответ: это важно для синхронизации потоков и адаптивного ресемплинга, поскольку точность ресемлинга определяется точностью информации о соотношении чуть различающихся клоков источника и приемника.

 

Другой вопрос:

Имеет ли это хоть какое-то отношение к проблемам качества воспроизведения звука?

Ответ: Нет, не имеет никакого отношения. Поскольку ЦАПу эти данные вообще не о чём, он работает с временем на основе заданной частоты дискретизации и собственного клока, а для драйвера ALSA проблемы системного времени только в том, чтобы вторая половина буфера драйвера с асинхронным чтением успевала заполняться раньше, чем будет передана на выход первая.

Для этой задачи слежение за реальным временем также ничего не дает - делай всё по возможности быстро и с запасом по времени и никакие фазовые ошибки между прогнозируемым и реальным временем периода никакого влияния и отношения к результатам работы драйвера иметь не будут.

Я мягко намекал, что JACK для воспроизведения аудио совершенно не нужен и что для этого достаточно ALSA, а удел JACK - проуадио.

Приветствую всех!

С разрешения Уважаемого Игоря, выдерну две его цитаты:

 

Возвращаемся к исходному вопросу: зачем надо ...

Ответ: это важно...

 

Мне кажется, что за этими интересными дебатами, все опять забыли основной посыл ампира - это стремление к идеальным цифрам! Любое стремление, которое не противоречит УК РФ похвально. Но, повторюсь, я уже не помню, где ампир говорит о том какие изменения у него происходят со звуком при всех этих "красивых" изменениях в измеряемых цифрах.

 

Так как самому все надо отслушивать, а не полагаться на голые цифры, то приведу свой опыт:

- поставил такую же цель как ампир, понизить латентность системы.

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

2. Включил в системе TSC - латентность уменьшилась (вернее таймер TSC был по умолчанию, попробовал HPET -стало хуже, вернул TSC)

3. Выставил в биос все параметры по дефолту - латентность упала до нуля, если не применять параметр -N в тесте cyclictest, ну, вы меня понимаете, про какие нули я говорю.

А теперь о звуке, о чем не говорит ампир: первые впечатления - ВАУ! динамика сумасшедшая (по сравнению с задавленным биос), энергетика сумасшедшая, ... но потом понимаешь, что это не музыка, это драйв, но не музыка. Резюме: для любителей "энергичных танцев" - это самое то. Для рока, металла, электронщины (тоже хорошая музыка) - это самое то (возможно...)

Но для мой музыки это не подходит, стал возвращать все "в зад", и на каждом этапе, естественно, все отслушивать.

Сразу финал: вернулся воздух, вернулась сцена, инструменты расставились по этой сцене. Одно из главных - между инструментами появился воздух.

Скажу так (это например для Юрия, который сейчас озабочен измерением латентности) - цифры, какие бы красивые они не были, не обеспечат (не всегда обеспечат) нужное вам SQ.

Совсем забыл про первый шаг на пути понижении латентности: заменил ядро на RT - латентность естественно уменьшилась.

Другой вопрос: Имеет ли это хоть какое-то отношение к проблемам качества воспроизведения звука? Ответ: Нет, не имеет никакого отношения. Поскольку ЦАПу эти данные вообще не о чём, он работает с временем на основе заданной частоты дискретизации и собственного клока, а для драйвера ALSA проблемы системного времени только в том, чтобы вторая половина буфера драйвера с асинхронным чтением успевала заполняться раньше, чем будет передана на выход первая. Для этой задачи слежение за реальным временем также ничего не дает - делай всё по возможности быстро и с запасом по времени и никакие фазовые ошибки между прогнозируемым и реальным временем периода никакого влияния и отношения к результатам работы драйвера иметь не будут.

 

 

Это имеет прямое отношение к проблемам качества воспроизведения.

Я хоть чего-то делаю и показываю.

От вас опять - ваши домыслы и фантазии, ничем не обоснованные.

 

Но, повторюсь, я уже не помню, где ампир говорит о том какие изменения у него происходят со звуком при всех этих "красивых" изменениях в измеряемых цифрах

 

Я не владею худ. свистом.

Изменено 17 ноября, 20178 г пользователем ampir-nnn

3. Выставил в биос все параметры по дефолту - латентность упала до нуля, если не применять параметр -N в тесте cyclictest, ну, вы меня понимаете, про какие нули я говорю. А теперь о звуке, о чем не говорит ампир: первые впечатления - ВАУ! динамика сумасшедшая (по сравнению с задавленным биос), энергетика сумасшедшая, ... но потом понимаешь, что это не музыка, это драйв, но не музыка. Резюме: для любителей "энергичных танцев" - это самое то. Для рока, металла, электронщины (тоже хорошая музыка) - это самое то (возможно...)

Это динамикой бы не назвал.

Звук становится скорее mp3'шный, чем динамичный. Жесткий, "цифровой". Уши в трубочку сворачиваются. Долго слушать не хочется.

Приветствую всех!

С разрешения Уважаемого Игоря, выдерну две его цитаты:

 

Возвращаемся к исходному вопросу: зачем надо ...

Ответ: это важно...

 

Мне кажется, что за этими интересными дебатами, все опять забыли основной посыл ампира - это стремление к идеальным цифрам! Любое стремление, которое не противоречит УК РФ похвально. Но, повторюсь, я уже не помню, где ампир говорит о том какие изменения у него происходят со звуком при всех этих "красивых" изменениях в измеряемых цифрах.

 

Так как самому все надо отслушивать, а не полагаться на голые цифры, то приведу свой опыт:

- поставил такую же цель как ампир, понизить латентность системы.

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

2. Включил в системе TSC - латентность уменьшилась (вернее таймер TSC был по умолчанию, попробовал HPET -стало хуже, вернул TSC)

3. Выставил в биос все параметры по дефолту - латентность упала до нуля, если не применять параметр -N в тесте cyclictest, ну, вы меня понимаете, про какие нули я говорю.

А теперь о звуке, о чем не говорит ампир: первые впечатления - ВАУ! динамика сумасшедшая (по сравнению с задавленным биос), энергетика сумасшедшая, ... но потом понимаешь, что это не музыка, это драйв, но не музыка. Резюме: для любителей "энергичных танцев" - это самое то. Для рока, металла, электронщины (тоже хорошая музыка) - это самое то (возможно...)

Но для мой музыки это не подходит, стал возвращать все "в зад", и на каждом этапе, естественно, все отслушивать.

Сразу финал: вернулся воздух, вернулась сцена, инструменты расставились по этой сцене. Одно из главных - между инструментами появился воздух.

Скажу так (это например для Юрия, который сейчас озабочен измерением латентности) - цифры, какие бы красивые они не были, не обеспечат (не всегда обеспечат) нужное вам SQ.

 

 

"Поверьте на слово" - почему не показать результаты, очень интересно увидеть как "латентность упала до нуля". Мне никак не удалось добиться <1.

Если выставить в БИОС все параметры по дефолту, результат будет обратный. Частота процессора и шины большой роли не играет, у меня частота процессора занижена на 30%. HPET в биос лучше отключить, так же ненужные устройства и все плюшки по питанию.

 

Вы предлагаете свои результаты и изменения в системе описать фразами вроде:

Сразу финал: вернулся воздух, вернулась сцена, инструменты расставились по этой сцене. Одно из главных - между инструментами появился воздух.

Как поверить в то, что это не мои "слуховые галлюцинации". Вы просто мне "Поверите на слово" , да ?

Изменено 17 ноября, 20178 г пользователем ampir-nnn

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

Это говорит о том, что у @audioshock достойная система (позволяет оценить разницу), а он в состоянии описать эти изменения (владеет художественным свистом).

 

Почему два усилителя мощности имеющие одинаковые технические характеристики отличаются друг от друга по звуку?

Почему КНИ в тысячные доли процента у УМЗЧ не является залогом хорошего звука?

 

Наверное потому, что не все можно описать цифрами, и придуманы еще не все критерии для оценки звука. Зато на слух разница заметна.

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

 

Это лишь мое мнение.

Изменено 17 ноября, 20178 г пользователем UNITRA

... почему не показать результаты, очень интересно увидеть как "латентность упала до нуля". Мне никак не удалось добиться <1.

Если выставить в БИОС все параметры по дефолту, результат будет обратный. Частота процессора и шины большой роли не играет, у меня частота процессора занижена на 30%. HPET в биос лучше отключить, так же ненужные устройства и все плюшки по питанию.

 

Вы предлагаете свои результаты и изменения в системе описать фразами вроде:

Сразу финал: вернулся воздух, вернулась сцена, инструменты расставились по этой сцене. Одно из главных - между инструментами появился воздух.

Как поверить в то, что это не мои "слуховые галлюцинации". Вы просто мне "Поверите на слово" , да ?

Ампир,

результаты показать можно, только хотелось бы разобраться в вашем тесте:

 

"Если выставить в БИОС все параметры по дефолту, результат будет обратный." - обратный чему? Повторюсь, у меня если выставить все по дефолту, т.е максимальные заводские параметры, то латентность минимальная. У вас что там за обратный результат?

 

"Частота процессора и шины большой роли не играет, у меня частота процессора занижена на 30%" - роли не играют, это о чем: о латентности или о SQ? Как раз роли играют и в том и в другом случае, см. предложение выше.

 

"Вы просто мне "Поверите на слово" , да ?" - верить не надо, я же всем желающим предложил повторить все это самим, там не сложно.

 

"HPET в биос лучше отключить" - для чего? Если хочешь снизить латентность, то лучше включить, если хочешь повысить SQ, то естественно выключить.

 

Теперь результаты: с трудом нашел какие-то скрины, в данном случае сравнивал Ubuntu и "хваленый" Debian 7

 

Вот это латентность на Debian

 

 

Вот это на Ubuntu

 

 

Но мне больше понравилась другая картинка...

 

Изменено 17 ноября, 20178 г пользователем audioshock

А куда делась тема про оси )))

Видимо, ее автор проверил, работает ли кнопка "Удалить тему".

Жаль, ....

А куда делась тема про оси )))

Тема про "оси" ушла на приватный форум тини, там автора темы ни кто не обижает , все только восторгаются .

Шутка конечно, про то, что здесь обижали, просто были критические высказывания, а они не всем нравятся.

 

На приватном форуме тини идет большое обсуждение разных систем и сборок, так что, если кто еще не определился - все туда!

Изменено 21 ноября, 20178 г пользователем audioshock

Жаль, ....

Ампир,

а почему Вам жаль, Вы хотели предложить какой-то свой законченный вариант операционной системы и плеера? Будем только рады. Можно в этой ветке, можете свою открыть, но не мне Вас учить, как это сделать.

...

Я немного подправлю свою высказывание выше: не "Тема про "оси" ушла...", а "тема про ось BAMF ушла...", т.к. Дима считал эту ветку ТОЛЬКО своей со всеми вытекающими последствиями.

Изменено 21 ноября, 20178 г пользователем audioshock

"Настройки операционной системы и БИОС, влияние этого на качество звука"

Подправьте название. зачем плодить темы, тем более здесь разговор уже давно вышел за рамки БИОС

Законченного варианта системы никогда не будет, наверное ни у кого.

"Настройки операционной системы и БИОС, влияние этого на качество звука"

Подправьте название. зачем плодить темы, тем более здесь разговор уже давно вышел за рамки БИОС

Законченного варианта системы никогда не будет, наверное ни у кого.

Законченных, т.е. готовых к употреблению систем и плееров достаточное кол-во, в исчезнувшей ветке их было предостаточно.

Так что, если есть что-то своё, милости просим.

Тему как подправить при условии, что от вас будет готовый продукт?

Присоединяюсь к просьбе @audioshock.

Многим было бы интересно послушать, но при наличии инсталлятора. Как в других законченных дистрибутивах.