?

Log in

No account? Create an account
Fire-wire против USB: ну сколько можно а. - сообщество "Звукорежиссура" [entries|archive|friends|userinfo]
Звукорежиссура

[ website | Привоз звукового оборудования из Европы (www.thomann.de) ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Fire-wire против USB: ну сколько можно а. [Apr. 6th, 2010|07:32 pm]
Звукорежиссура

ru_zvuk

[krasowski]
[Tags|, , , , , ]

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

Представим что нам нужен внешний аудио-интерфейс, либо на юсб, либо на файр-вайр шинах. Мы хотим чтобы к этому интерфейсу можно было подключить как можно больше аналоговых инструментов, и в тоже время иметь возможность качественного мониторинга. При всем этом проекты нам хотелось бы вести с достаточно высоким уровнем качества. Итак пусть это будет следующий интерфейс:
10 in - 24bit 96k
10 out - 24bit 96k

Один моно канал каждую секунду квантуется (dsp чипом) 24 бита 96 000 раз. 1 байт = 8 бит. 24бита = 3 байта.
За 1 секунду моно канал пропускает 288 000 байт ~ 282 килобайта аудио-данных или же 2,3 Мбит/с
Допустим нам нужно одновременно использовать 10 входов и 10 выходов в формате 24/96. Для удобства будем оперировать бит/с:
10 моно входов будут пропускать за 1с 23Мбит (очень грубо 3Мбайта данных).
Столько же аудио-данных формата 24/96 будут передаваться 10-ю моно выходами.

Итак общая нагрузка на наш сферический аудио-интерфейс с 10in/10out каналами в формате 24/96 будет составлять 46Мбит/с (около 6Мбайт в секунду):
Пропускная способность ЮСБ 2.0 = 480Мбит/с (сравните с требуемыми 46Мбит/с)
Пропускная способность Файр-Вайр = 400Мбит/с (сравните с требуемыми 46Мбит/с)

Это не значит что ЮСБ/Файр-Вайр шины загружены только чистыми аудио-данными. По-мимо аудио-данных передается океан другой сопутствующей системной информации. И ЮСБ и Файр-Вайр работают с пакетами аудио-данными практически одинаково и исключительно в синхронном режиме, для гарантированной передачи данных.
Возникает вопрос: а откуда берутся всякие задержки, если электрический сигнал протекает мгновенно? Раз для передачи такого качественного сигнала на 20 моно-каналов требует в 10 раз меньшую пропускную способность, чем интерфейс, то что мешает передать сигнал мгновенно и без всяких задержек, которые мы можем наблюдать в реальных условиях? Мешает физика, так как аудио-интерфейс это не простая коробка пропускающая преобразованный из аналога в цифру сигнал.

По моно каналу идет аналоговый сигнал. Поступая на вход аудио-интерфейса этот аналоговый аудио-сигнал преобразуется в цифровой для его внутренней обработки. Но цифровой сигнал - это не абстракция из 0 и 1. Это прежде всего импульсы в цепи. И основа для создания этих импульсов - ток - то что называется упорядоченным движением частиц. Чтобы передать цифровой сигнал в формате тока, а не какой-то там абстракции - его необходимо с модулировать. Но и этот процесс не достаточно просто и очевиден.
Поэтому идет модуляция цифровых данных для физической передачи их по кабелю соединяющему аудио-интерфейс и компьютер. Впрочем модуляция данных идет на протяжении всего аудио-тракта в различных его звеньях.

Рассмотрим модуляцию на примере аудио-интерфейса с файр-вайр.
Для начала передачи с модулированных аудио-данных аудио-интерфейс просит предоставить синхронный канал у компьютера , имеющий полосу частот, соответствующую его потребностям . Идентификатор синхронного канала передается вместе с данными пакета (вот они и появляются "новые" системные данные по-мимо аудио-данных). Получатель проверяет идентификатор канала и принимает только те данные, которые имеют определенный идентификатор (еще больше системных данных появляется между системами). Сами данные с идентификатором разбиты на синхронные каналы и объединены в пакеты конечной длины по 125 микросекунд (т.н. кадры). Кадры передаются в буфер.

Представим что мы имеем возможность управления буфером кадров.
В 1с = 1000 000 микросекунд. 1 кадр = 125 микросекунд. 4096 кадров = 512 000 микросекуд = 0.5 секунды.
Если мы выставим 128-256 кадров = max 32000 микросекунд = 16-32 милисекунды.

Передача кадров происходит на канальном уровне. Но есть также уровень приложений. И вся та же технология пакетной передачи аудио-данных реализована и на уровне приложений, а в роли пакетов выступают - сэмплы. Сэмплы также буферизуются системой и размер буфера хранения сэмплов задается и чаще называется asio/wdm/core audio buffer sizs.

Вот она откуда берется задержка. Из модуляции аудио-данных, так необходимая для их физической передачи. Поэтому когда вы подключаете свой инструмент в аудио-карту и включаете любимый хост, то можете наблюдать общую сумму задержки в аудио-тракте и отдельных ее участков. На каждом участке идет обработка данных и их модуляция. То есть аналоговый звук, например, гитары кодируется а затем модулируется и передается последовательными пакетами данных каждую Х-милисекунду.

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

Модуляция на канальном уровне происходит аппаратно (усилители, таймеры, системы управления питанием, ключи, мультиплексоры и т.п.). Физика этих компонетнов близка к идеальным. Но тем не менее аппаратные несовместимости встречаются. В модуляции передающего-принимающего сигнала играют, что очевидно и соответсвенно, передающие и принимающие компоненты систем. Поэтому все еще распространена проблема некорректной работы некоторых аудио-интерфейсов на базе fire-wire с соотвествующими контроллерами материнских плат компьютерных систем (известные советы в отношении работы с TI контроллерами). Но если физика уже отточена, то логика программирования взаимодействия устройсв на уровне операционных систем и приложений все еще развивается и видоизменяется. Поскольку качество системы определяется ее самым слабым звеном, то можно констатировать факт, что на сегодняшний день в мире аудио-интерфейсов, да и не только, таким звеном является "программное" - драйверы, ОС и прилагающееся ПО.

Компании Alesis, M-Audio, Cakewalk и другие намекали (в частности на форумах их поддержки), а некоторые открыто заявляли, что в большинстве случаев качественных различий между FW400 и USB2.0 на сегодняшний день нет, а драйверы обеспечивающие их работу прошли те стадии ошибок и нестабильности, которые можно было наблюдать еще несколько лет назад, а сам тип подключения не является синонимом качества и профессиональности устройства.
Я же еще раз предлагаю вдуматься в информацию выше, представить тот аудио-поток с которым вы собираетесь работать и сделать выбор в сторону удобства и каких-то других качественных различий в аудио-интерфейсах, нежели вопрос шин передачи данных. Такими вопросами могут быть - наличие цифровых интерфейсов, встроенных усилителей, качественная работа с ОС (особенно важный вопрос), возможность расширения и одновременная работа с несколькими аудио-картами (в этом случаи fire-wire выглядит предпочтительным, потому что только он позволяет такую реализацию) и т.д.
LinkReply

Comments:
[User Picture]From: bugaets
2010-04-06 03:38 pm (UTC)
:) а под кат ?
(Reply) (Thread)
[User Picture]From: alexboogie
2010-04-06 03:51 pm (UTC)
ну на самом деле да, прямо хотя FAQ пиши, насколько часто возникает вопрос а потянет ли мой USB столько-то каналов и такой-то битрейт
не укладывается видимо у людей в голове, какая прорва информации может передаваться по тоненькому проводочку
ну и еще конечно производители тоже запутывают людей - мол а чо вы хотите, ведь нормальное качество звука не может передаваться по жалкому USB, смешно даже, а уж если 8 каналов - то вообще не смешите народ, а покупайте наше устройство на самой правильной FW шине, уж оно-то огого, передаёт без потерь, в отличии от стандартного FW адаптера, который конечно половину данных растеряет по дороге, не говоря уже про USB
и люди верят и переспрашивают
(Reply) (Thread)
[User Picture]From: todesser
2010-04-06 03:52 pm (UTC)
И ЮСБ и Файр-Вайр работают с пакетами аудио-данными практически одинаково и исключительно в синхронном режиме, для гарантированной передачи данных

