Наверное, имеется ввиду, что на какой-то момент времени, один или более пакетов еще не успеют оказаться в приемнике, а для формирования аналогового сигнала они уже понадобились...
Такое могло ТЕОРЕТИЧЕСКИ быть при синхронной передаче, при асинхронной - просто невозможно. В нормальных условиях.

PnL, тут два момента.

Первый - пакет пришёл, да для ЦАП не преобразован вовремя. А ЦАП ждать не может, в отличие от ОС при записи в файл.

Второй - здесь.

При асинхронном USB, ЦАП решает что и когда ему посылать, чтобы обеспечить беспрерывный поток данных, а рассогласования по частоте нет как такового - тактируется все только ЦАПом. Вот если соединение хреновое и шнурок не обеспечивает доставку вовремя, то могут быть проблемы, но на практике, вероятность такого события в нормальных условиях и при исправных компонентах практически нулевая. Именно поэтому нет контроля ошибок. Вот при проигрывании CD в плеере, там уже на этапе считывания могут быть ошибки с достаточно высокой вероятностью, вот там должен быть контроль и исправление, но увы... а потому - только с винчестера.

Типы передачи данных.
Спецификация шины определяет четыре различных типа передачи (transfer type) данных для конечных точек:
_http://usb.fober.net/teoriya/Tipy-peredachi-dannyx/

"Изохронные передачи (Isochronous Transfers) - применяются для обмена данными в "реальном времени", когда на каждом временном интервале требуется передавать строго определенное количество данных, но доставка информации не гарантирована (передача данных ведется без повторения при сбоях, допускается потеря пакетов). Такие передачи занимают предварительно согласованную часть пропускной способности шины и имеют заданную задержку доставки. Изохронные передачи обычно используются в мультимедийных устройствах для передачи аудио- и видеоданных, например, цифровая передача голоса. Изохронные передачи разделяются по способу синхронизации конечных точек - источников или получателей данных - с системой. Различают асинхронный, синхронный и адаптивный классы устройств, каждому из которых соответствует свой тип канала USB.

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

наивысший приоритет имеют изохронные передачи;
после отработки всех изохронных передач система переходит к обслуживанию передач прерываний;
в последнюю очередь обслуживаются запросы на передачу массивов данных;
по истечении 90% указанного интервала хост автоматически переходит к обслуживанию запросов на передачу управляющих команд независимо от того, успел ли он полностью обслужить другие три списка или нет.
Выполнение этих правил гарантирует, что управляющим передачам всегда будет выделено не менее 10% пропускной способности шины USB. Если передача всех управляющих пакетов будет завершена до истечения выделенной для них доли интервала планирования, то оставшееся время будет использовано хостом для передач массивов данных. Таким образом:

изохронные передачи гарантированно получают 90% пропускной способности шины;
передачи прерываний занимают оставшуюся после изохронных операций часть этой 90-процентной доли;
под передачу данных большого объема выделяется все время, оставшееся после изохронных передач и передач прерываний (в рамках 90% доли пропускной способности);
управляющим передачам гарантируется 10% пропускной способности шины;
если передача всех управляющих пакетов будет завершена до завершения выделенного для них 10-процентного интервала, то оставшееся время будет использовано для передач данных большого объема."

PnL, данные по USB принимает XMOS процессор, а не ЦАП. На выходе XMOS данные будут идентичны переданным с источника, чтобы записать их в файл без привязки к реальному времени. В то время как данные, переданные от XMOS к ЦАП в реальном времени определяют звучание. Это же объясняет разное звучание USB кабелей в реальном времени, тогда как при записи в файл разницы нет. И это же объясняет разное звучание разных источников в реальном времени, тогда как при записи в файл разницы нет. До сих пор не понятно?

---

Почему XMOS процессор в этих случаях не справляется одинаковым образом (звук то - разный) есть разные теории. По одной из них - данные, передаваемые через USB кабель - это не TTL логика с чётким представлением передаваемого сигнала. А некий набор импульсов небольшого уровня со сглаженными фронтами, где процессору приходится нагружаться тем или иным образом для выделения из них обрабатываемого сигнала. Особенно критично это выходит при необходимости передавать данные в реальном времени. По крайней мере - это объясняет влияние кабеля и источника.

Сам себе поклялся сюда больше не писАть, но нет, не удержался, блин!

(13-09-2016 21:34)adsh писал(а):  ... На выходе XMOS данные будут идентичны переданным с источника, чтобы записать их в файл без привязки к реальному времени. В то время как данные, переданные от XMOS к ЦАП в реальном времени определяют звучание ...

Правильно ли я понял Вашу гипотезу? Вы предполагаете, что по USB отсчеты PCM идут без искажений, но (из-за свойств кабеля?) некоторые из них "запаздывают" так, что когда пора передавать очередной отсчет в ЦАП, он "ещё не приехал" и в ЦАП вместо него передаются "нули"/предыдущий отсчет/какая-то галиматья?
Если я неправильно понял, разъясните пожалуйста.

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

Некоторые авторы проводят параллели между вычислительной мощностью, загрузкой процессора источника и слышимым звуком. Так выходит и тут - чем больше загружен XMOS (плохой кабель и т. п.) - тем хуже звук.

