IgorA

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

@Дуст Включите (до запуска плеера) в панели настроек WASAPI (wasapi_x64_config.exe) опции конвертации в 24 бита.

Давайте конкретно разбираться. Вот ключевой тезис 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 проблемы системного времени только в том, чтобы вторая половина буфера драйвера с асинхронным чтением успевала заполняться раньше, чем будет передана на выход первая. Для этой задачи слежение за реальным временем также ничего не дает - делай всё по возможности быстро и с запасом по времени и никакие фазовые ошибки между прогнозируемым и реальным временем периода никакого влияния и отношения к результатам работы драйвера иметь не будут.

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

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

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

Суть то в том, что 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 при невыполнении этого условия - неизвестно. Что касается перехода на клок Джека при включении адаптивного ресемплинга - это факт.

Давайте, все вместе внимательно разберемся в смысле картинок, которые выложил (и далеко не в первый раз уже выкладывает) ampir-nnn выше на этой странице. Это очень важно для того, чтобы разум восторжествовал и победил мифологию, порождаемую безграмотностью вкупе с безответственностью. ampir-nnn использует компонент Zita-ajbridge, содержащий модуль zita-j2a. логи работы которого выложил выше на странице ampir-nnn. Как работает этот компонент? Он внедряется между JACK и драйвером ALSA как ещё один дополнительный посредник, включающий в себя ресемплер. Вот его внутренняя структура из статьи про Zita: Зачем в структуре этого модуля нужен еще какой-то ресемплер, если надо просто передать звуковой поток драйверу? Ответ на этот вопрос даётся уже в самом первом предложении статьи о Zita: Combining audio components that use incoherent sample clocks requires adaptive resampling - the exact ratio of the sample frequencies is not known a priori and may also drift slowly over time. This situation arises when using two audio cards that don’t have a common word clock. То есть, Джек раздает один поток на разные карты, которые неизбежно будут расходиться во времени воспроизведения больших блоков семплов, а их надо насильно подгонять к синхрону, создавая для них две версии раздваивающегося входного потока, каждая из которых адаптирована к соотношению входного клока и клока конкретной карты. За счет этого рассинхрон подавляется. Именно эту задачу решает адаптивный ресемплер в Zita. В качестве актуальной проблемы в статье отмечается то обстоятельство, что неравномерность получения данных о текущем времени воспроизведения в карте от драйвера ALSA приводит к погрешностям в подгонке потоков (ресемплинге, передискретизации), создавая аналог джиттера. Вот теперь внимание! Это и есть тот самый джиттер, с которым столь торжественно, пафосно борется ampir-nnn, демонстрируя всем свои достижения. То есть, это джиттер, создаваемый адаптивным ресемплингом. В Zita применяются определенные решения, чтобы его минимизировать. А вы еще не догадались, как побороть его более надежно, на 100% и навсегда? - Правильно! Вообще не использовать адаптивный ресемплинг, JACK в паре с Zita. Но следующий и главный вопрос - откуда берется тот общий клок, к которому подгоняет Zita все карты? Какая-то из карт становится главной, а другая подчиненной? Нет! В качестве точки отсчета объективного общего хода времени используется Jack’s microsecond timer. Именно время Джека становится в этой модели общей точкой отсчета, абсолютом, к которому надо подстраиваться. Представьте себе теперь весь драматизм ситуации: борьба за аудиофилию превращается во вредительство. Наиболее стабильный клок звуковой карты подменяется на клок Джека (программы), который задается генератором системной платы. И звуковой поток, передаваемый в карту, ресемплируется на основе данных от таймера Джека. Статья, которая это все описывает, вот (обратите внимание на красноречивое название статьи и имя файла): http://kokkinizita.l...dapt-resamp.pdf

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

Рустам, желание разобраться в сложных вопросах похвально. Вот только жаль, что из прежних обсуждений ничего в сознании не оседает, и как в фильме "День сурка" раз за разом надо начинать с начала. Вот это предложение, по концентрации это просто какой-то экстракт непонимания: При любом трансфере целочисленных данных нет никакой избирательности ошибок по отношению к младшему разряду данных. Это ведь не вычисления. Младший разряд находится точно в тех же условиях, что и старший разряд. Поэтому наличие даже редких случайных однобитовых ошибок при передаче аудиоданных неизбежно приводит к заметным щелчкам. Для современной техники такие ошибки - нонсенс, авария, эксклюзив. В исправных устройствах всё всегда у всех в норме передается без битовых ошибок в цифровом потоке данных. Джиттер, который портит звук без щелчков, не приводит к потерям битов. Это знают все, кто сколько-нибудь в теме. А Вы опять начинаете про биты. Далее, мои объяснения "паттернами" и "джиттером" - это не разные объяснения, это одно и то же объяснение. "Паттерны" - то есть, собственный рисунок программной активности, являются источником помех и наводок, порождающих джиттер. Нет другой версии, которая объясняла бы влияние компьютерного софта на внешний XMOS ЦАП, получающий поток данных из компьютера через два аппаратных асинхронных буфера, синхронизируемых собственными клоками - сначала выходной буфер контроллера USB, а потом буфер XMOS контроллера ЦАПа.

На рутреке в этой коллекции несколько хуже вариант, вроде бы. Вот трек 9 https://yadi.sk/d/eW-lZQms3Pibsc А какое еще объяснение влияния внешней цифровой активности на результат после асинхронного буфера может быть, кроме помех и наводок? Вы можете предложить другую версию?