Ничего подобного. Режим усб2 синхронным можно назвать только с очень большой натяжкой, т.к. присутствуют значительные задержки между запросом на передачу данных и саму передачу.
В усб3 это вроде пофиксили.
(Reply) (Thread)
From: (Anonymous)
2010-04-06 05:15 pm (UTC)
PCI.
(Reply) (Thread)
[User Picture]From: father_gorry
2010-04-06 05:16 pm (UTC)
Задержка возникает из-за архитектуры железа/софта. На одной и той же машине задержка может отличаться в разы между WDM и ASIO-драйверами, потому что WDM несколько раз копирует входящие данные в разные разделы памяти. ASIO тоже копирует (такова уж особенность PC/win), но меньше раз. Отсюда и задержка, и размер буфера.
Так что статью можно сократить до расчета объема канала.

А факты таковы, что firewire лучше не покупать. Именно потому что в нем используется синхронный интерфейс, как пишет todesser.

Скорости за глаза хватает, так?

Но.

Синхронный интерфейс требует синхронизации по часам с обоих сторон - на карте и на компьютере. А этот протокол плохо стандартизован, поэтому на firewire-картах часты треск и глюки в зависимости от того, к какому чипсету он подключен. Чипсет в ноутбуках сидит на мамке, поэтому чтобы не переживать по поводу звука, придется сменить 2-3 ноутбука.

А это геморрой.
(Reply) (Thread)
[User Picture]From: froll
2010-04-06 11:07 pm (UTC)
> Синхронный интерфейс требует синхронизации по часам с обоих сторон - на карте и на компьютере.

Интересно, как вы себе это представляете.
Вы с понятием "master clock" знакомы?

> А этот протокол плохо стандартизован

%)))
Вы это сами придумали?
Что конкретно у вас "плохо стандартизировано", SMPTE time code? AES/EBU?

> поэтому на firewire-картах часты треск и глюки в зависимости от того, к какому чипсету он подключен

