(03-04-2016 22:52)Comandante писал(а): Поточный способ передачи - это один из способов передачи данных USB, который предусматривает договор между хостером и дискриптером о скорости или об объемах.
Правильно, но при балке обеспечивается контроль содержимого на приемной стороне, а при изохроне гарантируется только своевременность доставки без всяких гарантий по содержимому и алгоритмов исправления ошибок. Поэтому, что там вовремя (обязательно вовремя) доехало на самом деле ... Когда юсб-аудио соизволит перейти на балк, все эти вопросы снимутся.
Цитата:Какого х в 2м десятилетии 21 века через вывод звука по usb никто еще не реализовал простую коррекцию ошибок с проверкой четности. И все городят огороды с асинхроными режимами, джитеродавами, дорогими мифическими кабелями, дорогими разьемами и питаниями. когда все это нафиг ненужно
Таки оно УЖЕ не нужно.
Пользуем малахайку на основе, например, BeagleBone Black. Прямой I2S вывод с софтовоспециализированного миникомпа, с тактированием ОТ цапа, без всяких ЮСБ, спдифов и прочего. ЮСБ там, конечно, есть- но оно используется для считывания данных с носителя по "правильному протоколу".
(03-04-2016 23:04)onv писал(а): Правильно, но при балке обеспечивается контроль содержимого на приемной стороне, а при изохроне гарантируется только своевременность доставки без всяких гарантий по содержимому и алгоритмов исправления ошибок. Поэтому, что там вовремя (обязательно вовремя) доехало на самом деле ... Когда юсб-аудио соизволит перейти на балк, все эти вопросы снимутся.
Ну вы же знаете, что все как обычно контролирует хостер. Все содержится в трех основных пакетах отпраленных ним. Запрос - данные- подтверждение. Нет подтверждения, значит данные недошли или их целостность нарушена - ошибка, передача престановлена. Отправляется повторный пакет.
Контрольные суммы пакета данных проверяются и без пересчета новый отправлен не будет. Вот такой он упорото-настырный зараза
(03-04-2016 23:13)Wehr-wolf писал(а): Если уже допустили что ошибки могут быть, то каковы они на слух.
Кто гарантировано слышал ?
Ошибок на слух не бывает. Ошибка, это математическое действие из другой категории понимания. Цифры, это не меллодия. До ЦАПа. Дальше можно дискутивать.
(03-04-2016 23:11)Comandante писал(а): Отправляется повторный пакет.
Вы все верно говорите, но это справедливо только для балка. В изохроне "The data has a CRC as normal, but if the receiving side detects an error there is no resend mechanism."
Есть согласованная полоса пропускания, временное окно и объем, который обязательно в это окно нужно успеть протолкнуть. Все.
(03-04-2016 23:04)onv писал(а): Когда юсб-аудио соизволит перейти на балк, все эти вопросы снимутся.
хм. А что мешает разработчикам к примеру на уровне драйвера переключить в режим bulk, и (возможно) с соответствующим bulk чипом на усб приемнике?
Просто непонимаю, почему хитрые китайцы еще не смекнули. А вместо этого ибей завален всякими химерами типа usb>spdif на крутом асинхронном xmos которые кажутся просто мышиной возней а не решением вопроса.
Легкий пример, программы для "Поиска" или "Спекрума" на кассетах типа бейсика, игр всяких помните, прокрученные через магитофон они давали определенную мелодию, управляя скоростью лентопротяги я могу двумя тремя магнитофонами создать музыку из "ничего" значит ли это что цифра не музыка ?
Цитата:Ошибок на слух не бывает.
Царапины на диске CD ?
Цитата:это математическое действие из другой категории понимания.
Это математическое действие приводит к искажению восприятия ?
В чем оно выражается ?
Я имею в виду гипотетическое сравнение интерфейса SPDIF и современных веяний прямого считывания и прочее о чем пишут.
В чем выразилась итоговая разница этого перехода, что там ?
Мне просто хочется уяснить ажиотаж вокруг побитовой точности.
Другими словами, лучше стало, что именно, как выразилось, в каких величинах ?
(03-04-2016 23:27)onv писал(а): Вы все верно говорите, но это справедливо только для балка. В изохроне "The data has a CRC as normal, but if the receiving side detects an error there is no resend mechanism."
Есть согласованная полоса пропускания, временное окно и объем, который обязательно в это окно нужно успеть протолкнуть. Все.
Изохронный способ предусматривает управление передачей данных хостером. То есть, в пакете со служебной информацией отправляется набор управляющих команд для принимающий стороны если она не в состоянии корректировать свою работу с передающей. В этом заключается изохронный режим.
Опять же, все предусмотренно, что бы не потерялся ни один бит информации. Или они договариваются, в случае невохможности, хостер дает инструкции при соблюдении которых возможна передача данных.
(03-04-2016 23:40)Wehr-wolf писал(а): Царапины на диске CD ?
Царапины на диске исправляются без слышимых артефактов с помощью кода Рида-Соломона, который по ошибке приплели в этой теме. Там совсем другая история.
(03-04-2016 23:32)rix81 писал(а): хм. А что мешает разработчикам к примеру на уровне драйвера переключить в режим bulk, и (возможно) с соответствующим bulk чипом на усб приемнике?
Просто непонимаю, почему хитрые китайцы еще не смекнули. А вместо этого ибей завален всякими химерами типа usb>spdif на крутом асинхронном xmos которые кажутся просто мышиной возней а не решением вопроса.
Не всё там так просто с ХМОСом и прочими. Кроме канала передачи данных, есть ещё каналы interrupt and control. Так вот, по ним в ОБЕ стороны передается информация о наличии мастерклока, регулировки громкости и прочее. Вполне возможно, что предается и информация о совпадении контрольной суммы (а она в ЮСБ аудио отправляется на приемник, просто нет механизма переотправки кривого пакета). Дальше всё зависит от того, каким образом драйвера на это дело реагируют. Иначе, чем объяснить зависание или остановку воспроизведения в винде при нарушении приема аудиоданных? У меня такое было, когда ковырялся с ХМОСами. Как происходило? Очень просто- экспериментировал с согласующими резисторами- бусинами в цепях ЮСБ (ручки чесались с помехами "побороться"), в некоторых случаях дивайс спокойно определялся виндой, спокойно работал в сетках частот 44 и 96, а вот на 192 периодически вызывал зависание- остановку плеера. Причем, предварительно никаких щелчков и прочего, похожего на выпадение семплов- просто останавливалось вопроизведение- и всё. Подозреваю, на первом же пакете с несовпадением контрольной суммы драйвер дает команду на остановку воспроизведения.
Цитата:Царапины на диске исправляются без слышимых артефактов с помощью кода Рида-Соломона
Я использовал CD формат как ближайший аналог для примера.
Помню множество случаев когда CD плееры давали сбои и итог всегда был четко слышен сразу же.
Ведь тема затрагивает аудио.
Тогда в чем ключевой вопрос в теме побитовой точности ?
Выходит если не побитово точно то значит будет слышимая непоятоянная ошибка, и на слух ее можно услышать, или это уже из ряда выдумок ?
Я даже не знаю, если в аудио файле, в редакторе чуть двинуть всего одну точку отсчета какой то синусоиды, то это будет слышно в миксе, это да, это слышно. Но я хочу понять, в чем ажиотаж, есть ли уже примеры подтверждающие фактами необходимость того о чем говорят аудиофилы ?
(03-04-2016 23:56)Djem писал(а): Очень просто- экспериментировал с согласующими резисторами- бусинами в цепях ЮСБ (ручки чесались с помехами "побороться"), в некоторых случаях дивайс спокойно определялся виндой, спокойно работал в сетках частот 44 и 96, а вот на 192 периодически вызывал зависание- остановку плеера.
Может, автодетект по этим резисторам начинал рапортовать о низкоскоростной шине? Устройство-то продолжает быть видно, но драйвера, видя низкоскоростную шину и высокоскоростной поток, который в нее нужно отдать, могут просто клинить
В сотый раз одна и та же песня, цыхра, биты, прфекты.
Префект бит можно по телефонному модему передать, и даже на перфокартах.
По юсб кабелю передаются не файлы в цап, и не цифровые данные. А импульсно-кодо модулированный аудио сигнал, PCM поток. Там важна точная привязка во времени этих битов, а не точное их количество. Иначе все плееры бы играли одинаково, все кабеля, все порты, и все блоки питания компьютеров.
А теперь создадим ещё одну тему, как это префект битовый играет по разному, и все кабеля на цыхре одинаковые.)
(03-04-2016 23:56)Djem писал(а): Подозреваю, на первом же пакете с несовпадением контрольной суммы драйвер дает команду на остановку воспроизведения.
к сож наверное не так, во всех статьях пишут что основная задача протокола usb audio обепечить заданую пропускную способность в ущерб возможной целостности даты. Т.е абы звук шел.
А вобще реализация усб в произвольном устройстве может быть какой угодно рукожопости, особенно у китайских товарищей что все делают по гостам, особенно в ноутах
смешно наверное, что те товарищи которые писали здесь, забей, нафиг не нужна побитовая точность, сами слушают музыку в lossless : ) так оно ж нелогично.
Цитата:Иначе все плееры бы играли одинаково, все кабеля, все порты, и все блоки питания компьютеров.
Да, плееры программы действительно по разному играют, на то они и программы, их писали разные люди с разной логикой.
Порты одинаково выдают данные при идентичных программах и идентичных ОС, тут даже обсуждать нечего.
**** А теперь создадим ещё одну тему, как это префект битовый играет по разному, и все кабеля на цыхре одинаковые.)
Кабеля одинаковые естественно, одинаковыми их делает логика работы протокола и логика работы физического приемника и передатчика. На данный момент нет ни единого вразумительного доказательства звучания USB кабеля (кроме психоакустики и визуального восприятия).
(04-04-2016 01:13)Wehr-wolf писал(а): Да, плееры программы действительно по разному играют, на то они и программы что их писали разные люди.
Порты одинаково выдают данные при идентичных программах и идентичных ОС, дровах, как и кабеля, вообще кабеля легче всего проверить анализатором протоколов.
Вопрос связки всех элементов, как я понимаю звук можно уже ухудшить даже до ЦАП.
Играют по разному, но у всех бит префект. До одного места этот префект.
Данные выдают одинаково, а PCM потоки по разному. Я свой порт NEC, пару недель улучшал, с мат. платы слушать теперь не смог бы. Там на звук влияет всё.
Статья не обьясняет ничего для тех кто хочет понять что такое ошибка.
Там производители сошлись во мнении что ОНИ всеми своими усилиями не могут выяснить что происходит, а следовательно и измерить, потому как то что они измеряют имеет отношение к данным но не к звуку.
Я такие статьи читаю уже не первый раз, никто ничего не понимает, у каждого своя трактовка.
Нет фактических норм и порядков, разные пути якобы решения.
-------------
В статье говориться о ошибке.
Следовательно ошибка какой бы она ни была должна быть слышна, а теперь вопрос !
Может ли быть ошибка оговоренная во всем этом быть стационарно действующей величиной.
То есть, если я слушаю музыку и ничего, ошибок не слышу, артефактов тоже, то какой формы эти ошибки, что они ?
Кто гарантированно это опознает и как ?
К тому же, при переходе казалось бы на "бит в бит" производители кабелей хай энда в тот же час потеряют рынок сбыта, не так ли !?
Дело в том что бит то подтвержден в таком случае, следовательно цена кабеля уже может быть 5 уе, за обычный фирменный кабель для принтера !
Да и еще, из стаьи выходит что биты вы подтвердите ТОЧНО а округление сигнала никуда не денеться
Wehr-wolf, возможно, мой вывод будет дилетантским, но, если провести аналогию того, как слышны ошибки в чтении компакт-диска, и джиттер - а это резкий, плоский, стеклянный звук, который принято называть цифровым в худшем смысле, то ошибки при передаче сигнала по юсб тоже дают не перепутанные звуки ( ), а недоделанные: сцену, разборчивость, динамический диапазон и т.д.
Если предположить, что разные юсб-кабели в силу конструктивных особенностей доносят до приемника разное кол-во правильной информации, то поэтому и слышна разница в звучании кабелей, хотя это по сути слышен не кабель, а разное кол-во ошибок.
У меня есть свой звук, с блэкджеком и шлюхами!
Если ты вызываешь дождь, будь готов промочить ноги.
Что нужно сделать: В прикреплённом архиве - FLAC, который нужно проиграть чем-нить бит-перфектным через цифровой выход проверяемой ЗК на цифровой вход AV-ресивера. Если всё настроено правильно, ресивер будет играть музыку, а на дисплее напишет, что декодирует AC3
Что внутри FLAC: Внутри WAV, но "хитрый". Формат (заголовок и отсчёты данных) соответствует WAV с частотой дискретизации 48 КГц. Данные - не отсчёты PCM, а пакеты AC3. Имеем на это право, т.к. данные PCM это просто числа и могут быть любыми. Если надумаете послушать этот файл через обычный ЦАП, услышите ОЧЕНЬ громкое шипение.
Как это работает: Плеер, софтовый или "железный", декодирует FLAC, достаёт оттуда отсчёты PCM (он "думает" что это PCM) и отправляет их в ЦАП (в нашем случае - на выход SPDIF). Ресивер анализирует поступающие по SPDIF данные, по формату опознаёт пакеты AC3, декодирует и воспроизводит. Это если в тракте нет никаких обработок - регулировки громкости, фильтров, оверсемплера и т п. В противном случае структура пакетов AC3 нарушится и ресивер не сможет их декодировать.
На данный момент считаю, что если этот тест проходит, то в цепочке Хранилище файлов -> декодер FLAC -> плеер -> ЦАП -> выход SPDIF данные передаются без ошибок, т.е. "битперфектно".
Возможно, я что-нить проглядел, если что, "ткните".
Вдогонку: если бы при передаче данных по USB в моём тракте возникали ошибки, я бы не мог слушать DSD. Данные DSD у меня передаются в ЦАП в формате DoP
