ig_z

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

Можно подробнее, что именно должно синхронизироваться? Производители обычно декларируют время задержки, что то типа: Total Group Delay (Fs = Output Sample Rate) tgd - 12/Fs - s. И обязательный малюсенький раздел - синхронная работа нескольких устройств. Обычно все сводится к напоминанию соединить все клоки вместе и перевести чип в слейв режим. В настоящее время производители оборудования декларируют "нулевую" разницу фаз между аудио каналами и ГВЗ 2 мСек для 192 аудио каналов. У вас есть данные, что это не соответствует действительности? Поделитесь инфой пожалуйста.

Это забота аппаратного аудио интерфейса в процессоре, если ТС его использует. Более вероятна проблема выбора 32 бит данных через 16 бит порты в некоторых "оптимизированных" платформах

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

В конце девяностых наблюдал со стороны за производством неких таких изделий. Использовалась полиэтилентерефталатная пленка, в народе лавсан, 35 микрон. Катушка моталась 40 микрон и получалась 600 ом. В те времена практически все заметные бренды делали так же. Магия существовала только в умах маркетологов и особо одаренных пользователей. Единственный заметный нюанс был в клеевых материалах. Наши использовали бф и это требовало определенных усилий для качественной склейки. Ну и диапазон технологий от 40-х до нынешних дней, для наушников и микрофонов, да еще и разных типов очень широк. Недавно видел статью, как умелец делал електростатические трансдьюсеры из лавсана толщиной 10 микрон. Уже есть и такой. А точно в беердинамик 20 микрон провод? маловато для серийного производства.

В яре такого вроде не было, лично я так и не нашел. Такое точно есть в гцц. Совсем недавно натыкался на бложик с описанием такого механизма. Там его применяли для построения стека вызовов

Весной в киеве AVID разогнал больше 50 человек. В том числе и сетевых разработчиков. Сам сидел на AVB демонах и езернет драйверах. Так что запрос в линкедин и может быть кто нибудь и отзовется

ждус это набор исходников, студия это среда разработки. Совершенно ортогональные сущности как теплое и мягкое. И комбинировать их можно в любых сочетаниях. Если вы хотите создавать вст плагин для какого то эфекта, то берите и создавайте. Там нет никакой рокет саенс. Тысячи контор на этом зарабатывают и миллионы хобистов на этом ловят фан. Желание повторять комерческие усилители, моделируя компоненты, это что то нездоровое имхо. Продаваны из отделов продаж напишут любую чушь, лишь бы исполнители звуков на музыкальных инструментах, в среднем имеющие умеренный уровень интеллекта и не имеющие никаких технических познаний, в конечном итоге отдали свои денежки. Простой пример "положение микрофона относительно кабинета". Ясный пень, когда чел увидит на картинке микрофон шур, кабинет маршал, а сквозь тряпочку динамики селешн, то сразу включится эллочка людоедка и с воплями хочу, денежка перекочует из кармана в карман. Хотя по сути там фильтр первого порядка. Если вы инженер, вы поймете о чем я. Любой гитарный усилитель есть комбинация амплитудных ограничителей, межкаскадных коррекций и темброблоков. В количестве от одного до много. Все тонкости и нюансы были многократно перетерты лет десять назад на простейшем радиолюбительском уровне на различного рода гитарных сайтах. Вся эта волна благополучно затихла лет пять назад. В сухом остатке несколько успешных коммерческих примеров 9вольтового гитарного оборудования, звучащего как "лампа". Понимание этих базовых принципов и возможность управлять всеми параметрами тракта дает возможность вст плагину быть необычайно гибким в настройке звука. При чем тут модели лампы я в упор не понимаю. Зачем может понадобиться производить сложные вычисления если можно производить простые? Я тоже не имею желания спорить на подобные темы, поэтому думаю, что вам смогут что то посоветовать на вегалабе и подобных ресурсах. Там все знают о моделях шерстяных проводов, слюдяных конденсаторах телефункен и американских электронах внутри 12ах7

