Равно как при изменении величины буфера ASIO/WASAPI, верно?
Нет. С ASIO и WASAPI идет работа в стандартном режиме. Потеря данных при малом буфере - стандартная ошибочная ситуация.
Тем не менее, когда получаем fail при малом размере буфера и штатном файле известно, что это некорректная ситуация (буфер необходимо увеличить). Если тот же fail при измененной скорости воспроизведения - аналогично (мы знаем, что timeperfect нарушен изначально). И лишь при положительном результате возникает вопрос о причинах “некорректной работы”.
Заголовок контейнера (файл wav как раз им и является) существует только на стороне отправителя. На цап отправляется поток pcm-raw (headerless).
@pm325, могу только повториться. Не вижу в применении нештатных данных на штатной функции в данном случае перспективы получить результат, на котором будет возможность надежно базироваться с выводами.
Лично мне, логика @pm325 ясна и любопытна. В ЦАП уйдут те же биты, но быстрее. Любопытно, как на это отреагирует контроль битперфекта?
1 лайк
Проведите эксперимент и посмотрите что получится.
1 лайк
У меня нет ЦАПы с тестом битперфекта.
Купите.
Ок. Учту.
Чтобы разбавить ситуацию. Происходящее напоминает известный анекдот )
Купили как-то суровым сибирским лесорубам японскую бензопилу.
Собрались в кружок лесорубы, решили ее испытать.
Завели ее, подсунули ей деревце.
«Вжик» — сказала японская пила.
«У, бля…» — сказали лесорубы.
Подсунули ей деревце потолще. «Вж-ж-жик!» — сказала пила.
«Ух, бля!» — сказали лесорубы.
Подсунули ей толстенный кедр. «ВЖ-Ж-Ж-Ж-Ж-Ж-Ж-ЖИК!!!» — сказала пила.
«Ух ты, бля!!» — сказали лесорубы.
Подсунули ей железный лом. «КРЯК!» — сказала пила.
«Ага, бля!!!» — укоризненно сказали суровые сибирские лесорубы! И ушли рубить лес каменными топорами…
6 лайков
Павел, существует всего четыре варианта развития событий:
- положительный;
- отрицательный;
- ложно-отрицательный;
- ложно-положительный.
Насколько я понимаю, смущает возможность получения варианта #4. Не исключено, что он может быть достигнут лишь узком диапазоне изменения частоты (например, вместо 44100 выставить 44101 Hz).
1 лайк
quote=“pm325, post:51, topic:86077”]
Павел, существует всего четыре варианта развития событий:
- положительный;
- отрицательный;
- ложно-отрицательный;
- ложно-положительный.
Насколько я понимаю, смущает возможность получения варианта #4
[/quote]
Нет, мне не интересен эксперимент т.к. результатом будет 1+4 результат или 2+3 без различия и самое главное выводов надежных ни в одном из исходов нельзя будет делать исходя из результата.
Гораздо интереснее потратить время на то чтобы разбраться с вариантами событий последующей обработки кэша. Базовым подходом видится выбор устройств умеющих действительно асинхронно обрабатывать наполнение кэша и читать из него. Любопытно насколько штатная это фича в современных ЦАПах либо скорее удел продвинутых устройств. Для подобного варианта устройства не принципиален будет вопрос под экспериментом и еще 100500 потенциаьных заморочек с входящим потоком, если исходящий поток действительно асинхронен. (Возможны и свои проблемы в этом подходе безусловно, с задержкой относительно входящего потока например, но это уже другой пласт проблем).
Так можно сколько угодно придумывать. Может плохие подавальщики ещё и пукают оглушительно, аж пианист, бедолага, от испуга дёргается. Не суть.
Суть в том, что “битперфект” то есть кол-во и порядок бит это ещё не все. Помимо этого есть временной фактор и неизвестный нам фактор влияния того или иного софта на работу железа транспорта.
Мне лично кажется, что после достижения условного “битперфекта” влияние софта уже меньше, чем самого железа транспорта. Но это просто мнение, не более того.
Поправка: в условиях данного теста допустимые комбинации несколько иные - либо 1+3, либо 2+4.
Например, сетевой модуль eRED-MODE асинхронный “by design”.
Если же подразумевается режим Bulk Transfer mode, вопрос поднимался около 10 лет назад:
UPD: Adequacy of the Universal Serial Bus for real-time systems (2003)
По теме см. раздел 3.4 Transfer (page 10)
Select your USB audio MCU with care: Scary stories from the test bench
Придумывать стОит аналогии по только рассматриваемым мотивам. Собственно выше была иллюстрация момента, о котором сейчас речь: насколько by design современные ЦАПы вообще подвержены влиянию временного фактора входящего потока.
По поводу мнения “после достижения условного “битперфекта” влияние софта уже меньше, чем самого железа транспорта” - в целом согласен. Но несколько важных моментов:
- Влияние прикладного софта (аудиоплеера) практически нивелируется, ну разве что он криво настроен либо криво использует драйвер.
- А вот системный софт (драйвер USB, если про USB говорим) действует в одной команде с ЦАП и может потенциально влиять на результат.
- Если внутри ЦАП выходной поток действительно асинхронен входящему, вполне достаточно “битперфекта”, временной фактор входящего потока уже не интересен.
Не обязательно bulk, вопрос более общий - как обрабатывается исходящий из буфера поток. Хотя надо отметить, от при bulk режиме USB или допустим при передаче на вход по TCP/IP уже точно квазисинхронной передачи с наследованием временных проблем входного потока не получится )
Когда интересовался темой по режимам USB, помнится находил ресурс с огромной простыней ЦАПов и режимов USB которые они используют. Bulk попадался, но довольно маргинален был. С учетом например текущих результатов теста про bitperfect в целом не удивительно, судя по всему потоковые режимы также достаточно надежно работают.
Легкий утренний гуглинг по теме принес следующее саммари по теме:
- судя по всему утверждение “насколько мне известно, в большом количестве моделей используется просто ФАПЧ” касается работы с SPDIF
- если говорить про USB ситуация судя по всему обратная “The vast majority of DACs these days reclock the data so jitter on the USB signal does not matter.”
- в целом при асинхронной передаче данных нас не беспокоят временные проблемы входного потока “Asynchronous communication is defined as transmission of data without the use of an external clock signal.”
Если несколько упрощенно применительно к топику резюмировать - при использовании современного ЦАПа с компьютером, аудио-плееры играют одинаково, если обеспечивают передачу звуковых данных в ЦАП bitperfect.
1 лайк
Изохронный режим действительно применяется куда чаще по той простой причине, что он гарантирует заданную пропускную способность. Bulk обеспечивает полную асинхронность и повторную передачу битых пакетов, но требует более щадящих условий для аудио приложений, ибо это вотчина soft realtime.
1 лайк
Существует несколько режимов работы связки транспорт-приемник:
Не обязательно только SPDIF.
In a typical synchronous sink endpoint implementation, the source (host) and sink (device) agree on an operation audio sampling rate ( i.e., 48 kHz). Every one millisecond (for Full Speed, at Hi-Speed every 125 microseconds), the USB host sends the SOF signal followed by the agreed number of samples (48). The SOF signal acts as an input to the USB clock generator (typically a PLL), which in turn causes the USB device clock to synchronize with the USB. The USB clock is further used to generate the master clock to the codec through a PLL block that generates the I2S clock.
2 лайка