(09-11-2012 13:41)So Sensually писал(а):  Как раз в USB реализован не тупо линейным потоком как оптика или коаксил, а сложной геометрической структурой, позволяющей например при потерях на физическом уровне 1% терять 3% данных, при потерях 0.5% терять 0% данных. А коаксил и оптика при даже 0.1% на физ уровне испытает определенный % потерь данных.

Таки я все таки не понял...что вы тут хотели сказать? Что значит тупо линейный поток? А что значит сложная геометрическая структура? Поток чего? Структура чего?
USB это вообще то просто последовательный интерфейс , аналог COM порта, ему по большому счет все равно какие данные по нему ганяются....
Потрудитесь пожалуйста ваши мысли изъяснять яснее, кто на ком стоял? (с)

---

(09-11-2012 11:24)VladimirNB писал(а):  

(09-11-2012 10:57)So Sensually писал(а):  Если есть вопросы - задавайте.

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

Это интересный вопрос. Для начала надо залезть в сорсы usb-audio из ALSA и глянуть какого рода формат пакетов вообще используется для обмена данными с USB Audio устройствами, потом глянуть в спецификацию самого USB и глянуть какой там используется алгоритм кодирования сигнала (подозреваю что вариация манчестера какая нибуть но точно хз). В целом тут можно предположить что например как и в SPDIF канале, в синхронном режиме (! это важно) при высоком джиттере сигнала у нас херятся часть битов во фрейме , например в SPDIF обычно херятся биты кодирующие ВЧ составляющую сигнала, именно поэтому при выскомо джиттере обычно страдают всякие тарелочки и тд.
...А и еще такой момент, совсем не цифровой - у нас же USB может работать как антенна, ловить какие то наводки, в тех же проводниках питания - в итоге все зависит в качество схемотехники самого USB приемника, неизвестно как эти помехи по питанию могут повлиять на его работу

PS: Это все теория, и ИМХО, но на выходных все таки попробую сорсы ALSA поковырть, глянуть формат пакетов.

---

(09-11-2012 12:09)smirnofb писал(а):  Дополню, для популярности:
Перед копированием данных с одного цифрового носителя на другой, на копируемом носителе сразу же резервируется место идентичное копируемому. После запроса, сверяются копируемые и скопированные, при их совпадении копирование завершено успешно. Это наглядно демонстрируется на примере, когда вы собираетесь скопировать что то , например с флешки, ОС сообщает, что недостаточно места. То есть, резервируя место для передаваемых данных, ОС сверяет объемы.
Поэтому, при передаче пакетов - данные не теряются, это верно.

Нет не сразу же, иначе бы при например копировании 4Гб файла, у вас на носителе сразу же бы свободное место уменьшилось на 4Гб, однако это не так, место выделяется уже в процессе копирования. То что вам ОС (или правильней все таки ваш файловый менеджер/командная оболочка) сообщает при копировании файла о том что на приемнике не достаточно места - это всеголишь ее удобная функция, она просто глянула обьем файла, и глянула обьем свободного места на носитиле, но не более того, на уровен API ядра ничего такого нету.
И да сами данные не сравниваются, сравниваются либо контрольные суммы, либо контроль четности, либо сравнение с использованием какойто хеш-функции (смотря на каком уровне смотреть и какой софт юзать)
...люблю я попридератся к деталям да

(09-11-2012 14:48)rraist писал(а):  Нет не сразу же, иначе бы при например копировании 4Гб файла, у вас на носителе сразу же бы свободное место уменьшилось на 4Гб, однако это не так, место выделяется уже в процессе копирования. То что вам ОС (или правильней все таки ваш файловый менеджер/командная оболочка) сообщает при копировании файла о том что на приемнике не достаточно места - это всеголишь ее удобная функция, она просто глянула обьем файла, и глянула обьем свободного места на носитиле, но не более того, на уровен API ядра ничего такого нету.
И да сами данные не сравниваются, сравниваются либо контрольные суммы, либо контроль четности, либо сравнение с использованием какойто хеш-функции (смотря на каком уровне смотреть и какой софт юзать)
...люблю я попридератся к деталям да

Если вы знакомы с процессом резервирования дискового пространства, то вы должны были знать - что(!) Начало процесса лежит в оценке необходимого объема, следующий этап - само физическое резервирование. Но вы определили это как - резервирование в процессе копирования потому - что(!) вы не можете сразу увидеть, что какая то его часть уже зарезервирована, система об этом не сообщает. Вы не можете одновременно с копированием, увидеть в свойствах - что(!) эта часть уже занята под копирование. Вы видите только как увеличивается в объеме зарезервированные под этот объем - файл или папка.