Вот тут вывод правильный, хотя совершенно неправильный посыл.
Треск и глюки от кривизны драйверов, удешевления схемотехники и дешевизны применяемых компонентов.

> Чипсет в ноутбуках сидит на мамке, поэтому чтобы не переживать по поводу звука, придется сменить 2-3 ноутбука.

Вы знаете, с тех пор придумали FireWire-интерфейсы в форматах PCMCIA и ExpressCard.
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: proxiper
2010-04-06 05:57 pm (UTC)
Firewire -- модная говно с кучей проблем. Более-менее адекватно с ним работают только RME и еще более дорогие девайсы. С остальными лотерея -- может быть будет все нормально, может откажет в самый неподходящий момент, а может вообще не заведется даже с контроллером от TI.

С новыми девайсами на USB вроде более-менее, но тоже всяко бывает.

Но если нужны малые задержки и стабильность, то только PCI и PCI Express. Лучше только цифровой интерфейс, а конвертеры внешние.

(Reply) (Thread)
[User Picture]From: fan_d_or
2010-04-06 07:24 pm (UTC)
Но если нужны малые задержки и стабильность, то только PCI и PCI Express. Лучше только цифровой интерфейс, а конвертеры внешние.

Можно подумать, что цифровой интерфейс идёт через какую то другую дырочку!
Цифровой интерфейс ничем не отличается от аналогового - потому, что с звуковым чипсетом оно сопрягается по протоколу I2C. На I2C сидят и АЦП/ЦАП, и порты SPDIF - потому никаких преимуществ с точки зрения доступа в компьютерное пространство у цифрового потока нет. Аналоговый вход (АЦП) имеет даже преимущество - поскольку АЦП не создаёт дополнительного геморроя с синхронизацией потока, находясь под полным контролем звукового чипсета.

Абсолютно все заморочки со звуком на компе вызваны убогостью протоколов передачи срочной (привязаной ко времени)информации внутри самого компа - ОС имени Воротного Билли являются катастрофой в реал-тайме, будучи спроектированными откровено бездарно.

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

USB чуть хуже, чем IEEE, потому, что на нём сидит слишком много задач (периферии) системного плана. Правда, он лучше отлажен - поскольку на PC USB является родным, а яблочный файрвайр - гостем...

По уму - звуковой интерфейс звука надо сажать на SATA. Там ему самое место... Но в очередной раз никто не сделает правильно...
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: froll
2010-04-06 11:09 pm (UTC)
Не сказал бы, что FW "модная говно", но проблемы, действительно, только у дешевых устройств типа M-Audio, RME работают хорошо.

USB типа "знает свое место" и работает более-менее ожидаемо.
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: froll
2010-04-06 10:59 pm (UTC)
А под кат? ;)))

Написано много, все по делу, но.

Разница между USB и FireWire при _самых прямых дровах_ проявится при забивании шины десятком устройств, которые будут раздирать USB на части. FW же, как интерфейс управляемый и с передачей данных кадрами, пострадать от этого не может принципиально - если устройству уже выделена "полоса", оно его получит.

Это все :).

В бытовом применении выигрыша у FW я не вижу, поскольку USB тупо дешевле и есть везде, а если возникает проблема с навороченной мышкой или планшетом, которые мутят воду в USB (ситуация редкая, но тем не менее), то проще на время записи все это убрать.
(Reply) (Thread)
[User Picture]From: fan_d_or
2010-04-06 11:55 pm (UTC)
Разница между USB и FireWire при _самых прямых дровах_ проявится при забивании шины десятком устройств, которые будут раздирать USB на части.

+1
(Reply) (Parent) (Thread)
[User Picture]From: uninvisible
2010-04-07 01:58 pm (UTC)
Собсна, в этом вся и суть без остатка. то же всё время и пишу. Если не воткнуто по USB ещё дохрена всего - мышки, хуишки, клавиш несколько и прочее, тем более -внешний винт - юзай USB. С внешним винтом, особо если с него работать, с USB возникают затыки.
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: p_h_langer
2010-04-07 07:15 am (UTC)
> идет модуляция цифровых данных для физической передачи
> их по кабелю соединяющему аудио-интерфейс и компьютер.

что-то я сиииильно сомневаюсь в налиии там кобельного момеда, несущей, которую чем-то модулируют etc

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

...но самое главное - вы лишний раз подтвердили мой главный тезис: хреновина для тюкания мышечтькой в окошечько, даже снабжённая обгрызенным фруктом на заднице - очень плохо годится для использования в качестве звукового устройства :-)
(Reply) (Thread)
[User Picture]From: uninvisible
2010-04-07 10:55 pm (UTC)
Кому как. Хехехе. Для всего нужны и важны голова и руки.
(Reply) (Parent) (Thread)
(Deleted comment)
[User Picture]From: cyanide_burnout
2010-04-22 05:51 pm (UTC)
C USB 2.0 не все так радужно, как вы пишите (в сравнении с FW). Вот тут по русски изложено, к примеру - http://www.ixbt.com/storage/usb3hdds-p01-buffalo.shtml
(Reply) (Thread)