IgorA

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

Плееры делают float для JACK не так. Никакой dithering при этом не применяется. Они просто делят значение целого семпла на нормирующий в диапазон -1...1 коэффициент. Для 16-битных исходников это число 32768.0, для 24-битных - 8388608.0. А JACK перед передачей драйверу ALSA умножает обратно на этот коэффициент. Восстанавливает целочисленность. Естественно, звуку это последовательное деление и умножение в лучшем случае не вредит, но точно, что не помогает.

Если заинтересовал MPD, то вот фрагмент кода из его исходников, файл JackOutputPlugin.cxx (там для нас даже предусмотрели красноречивый комментарий) static void set_audioformat(JackOutput *jd, AudioFormat &audio_format) { ... /* JACK uses 32 bit float in the range [-1 .. 1] - just like MPD's SampleFormat::FLOAT*/ static_assert(jack_sample_size == sizeof(float), "Expected float32"); audio_format.format = SampleFormat::FLOAT; }

@rustam0906, double - это тоже формат с плавающей точкой, просто 64-битовый вместо 32-х. Поменять на него можно, если пересобирать JACK из исходников. Тогда будет JACK с 64-битным процессингом. Но и все клиентские приложения тогда должны будут собираться под эту версию и отдавать double. То, что распространяется в готовых пакетах, собрано под float32.

@rustam0906, Вы ошибаетесь. Обратите внимание в цитируемом тексте на: no "format negotiation". Это относится не к обработке внутри JACK, а к отсутствию согласования форматов для внешних приложений, поскольку вместо этого согласования им директивно задано отдавать в JACK flloat32 и ничего кроме. Я ведь не только первую страницу документации читал, но и смотрел программный интерфейс JACK для приложений (API). Там нет выбора формата для передачи данных, он задан как тип jack_default_audio_sample_t и является форматом с плавающей точкой. Поэтому, всё сказанное выше в силе: клиентское приложение может передать в JACK только float данные.

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

@rustam0906 Если плеер поддерживает вывод в JACK, он обязан уметь передавать выходной поток в float32. Иначе нельзя. На стартовой странице документации JACK сказано: There is no "format negotiation": all audio data within JACK is represented as 32 bit floating point values.

Микширование в цифре - это DSP, также JACK поддерживает ресемплинг (и это DSP). Почти. Как я выше уже отметил, JACK может принять от редактора или плеера только float. Фиксированные 32 бита ему передать невозможно. То, что нужно драйверу ALSA, всегда делает сам JACK.