ADSH вы про буферизацию слышали когда-нибудь?

(13-09-2016 22:21)АндрейКа писал(а):  Сам себе поклялся сюда больше не писАть, но нет, не удержался, блин!

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

(14-09-2016 06:11)dukua писал(а):  Меня вообще убила формулировка "запись в файл без привязки ко времени"

Если Вы делаете запись в ОС в файл, а система занята или диск занят, то система может ждать долго и нудно. Может даже стать колом и минуты не отвечать. Но, в конечном итоге, файл скорее всего будет записан без ошибок. В отличие от задач реального времени.

(14-09-2016 10:09)adsh писал(а):  Если Вы делаете запись в ОС в файл, а система занята или диск занят, то система может ждать долго и нудно. Может даже стать колом и минуты не отвечать. Но, в конечном итоге, файл скорее всего будет записан без ошибок. В отличие от задач реального времени.

Не может. Буфер переполнится и будет сбой.

(13-09-2016 22:44)adsh писал(а):  АндрейКа, что-то там деградирует в передаче данных в реальном времени от XMOS в ЦАП ...

Нет, не понимаю.
Давайте играть музыку через плату на XMOS c ЦАПом и цифровым выходом "на борту". ЦАП будем слушать, а цифровой выход подключим к цифровому входу какой-нить E-Mu. То, что она напринимает, будем писАть в файлы. 2 эксперимента с двумя кабелями USB, "хорошим" и "плохим". Если сравнить файлы, они совпадут, звук же с аналогового выхода при этом будет отличаться? Правильно ли я понял?

АндрейКа, именно так - задачка простейшая. В файлах всё сходится, в выводе с ЦАП - звук разный. Даже источник больше влияет, чем кабель. На лицо - деградация данных на участке XMOS - ЦАП. Разница лишь одна - вывод в E-Mu + ОС и в ЦАП. В чём разница между этими двумя вариантами - ЦАП требует реалтайм вывод, ОС же переварит всё, что угодно (в разумных пределах).

(14-09-2016 15:38)adsh писал(а):  .... На лицо - деградация данных на участке XMOS - ЦАП. Разница лишь одна - вывод в E-Mu + ОС и в ЦАП. В чём разница между этими двумя вариантами - ЦАП требует реалтайм вывод, ОС же переварит всё, что угодно ...

Не. Тот же самый отсчет одновременно подаётся в микросхему ЦАП и в передатчик SPDIF. Одновременно. И "одновременность" эту задаёт кварцевый генератор, очень точно. Запрашивает этот отсчет из очереди эндпоинта USB именно микросхема ЦАП. По крайней мере так оно должно работать в "асинхронном" режиме USB Audio. Т.е. если ЦАП запрашивает не вовремя или из пустой очереди, ошибочный отсчет попадёт и в ЦАП и в SPDIF, откуда в файл.
Если Вы имеете в виду, что отсчет на ЦАП приходит не вовремя, поясните пожалуйста, как это может произойти при тактировании от кварцевого генератора. Ибо я ничего придумать не могу.

USB Audio нормально музыку не воспроизведет, если это USB Audio устройство не комп, почти полностью дублирующий источник.

(14-09-2016 16:41)shiza писал(а):  USB Audio нормально музыку не воспроизведет, если это USB Audio устройство не комп, почти полностью дублирующий источник.

Какие Ваши доказательства? ©

(14-09-2016 16:41)shiza писал(а):  USB Audio нормально музыку не воспроизведет, если это USB Audio устройство не комп, почти полностью дублирующий источник.

Интересно Ваше мнение. Расшифруйте.

(14-09-2016 16:11)АндрейКа писал(а):  Если Вы имеете в виду, что отсчет на ЦАП приходит не вовремя, поясните пожалуйста, как это может произойти при тактировании от кварцевого генератора. Ибо я ничего придумать не могу.

А как контролёры различных устройств при перегрузки бывают какое-то время "висят"? Они то все тактируются кварцем...

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

Ещё раз объясню. Я исхожу из логической задачи. Есть у чипа два выхода - один из них идёт в ЦАП, второй - в E-Mu. ЦАП не может выдать на выход того, чего в нужный момент времени ещё нет. E-Mu - гипотетически может выдать "постфактум", ибо запись в файл не привязана к времени. И с ним всё сходится. В случае же ЦАП - результат выдачи хаотический. Объясните этот факт другим способом.

(14-09-2016 17:19)adsh писал(а):  ... ЦАП не может выдать на выход того, чего в нужный момент времени ещё нет ...

Пропуск отсчета? Если б они там были, то попали бы и на вход ЦАПа, и в SPDIF. Ну устроено оно так, что тот же самый отсчет по тому же самому стробу записывается в регистр ЦАПа и в передатчик SPDIF ! Чесс cлово, хоть бери и блок схему рисуй !

(14-09-2016 17:30)АндрейКа писал(а):  Чесс cлово, хоть бери и блок схему рисуй !

К сожалению, внешний вид схем не говорит какой звук .

Переповторов там быть не может? Чего-то недокументированного?

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

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