IgorA

Плееры делают 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.

@rustam0906 JACK работает с float32 аналогично тому, как фубар работает с входными плагинами (декодерами), то есть, он принимает от клиентских приложений только float32. Так задано в его спецификации. Поскольку в Red Book и большинстве hi-res оцифровок в исходных файлах целочисленные данные, то плеер, выводящий в JACK, предварительно пересчитывает эти входные данные в float32. Естественно, лучше от этого аудиоданные не становятся. При корректном обращении их можно обратно восстановить из float в integer, не более того. Что и делают перед любым выводом в драйвер и фубар, и JACK. Поскольку драйверы float не принимают. Эти трансформации в float и обратно при наличии DSP обработки передаваемого потока весьма разумны, но они совершенно лишние при ее отсутствии, и применяются в этом случае просто в силу универсальности рассчитанного на DSP интерфейса. Если осталось неясным, умеет ли JACK конвертировать форматы, то ответ - да. Без этого он не сможет работать, так как конвертирует их всегда.

Драйвер ALSA не принимает плавающую точку. При низкоуровневом выводе без посредников драйвер ALSA принимает один из трех целочисленных форматов - 16, 24, 32 бита. И по моему опыту обычно только один конкретный из трех. В современных картах и ЦАПах фактически всегда 32 или 24. Это очень похоже на работу ASIO под Windows. Поэтому последнее звено перед драйвером ALSA, будь то плеер или JACK, при прямом hardware выводе в ALSA обязано выдавать именно этот требуемый целочисленный формат. При микшировании JACK, видимо, использует плавающую точку, но нет смысла загонять Red Book в плавающую точку, чтобы потом его же извлекать оттуда. Если чем-то больше нравится трансфер через плавающую точку, то это скорее эффект косвенного влияния процессинга на звук. Вряд ли он имеет универсальное значение за рамками использования конкретных программ. dithering - тоже искажения, которые маскируют другие искажения, возникающие при усечении разрядности исходника. Если можно просто передать 16-битный поток бит в бит, этого достаточно и это объективно лучший вариант.

Вы сами задумайтесь пожалуйста о смысле своей аргументации. Если проблема только в том, чтобы без изменений донести биты из файла до ЦАПа, то любой фубар под любой Windows уже решает все проблемы. А сам плеер, да, конечно, и он тоже - промежуточное звено в конвейере звукового потока. А JACK - еще одно звено в этом конвейере.

По такой логике и любой lossless плеер - не промежуточное звено между файлом и драйвером. Раз пересылок данных становится больше, значит, промежуточное звено. Собственный буфер данных у JACK есть. В его программном интерфейсе (API) есть функция, задающая размер этого буфера: jack_set_buffer_size.

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

Не сам звук, конечно, но цифровой звуковой поток - да. Само название расшифровывается как Audio Connection Kit. Connection - соединение, коммутация. Странно после того, как столько копий сломано, возвращаться к вопросу, что такое JACK. На стартовой странице проекта JACK конкретно сказано, что задача этого продукта - коммутация: take the audio output of one piece of software and send it to another.

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

JACK - коммутатор + конфигуратор. Иного я нигде не утверждал.

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

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

@PolarLight Я думаю, что DOS позволяет получить предельный минимум загрузки процессора при воспроизведении звука (в противоположность тому, что делает сам ampir-nnn через JACK) и в этом смысле, да, DOS - идеальная ОС для звука на ПК. Но масса ограничений, связанных с отсутствием поддержки современных устройств, на мой взгляд, делает этот вариант неперспективным.

@PolarLight JACK позиционируется как инструмент realtime микширования и гибкой коммутации звуковых потоков. Именно в этом контексте очень актуальны минимально достижимые значения буферов. С качеством воспроизводимого звука никто это не увязывал. До ampir-nnn.

@Urez Место, видимо, да, не соответствует предмету, но вопрос этот скорее не ко мне. Я комментировал обсуждение, которое и без меня занимало всю предыдущую страницу.

@PolarLight Юрий, а что непонятно?

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

@ampir-nnn Даже когда Jack выводит через ASIO 3 семпла / 2 периода, он ничего не минует в "звуковой системе ASIO". Желательно это понять и не заменять знания мифологией.

Иначе говоря, он передает звуковой поток стороннему компоненту, который под Windows умеет выводить через ASIO, опять же, никак и ничего в ASIO не минуя. То есть, спрятаться от ASIO за еще одним дополнительным посредником, для Вас означает "миновать звуковую систему ASIO"? Что он при этом минует в некой упомянутой выше "звуковой системе ASIO", если она и сводится только к этому драйверу?

@ampir-nnn И всё-таки ответьте пожалуйста конкретно на вопрос, связанный с Вашим утверждением, сделанным выше - что именно минует JACK в "звуковой системе ASIO", когда он выводит через ASIO? Если имелся ввиду некий микшер, то где этот микшер в ASIO?