Сергей, пауза в Linux версии отрабатывается замедленно (доигрывается уже заполненный буфер драйвера), чтобы не останавливать вывод и избежать возможных коммутационных щелчков при снятии с паузы. Насчет стабильности режима gapless позже я посмотрю. Возможно, потребуется добавлять и в Linux версию стандартный режим воспроизведения (под Windows только в нем gapless и работает). Своими сборками, пока софт в разработке, я не занимался. Плеер Squeezelite не смотрел.

-

@rustam0906 Что касается rt-ядра, то я слушал Debian с rt-ядром на нескольких треках. Я часто использую для тестов альбом Armik - Rain Dancer, WAV копии треков с CD. По моим впечатлениям звук был несколько более жестким и менее детальным, чем даже на обычном дистрибутиве Lubuntu. Что касается влияния на звук потребляемой мощности, то речь совсем не об этом, а о влиянии цифровой части воспроизводящего звук комплекса на процесс цифро-аналогового преобразования и в итоге на звук, который мы слышим. В теме про выбор ОС в сентябре это подробно обсуждалось. Странно, что Вы пропустили. Влияние это в случае bit-perfect вывода через интерфейс ASIO (да и ALSA), на мой взгляд, может быть только косвенным, порождаемым программной активностью и сопровождающими ее помехами и наводками. В то же время, в определенной конфигурации я получал достаточно наглядные спектрограммы влияния плееров на джиттер воспроизводимого сигнала и они на форуме выкладывались.

, сам факт влияния плееров на звук доказывает, что актуальными для восприятия могут быть ничтожные в общих масштабах вариации нагрузки на процессор. В том же интерфейсе ASIO драйвер жёстко задает формат и периодичность передачи ему данных. То есть, в "бутылочном горлышке" передачи данных драйверу ASIO все плееры обязаны совершенно одинаковые данные передавать одинаковыми порциями в одинаковом формате через одинаковые интервалы времени. И все исправные плееры так и делают. Единственное, что может при этом объективно отличать различные плееры - те же паттерны программной активности. Иного мне неизвестно. Если не они причина влияния, то что-то сверхъестественное. А дальше всё просто - нет активности, значит, нет влияния. Из этого исхожу, в этом направлении и действую.

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

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

@Urez Я думаю, для звука под Windows тоже нет необходимости в высокой производительности системы. Само железо может быть одним и тем же у Linux и Windows. Приблизиться, на мой взгляд, может минимизированный вариант Windows, в частности - Server Сore.

Моя философия проста и подтверждается, в том числе измерениями, которые я выкладывал: Лучшее, что может сделать компьютер для звука, это не навредить ему Те, кто пропагандирует rt-ядро, не пытаются даже задуматься, что оно делает и что это может дать звуку. По сути RT ядро разгоняет систему, ради минимизации времени на передачу управления программам с повышенным приоритетом, подобно тому, как разгоняют процессор в компьютере. В итоге существенно возрастает частота непроизводительных переключений процессора, что создает дополнительную нагрузку и снижает реальную производительность. В русском Wiki по Archlinux описание rt-ядра взяли из статьи Юрия Виденеева в журнале Хакер: Главное применение такой системы – промышленные и встроенные системы, но на обычном компьютере она тоже может быть интересна. Например тем, кто часто занимается обработкой звука и видео или постоянно грузит систему какими-нибудь ресурсоемкими вычислениями. Также есть положительный эффект от применения этого ядра на highload-серверах. Однако убрали последнее предложение заимствованного из статьи абзаца: Я же ничего, кроме слегка упавшей общей производительности системы, не заметил. Единственное, в чем может объективно помочь rt-ядро воспроизведению звука - это исключение прерываний звука при работе программ с малым буфером. Но и в этом случае существенно меньшей кровью обеспечить монопольное владение вычислительными ресурсами позволяет повышенный приоритет и захват ядра процессора, поддерживаемый некоторыми плеерами.

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

Из личного опыта. Коэффициент, используемый для пересчета целых в float диапазона -1...1 и обратно в разных программах может оказаться разным. Например, в известном японском ASIO плагине otachan для пересчета из float в 24-битовое целое используется константа-множитель FSCALER24 со значением 8388607. А в большинстве модулей, выдающих float на выход, для перевода 24-битовых целочисленных данных в float делят на константу 8388608. Соответственно, обратное преобразование становится неточным. В младших разрядах PCM этого обычно никто не заметит, но если в контейнере PCM передается DSD, то каждый бит становится важным и это расхождение порождает заметный шум.

Я пишу про многое, и про что-то привожу ссылки и цитаты. Какое из моих утверждений конкретно требует подтверждающей ссылки?

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

@rustam0906 Надо представлять, как кодируются числа в вычислительной технике. Плавающая точка нужна для вычислений над сигналом. Простой пример - надо найти средний уровень двух громких сигналов. Если они в целочисленном коде, то сложение двух чисел может привести к переполнению разрядной сетки и искажению результата. В плавающей точке отдельно хранится порядок результата и его диапазон допустимых значений очень велик. Поэтому переполнения не возникает. Сама максимальная точность по числу значащих цифр при этом остается равной 24 битам. И при делении решается проблема, например, по какой-то формуле для фильтрации значение семпла надо поделить на 10 и что-то потом с ним делать. В целочисленном представлении при делении младшие биты отбросятся, в плавающем - сохранятся, но попадут в дробную часть. Однако всё это актуально только при вычислениях, выполняемых над сигналом. Для просто воспроизведения ничего нового вычислять не надо. float формат при воспроизведении без DSP не требуется. На последнем шаге, при передаче драйверу, от float в любом случае надо избавляться. И когда float навязан как промежуточный формат, то удачный сценарий заключается в том, что 24 бита целочисленного исходника можно упаковать в float32, а потом симметричным преобразованием без потерь восстановить обратно.

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