ЗЫ. ну как я умею придираться к мелочам?
Придирается по настоящему тот - кто придирается последний

So Sensually
Почитал Ваши прошаренные объяснения, озадачился....
Итак по порядку:

"При воспроизведении контейнер распаковывается и цифровая информация размещенная в нем превращается в цифровой поток, на этом этапе уже не возможна проверка и последующая повторная доотправка потерянных данных, это слишком медленно, так мы вообще ничего не увидим и не услышим. Так вот поток, распакованный алгоритмами ЦП нашего компьютера из ОЗУ по шине материнки отправляется на USB интерфейс, далее на USB кабель и на ЦАП. Здесь и идут коласальные потери цифрового потока! "

Тут же вопрос, что скажете про асинхронный режим передачи данных?
Что для Вас "колосальные потери" - отсутствие потока, трески, сбои или смещение фронтов и охренненый джиттер?

Далее:
"Вы спросить почему контейнер mp3 или другой с "потерями" - теряет в качестве? Рассказываю. Поскольку потери в методах кодирования данных, на самом этапе кодирования, а не на этапе передаче данных. Есть мнения что человеческое ухо слышит весьма ограниченный диапазон частот, а так же раньше носители были емкие. Не было всяких террабайтов, а запаковать полный спектр частот - займет куда больший объем на носителе. Только по этом причинам существуют контейнеры с "потерями" (которые кстати на мой слух звучат хуже форматов "без потерь"."
Это откровение Только не ясно к чему тут мп3?!

"Вы спросите, а вот чему USB кабель такой дешевый? Дешевле чем оптические или коаксильные, какой из них лучше, спросите вы меня? Отвечаю. Лучше USB.Это на много порядков более сложный и технологичный кабель. Его проводники создают геометрический массив данных. Тут начинается действительно сложное объяснение которое я не готов дать, но могу только сказать что то что аудиофильские конторы наконец-таки соизволили обратиться к ИТ технологиям - огромный подарок аудиофилам. USB один из лучших когда-либо созданных человеком интерфейсов. Несмотря на такое гигантское распространение и выпиющую дешевизну. Ведь все дешевое обычно унылое - думаем мы, но это оказывается не так."

Дешевый говорите?.....

AudioQuest Diamond USB Cable
Ridge Street Audio Designs Poiema
WireWorld Platinum Starlight
Telos Gold Reference USB Cable
Nordost Blue Heaven USB Cable
WestministerLab USB Cable
Acoustic Revive USB-1.0SP/USB-5.0PL
Siltech Classic Anniversary USB Cable NEW G7 1.0M Type A / Type B
Locus Design Group Axis USB-A to USB-B

и причем здесь лучше, хуже?, все зависит от конкретной реализации цифрового тракта, будем выводить цифру из классной карточки хорошей оптикой или коаксиалом или кошерным юсб кабелем через посредственный юсб-спдиф конвертер, как думаете будет ли в выигрыше вариант с дорогим юсб кабелем?

(09-11-2012 15:29)smirnofb писал(а):  

(09-11-2012 14:48)rraist писал(а):  Нет не сразу же, иначе бы при например копировании 4Гб файла, у вас на носителе сразу же бы свободное место уменьшилось на 4Гб, однако это не так, место выделяется уже в процессе копирования. То что вам ОС (или правильней все таки ваш файловый менеджер/командная оболочка) сообщает при копировании файла о том что на приемнике не достаточно места - это всеголишь ее удобная функция, она просто глянула обьем файла, и глянула обьем свободного места на носитиле, но не более того, на уровен API ядра ничего такого нету.
И да сами данные не сравниваются, сравниваются либо контрольные суммы, либо контроль четности, либо сравнение с использованием какойто хеш-функции (смотря на каком уровне смотреть и какой софт юзать)
...люблю я попридератся к деталям да

Если вы знакомы с процессом резервирования дискового пространства, то вы должны были знать - что(!) Начало процесса лежит в оценке необходимого объема, следующий этап - само физическое резервирование. Но вы определили это как - резервирование в процессе копирования потому - что(!) вы не можете сразу увидеть, что какая то его часть уже зарезервирована, система об этом не сообщает. Вы не можете одновременно с копированием, увидеть в свойствах - что(!) эта часть уже занята под копирование. Вы видите только как увеличивается в объеме зарезервированные под этот объем - файл или папка.