Что за вопрос, если создают сложные плагины, что мешает создавать простейшие? На выходе должна получиться длл и никакой черной магии не нужно. Имплементите виртуальный метод унаследованного класса. Вот как приблизительно выглядит дабл рейнж мастер void RangeMaster::processReplacing(float** inputs, float** outputs, VstInt32 sampleFrames) { float* in = inputs[0]; float* out = outputs[0]; #if 0 while (--sampleFrames >= 0) { *out++ = *in++; } #else static float y[2]; //output samples static float x[2]; //input samples static float y1[2]; //output samples static float x1[2]; //input samples while (--sampleFrames >= 0) { //shift the old samples x[1] = x[0]; y[1] = y[0]; x1[1] = x1[0]; y1[1] = y1[0]; //Calculate the new output x[0] = *in++ * _ioutput; // *out++ = y[0] = ACoef * (x[0] - x[1]) - BCoef * y[1]; x1[0] = y[0] = ACoef * (x[0] - x[1]) - BCoef * y[1]; *out++ = y1[0] = ACoef1 * (x1[0] - x1[1]) - BCoef1 * y1[1]; } #endif } Зачем может понадобиться реализовывать модель усилителя/преампа/эффекта через спайс модели? Почему нельзя это делать напрямую? Но конечно, если очень хочется, то можно навернуть любые бессмысленные и беспощадные вещи. Про "звучания какого-нибудь именитого усилителя" вообще не понял, усилитель должен усиливать, а звучать должен инструмент. ВСТ плагин модифицирует звучание инструмента в соотв с заложенным алгоритмом. Мухи отдельно, котлеты отдельно

Совсем грубо и на пальцах можно прикинуть так: - среднепотолочный цап дает 1Vrms на выходе и имеет с/ш 120дБ - на выходе цапа в режиме цифрового мьюта будем иметь 1uVrms или 6.6uVpp шум. В режиме ресета смотреть шумы на выходе цап-а имхо неразумно. Только цифровой + аналоговый мьют, если такой имеется. Далее умножать на коэффициенты умножения в тракте и смотреть где появляется сильное отличие в уровнях.

Возможно это USB in a NutShell http://www.beyondlogic.org/usbnutshell/usb1.shtml\ Еще по сети гуляет док файл под авторством Мисячного, там этот вопрос освещен явно

На предыдущем проекте заказчик специально прислал девайс для снифинга "тап". Два рабочих входа А В для подключения в исследуемую линию, и два выхода - один дублирует трафик из А->В, второй выход В->А. Причем тап активный, с двумя! входами питания и довольно сильно грелся, но на гигабите работал без проблем.

Телепаты в отпуске, попробую угадать. Под виндовс влан теги стрипаются драйвером до снифера

Я что то не понимаю наверное. С абстрактной точки зрения езернет не гарантирует ничего, ни время доставки пакета, ни целостность пакета, ни задержки распространения ит.д. Единственная цель проектирования - максимальная живучесть сети. Иными словами езернет "обыкновенный" или "офисный" асинхронен по свой природе. Пакет защищается црц, доставка гарантируется тцп и собственно все. Вроде есть какие то разновидности реалтайм езернет, синхронный езернет, езеркат, но это все нишевые технологии. Если вернуться к птп, то этот стандарт гарантирует возможность в произвольный момент времени произвольному слейву вычислить абсолютное время грандмастера. Далее слейв волен делать что угодно, синхронизировать внутренние плл, внешние генераторы и т.д. Т.е. некоторая периферийная деятельность будет происходить во временном домене грандмастера с точностью, определяемой стандартом. С технической точки зрения птп расчитывает задержки распространения до соседей, далее аккумулирует задержки распространения до грандмастера. Далее получает время грандмастера с учетом кумулятивной задержки, далее расчитывает соотношение частот с соседями, далее вычисляет соотношение частот между собой и грандмастером. И после этого в любой локальный момент времени может получить время на грандмастере просто сумируя последнее полученное время от грандмастера плюс локальное время, умноженное на соотношение частот. Никаких точных меток, пакетов, или еще чего то здесь нет. Это не ЮСБ с их СОФами. Если вы соедините мастер и один слейв напрямую, а другой слев через 10 цисковских супер пупер свичей, а третий слейв через 100 безымяных свичей, то все равно после переходного процесса время грандмастера на всех слейвах установится одно и то же, хотя птп пакеты будут прилетать как попало, в зависимости от задержек на конкретных свичах. И если вдруг свичи начнут менять активную топологию, все равно будет короткий переходной процесс и дальше опять все слейвы будут работать в одном птп домене грандмастера

Для примера в нашем изделии омап + марвел. Стандартная частота птп 8 кгц. Судя по логам точность синхронизации времени десятки наносекунд. птп может скомпенсировать все, за исключением джиттера и несиметричности задержек. джиттер можно фильтровать, если он правильный. Несиметричность похоже никак не компенсируется. Для начала на хабре почитайте статью о птп в линуксе

Поддержать, это не значит реализовать. В данном свиче неЦПУ порты могут находиться в состояниях, определенных СТП, РСТП или МСТП стандартами. Вот и вся поддержка. Остальное это задача софта. Пример реализации можно найти в МСТП демоне линуха. Только сначала нужно набраться мужества столкнуться с некоторым числом нетривиальных стейт машин на каждом порту :).