ЗЫ. ну как я умею придираться к мелочам?
Придирается по настоящему тот - кто придирается последний

Брррр....это какойто поток сознания чесснслово
Процесс копирования - это процесс копирования, резервирование не имеет к нему никакого отношения, это есть совсем другой процесс. "Копирование" файлов не предусматривает резервирование места на носителе. Возьмите copy.c исходник из gnu coreutils и посмотреть там на ф-кцию static int copy_reg (...);

Она фактически вся сводится к просто вызову open() для src_path, open для dst_path, и потом в цикле просто read() из первого и write() во второй. Все. (Да я знаю что при желании можно реализовать через sendfile() но там тоже не будет резервирования). Вот эта функция это и есть копирование в чистом виде. Все остальное от лукавого. Да возможно какой то софт, реализует при работе с файлами и копированием файлов резервирование места на носителе приемнике данных - но к копированию это уже собсно никакого отношения не имеет.

..btw если вы гляние MSDN на предмет таких функций как CopyFile/CopyFileEx/CopyFileTransacted то увидите что там тоже ничего не сказано про резервирование
PS: какой то жуткий оффтоп уже пошел

(09-11-2012 13:41)So Sensually писал(а):  АндрейКа
По-русскому у меня твердая 2+ В передаче данных особо я не шарю, просто работаю в ИТ индустрии))

Фик с ней, с грамматикой! Вы про "геометрический массив" расскажите, я пойму.

Это мастер открыл исходные коды виндовс?
Это функции из С/С++, С#, ассемблера?