Это же кортекс, там нет арм режима. Поэтому младший битик д.б. равен 1

Что значит "полная порнография"? Можно плиз подробнее и более техническими терминами обрисовать ситуацию. Что такое "похожий многоканальный i2s"? В LPC есть I2S и SGPIO. Судя по описанию, на последнем можно делать всевозможные серийные синхронные / асинхронные шины и заниматься ногодрыжеством. Для этого он и задумывался, и как любое универсальное решение обладает избыточностью. У меня руки до него еще не дошли, если у вас есть конкретная информация об отрицательных свойствах этого модуля, поделитесь информацией, это будет всем интересно В чем заключается полусофтварность? Ну и как бы для юсб аудио интерфейса особо то и заниматься нечем. Например взять LPC17. Если бы DMA было бы поумнее ( что то типа 2D) или I2S модуль оптимальнее спроектирован, то весь аудио стрим для некоторых режимов мог бы передаваться без участия CPU.

Слегка офтоп. Если у вас есть LPC с SGPIO модулем, то можно получить похожий функционал. В сети бродит описание такого проекта. Pg22_27_IQV11N1_IQ__37.pdf

В ЮСБ аудио классе описан асинхронный режим. Ресемплинг совершенно не нужен. Пару раз пытались обсуждать эту тему. Из своего опыта могу сказать, что даже для самого общего случая виндовс + аудио вход + аудио выход решение получается достаточно простое. Для вашего случая все значительно упрощается - нужен только вход и хост будет использовать входной стрим для неявной синхронизации. Вы наверное лучше меня знаете проект fifi sdr, там девайс тактируется внутренним клоком 48кГц. За одну мСек времени на хосте, девайс передает в пакете 47,48 или 49 семплов в зависимости от соотношения частот между ними. Если девайс сформировал 1234567 семплов за какое то время, то в хосте окажется именно это количество семплов. Ни больше ни меньше.

Для начала нужно найти непроприетарный стандарт :) Я знаю только один - внезапно аудио видео бродкастинг AVB. Точно есть в последних двух релизах Епла. Вполне возможно есть в БСД и что то пилится в линуксе. В виндовзе скорее всего не будет никогда.

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

Дык может он пыточную делает, мы же не знаем. И 140 дБ пойдут вверх от -70. Вот и ждем чем закончится этот интересный тред

У вас ZWave или ZWave+ ? У них логотипы разные. Только что посмотрел исходники sample-application DoorLock(по идее ближе всего к реле по функционалу) для ZWave, там статус записывается в еепром. Читается при старте и восстанавливает значение выхода. В стандартных комманд классах ZWave ZWave+ я не припомню возможность устанавливать выход в предопределенное состояние, но есть возможность расширять стандартные комманд классы с помощью COMMAND_CLASS_MANUFACTURER_SPECIFIC. Нужно смотреть доку конкретного производителя. А какой у вас тип соединения между устройствами? Секьюрный или нет? ЮСБ свисток может работать ZWave снифером?

В мире синхронного аудио применяют алгоритм JetPLL. http://www.tctechnologies.tc/index.php/products/jetpll В нашем проекте используется какая то часть альтеры, управляющая непосредственно RC генератором. Результаты поразительные, на вход подается 6кГц от таймера, работающего от клоков гигабитного e-mac. На выходе получается идеальный "хи енд" клок для топовых adc/dac. Судя по доке, основной узел этого устройства есть DDS, но как это можно поместить в альтеру без скоростного dac-а я не могу представить.