ЗЫ. Писькомерятельство пошло какое то ((((

(09-11-2012 16:22)smirnofb писал(а):  Это мастер открыл исходные коды виндовс?
Это функции из С/С++, С#, ассемблера?

ЗЫ. Писькомерятельство пошло какое то ((((

copy.c это base function's для команды cp, часть пакета gnu coreutils который щас используется в большинсте *nix подобных систем.
СopyFile/CopyFileEx/CopyFileTransacted это вызовы WinApi соот-но виндовс.
Кстати да исходники Win2000 по сети гуляют, и там можно посмотреть сорс CopyFile() и увидеть что идет тот же самый тупой read/write блоками по 4096 байт.
Это не писькомерятельство, просто не надо ерунду писать

Давайте усложним задачу. Поговорим о том, какие явления происходят при передаче потока (или как его правильно назвать? Пакетов?) через HDMI кабель. Ну скажем от транспорта на ДАК. Уж там точно ведь осуществляется двусторонняя связь с подтверждением. И как многие думают и утверждают (не попробовав сами естественно, и тем самым введя себя в неловкое положение), что от качества самого кабеля ничего не зависит, лишь бы он был исправен. А на практике очень хорошо слышны изменения в звуке при смене кабелей. И чем кабель лучше (что видно и по тому как он передает изображение) тем лучше и звук.

(09-11-2012 19:00)VladimirNB писал(а):  Давайте усложним задачу. Поговорим о том, какие явления происходят при передаче потока (или как его правильно назвать? Пакетов?) через HDMI кабель. Ну скажем от транспорта на ДАК. Уж там точно ведь осуществляется двусторонняя связь с подтверждением ...

Не. Двусторонняя связь там только по линиям DDC. Транспорт, по которому видео и аудио идут, там в одну сторону, без подтверждений.

Ребята, вы цепляетесь к мелочам, упуская суть.

Очень легко сказать "это не правильно", при этом не обосновав, а что именно не так и не написав, А КАК ЖЕ ПРАВИЛЬНО? Если ты больше знаешь на эту тему - ну так напиши причины влияния уюб на звук. Смысл троллить меня, ради чего?

Была одна здравая попытка опровергнуть. Ее откоменчу

(09-11-2012 14:21)Гаруспик писал(а):  ... а хотя бы минимальные потери, то декодирование цапом таких поток как mp3, dts и.т.д. тут же сорвется.

С чего ты это взял? Видел цифровое спутниковое телевидение? На экране иногда бывают большие клетки - искажения из-за потерь.

Любой электрический импульс по любому проводнику рассеивается . Отсюда и потери, конечно в % они минимальны, колоссальны они для hi-fi.

---

(09-11-2012 15:33)alexsandr писал(а):  будем выводить цифру из классной карточки хорошей оптикой или коаксиалом или кошерным юсб кабелем через посредственный юсб-спдиф конвертер, как думаете будет ли в выигрыше вариант с дорогим юсб кабелем?

ЗК - УГ, т.к. по PCI-E шине всегда будут помехи. Цифру лучше выводить с материнке по очень простой причине - меньше препятствий и помех на пути тракта.

"фишку" усб я объяснял, люди почему то не согласны и никто так и не смог объяснить почему. Все цепляются к какой то херне, какие то понты, непонятные высмеивания, вместо беседы по существу.

---

(09-11-2012 15:33)alexsandr писал(а):  Дешевый говорите?.....

....
Nordost Blue Heaven USB Cable
...

Да, 7.000 руб за Nordost Blue Heaven USB Cable это немножко дешевле чем 750.000 тыс за метр акустической валхалы.

Говорю - перестаньте цепляться к словам, откройте свой разум, еще раз прочтите, затем гуглите что такое USB, цифровой поток и все прочие термины.

Цитата:

(09-11-2012 14:21)Гаруспик писал(а):  ... а хотя бы минимальные потери, то декодирование цапом таких поток как mp3, dts и.т.д. тут же сорвется.

С чего ты это взял? Видел цифровое спутниковое телевидение? На экране иногда бывают большие клетки - искажения из-за потерь.

Это абсолютно другой протокол. В mp3 сэмплы связаны тесно с предыдущими. По сути следующий сэмпл описывает изменения тона звука, по сравнению с предыдущим отсчётом, а не сам отсчёт.
Стоит только одному пакету выбыть - всё, файл испорчен.

(09-11-2012 16:29)rraist писал(а):  Кстати да исходники Win2000 по сети гуляют, и там можно посмотреть сорс CopyFile() и увидеть что идет тот же самый тупой read/write блоками по 4096 байт.
Это не писькомерятельство, просто не надо ерунду писать

Попытаюсь вас примирить... Всё зависит, ИМХО, от типа файла. Если это ISO образ(или любой одиночный файл), то сразу оценивается пространство в "приюте", а лишь затем, если позволяет место, следует операция копирования. Если же это папка с кучей файлов, то ошибка копирования может возникнуть в процессе этого самОго копирования.

So Sensually
Ваша манера общения и сомнительные изложения доводов, как и советы, не вызывают желания вести беседу в конструктивном русле.

С уважением, Александр.

Если кто захочет себе сделать аудиофильский юсб кабелек, вот, в некотором роде, наглядное пособие с картинками
Текст на анг., но разобраться что и как, думаю не составит большого труда:

"DIY - Solid core silver audiophile USB - Yes your cable makes a difference "

http://2channelaudio.blogspot.com/2013/0...makes.html

А кто что думает про USB кабели SUPRA? Мурзилки их хвалят, больше я отзывов не нашел

У меня есть. Хороший. За те деньги, что за него просят. Даже очень. Не зря What Hi Fi его отметил.

(18-06-2013 13:22)All007 писал(а):  У меня есть. Хороший. За те деньги, что за него просят. Даже очень. Не зря What Hi Fi его отметил.

Сравнивали его..... или хороший бо дешевый, толстый и WHF хвалил?

Сравнивал, с пристрастием У меня есть ещё USB Блю Хевен и GT2 от Фурутек. Были ЦАПы PS Audio DLIII и MOON D100. Сейчас TEAC UD501 и Naim DAC V-1. Это все "запитывалось" с ноута. "Раздавалой" работает Фубар. Какое то представление получить можно.

(18-06-2013 16:43)All007 писал(а):  Сравнивал, с пристрастием У меня есть ещё USB Блю Хевен и GT2 от Фурутек. Были ЦАПы PS Audio DLIII и MOON D100. Сейчас TEAC UD501 и Naim DAC V-1. Это все "запитывалось" с ноута. "Раздавалой" работает Фубар. Какое то представление получить можно.

И как его зовут ? и какова длина и цена вопроса (в ЛС), плз. Кстати, пользуюсь при тестировании одним простеньким, но достаточно злобным методом. Параллельно тестируемому цапу включаю в другой юсб еще один цап и кладу как можно ближе.

(18-06-2013 17:14)onv писал(а):  

(18-06-2013 16:43)All007 писал(а):  Сравнивал, с пристрастием У меня есть ещё USB Блю Хевен и GT2 от Фурутек. Были ЦАПы PS Audio DLIII и MOON D100. Сейчас TEAC UD501 и Naim DAC V-1. Это все "запитывалось" с ноута. "Раздавалой" работает Фубар. Какое то представление получить можно.

И как его зовут ? и какова длина и цена вопроса (в ЛС), плз.

Супра продается на форуме, поищите. Я брал себе 2 метра