ig_z

У вас хороший проект, и компенсация выше, чем в среднем по больнице. И по инсайдерским данным очень комфортный коллектив. Так почему уходит(ушел) текущий синьор?

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

фидбек еп такая же изохронная еп как и остальные две, а значит должна обрабатываться соф ивентом. Например в обработчике прерывания. При чем тут функция мейн?

Что то новенькое! Каким боком размеры разъемов стали влиять на параметры тракта? Если взять дюймовый банан, там можно ожидать потолок в 720 дБ?

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

На картинке результат работы типичного кодека с с/ш около 114 дБ. Скорее всего копеечный кристал семикондуктор. Даже не 20 ЕНОБов. Асахи со 130 дБ впечатляют. Но до теоретического значения в 144дБ дойдут ни в этой, ни в следующей жизни. Разрядность интерфейса можно нарисовать любую, хоть 132 разряда. У нас в девайсах есть форматы с плавающей точкой 32-64 разряда. Не нужно никому, кроме разве что эфектопейсателей.

Позволю себе дополнить. Теория изложена в трудах Фарино. Пример реализации идеи с экспоненциальным chirp-ом: http://gaydenko.com/qloud/ Единственный открытый вопрос - точный расчет fade in, fade out времен. Как я понимаю, форма fade in, fade out есть оконная функция, возможно с экспоненциальным изменением во времени как и у chirp-а. Длительность fade in, fade out зависит от скорости изменения частоты в chirp-е

Здесь я могу высказать только общие и глубоко субъективные впечатления. Я отработал на зенсис чуть больше трех лет 2010 - 2013, и достаточно плотно общался с разрабами секретной части их либы. Они с большим уважением относились к работе Адама Данкелса, и не только потому, что они соседи. Данкелс реально создал могучую "экосистему", особенно нас впечатляло наличие симулятора сети. Ничего подобного на зенсисе небыло и не планировалось. Поэтому, если вам нужна действительно сложная, разветвленная и управляемая сеть, то это лучшее решение имхо. К тому же бесплатное и с большим комьюнити.

Два года работал на зенсис и год на сигмадизайн. Два года назад начинал 4 семпл апликейшина для зивейв+. Ни разу не встречал и не делал ни одного охранного семпл апликейшина. Ибо таких не было в природе как минимум год назад. Секьюрный протокол там был просто улет - ничего более накрученного и дырявого я в своей жизни не видел. Правда они за последний год должны были выдать новую версию. В итоге - закрытый кристалл, закрытый протокол, закрытые исходники. При мне хотели продаться гугелу, потом циске. Даже эти всеядные их не захотели. Рискните, попробуйте :) И не говорите, что вас не предупреждали

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

Вроде бы в нотной записи используется "приблизительно - относительная" система длительностей. Типо "быстро", "очень быстро" и т.д.Предельный ритм по моему 200 тактов в минуту или около того. Что то типо шмеля или чардаша. Задержки между нотами без пауз по идее состоят из затухания предыдущей ноты и атаки следующей ноты, т.е. стремящиеся к нулю. Могу завтра выспросить у консерваторцев поточнее

Задорновский шша-шный персонаж детектед. В этом треде одна звезда из прибалтики, другая из РБ. Оба маргиналы и оба не способны работать в современных девелоперских коллективах. Вопрос, причем тут Россия? :) А вот в шша на свн остаются одни нищеброды. Если чо я из киева и контора ведет проекты в аккуреве и разумеется все сказанное плод моего имха

Спасибо, смотрю код. С I2S проблем нет. Я работаю с LPC17 и продолжу c LPC43 но тем не менее интересно было бы взглянуть на работу I2S модуля STM32 в реальном проекте.

А можно ли получить доступ к репозиторию? Я работаю с LPC, но есть определенный интерес к STM. Хочется оценить удобство/неудобство работы с I2S в реальном устройстве.

Что там искать ;) какой нибудь беринджер за 100 баксов. Для тех кто в теме удивительно, как 2-х долларовый микрофон в пластиковом корпусе с разъемом можно впаривать за такие деньги. И тем не менее удивительно, как от такой "конструкции" можно добиться такого низкого уровня акустического шума.

А можно ссылку на документ, что именно так измеряется с/ш для этого микрофона? Если прикинуть на пальцах, то получаем, что уровень шума равен 73 - 62 = 11 dBSPL или приблизительно 7-8 dBA, что является вполне нормальным параметром для [очень] дорогих измерительный микрофонных картриджей уровня Брюля или Роде. И совсем уж оптимистичная цифра для 6мм микрофона, производимого сразу для "всего" и скорее всего где нибудь в кетае

У микриума в примерах есть(был) обработчик с раскруткой стека и выводом в консольку значений регистров.

Наиболее вероятная причина - несинхронная работа с фифо. Т.е. нечетное кол-во лишних и/или недостающих чтений фифо. Что такое "настроить систему для однозначного определения" я не понял. Если есть бага с чтением фифо, её нужно фиксить и все. Как это делать вам никто не подскажет. Никто не видел ваших исходников и никто не знает задушевные тонкости организации I2S модуля. Простейший совет - перейти на 16 бит режим. Вряд ли в мире много людей, способных различить разницу 16 - 19 бит.

Там же вроде есть виртуальная машина к этим платам. Она вас чем то не устраивает?

На потенциально интересную вакансию два раза кинетически посылал резюме. Ни ответа ни привета.

Я прикрутил к кейловскому стеку (для LPC): #if USB_ERROR_EVENT static const char UsbErrorMsgs[8][32] = { "-------| PID_ERR --------------", "------|- Unexpected Packet ----", "-----|-- Data CRC error -------", "----|--- TIMEOUT -------------", "---|---- End of packet error --", "--|----- Buffer Overrun -------", "-|------ Bit stuff error ------", "|------- Wrong toggle bit -----" }; void USB_Error_Event(uint32_t error) // void USB_Error_Event (DWORD error) { TT_EN(Usb_ErrorEvent); TT_ERR_MSG("error = 0x%X", error); if (error & 0x000000FFL) { uint32_t i, err_msk; for (i = 0, err_msk = 0x1; i < 8 ; i++, err_msk <<= 1) { if (error & err_msk) { TT_ERR_STR(UsbErrorMsgs[i]); } } } if (error & 0xFFFFFF00L) { TT_ERR_STR("USB_UNEXPECTED Error"); } if (error == 0) { TT_ERR_STR("UNEXPECTED (error == 0)"); } TT_EX(); } #endif Реально наблюдал только ошибки "Unexpected Packet" на LPC2368. На LPC1766 таких ошибок не наблюдал

Классика жанра - деление на ноль. Книги и интернет завалены примерами. У меня так #ifdef TEST_HARD_FAULT int div(int lho, int rho) { return lho/rho; } void testFault(void) { int a,b,c; a = 10; b = 0; TT_INFO_NM_STR("test HardFalt handler\n"); c = div(a, b); TT_INFO_NM_MSG("c = a / b; => %d",c); } #endif //ifdef TEST_HARD_FAULT

В принципе разные производители измеряют параметры с разными нюансами. Как минимум нужно всегда искать сноски мелким шрифтом по поводу взвешивания с/ш при измерении. По моим ощущениям малопотребляющие кодеки находятся в диапазоне с.ш 105 дБ и ниже. Далее идет диапазон 105 - 115 дБ. Это 5в высококачественные кодеки, в основном от компаний купресс и асахи. Ну а пределом на сегодня является цифра 120 -123 дБ, но это достижимо только на раздельных цап ацп с потреблением более 300 мВт. По поводу микрофона. Вроде обычный шарповский электрет дает динамический диапазон около 60 дБ. Совершенно спокойно можно согласовать с 90 дБ кодека. 10дБ снизу и 20дБ сверху на перегрузочную способность канала останется. Что касается формата передачи данных, то я обычно выбираю формат 64FS. Т.е. левый/правый дергается с частотой 44.1 или 48 кГц, частота битовых клоков в 64 раза выше. Все варианты стерео кодеков с 24/32 битовым выходом будут работать. Ну и если есть необходимость в мастер клоке, то использую 22.5792 или 24.576 мГц (FS*512). Положение битов относительно сигнала левый/правый может быть любым, я предпочитаю выровненный вправо. Ну и очевидно, что формат данных должен совпадать на обеих концах линии.

В аудио мире так не принято. Точнее у всех 24 или 32 разряда для маркетинга. Реальная разрядность смотрится по отношению с/ш - 120 дБ это около 20 рарядов. Для малопотребляющих может быть и 17 и 18 разрядов. Из 3-х вольтовых есть еще UDA1380.

У меня так: #if USB_ERROR_EVENT static const char* UsbErrorMsgs[] = { "-------| PID_ERR -------------------------------------", "------|- Unexpected Packet --------------------------", "-----|-- Data CRC error -----------------------------", "----|--- TIMEOUT ------------------------------------", "---|---- End of packet error -------------------------", "--|----- Buffer Overrun ------------------------------", "-|------ Bit stuff error --------------------------", "|------- Wrong toggle bit in data PID ----------------" }; void USB_Error_Event(uint32_t error) // void USB_Error_Event (DWORD error) { TT_EN(Usb_ErrorEvent); TT_MSG("error = 0x%X", error); if (error & 0x000000FFL) { uint32_t i, err_msk; for (i = 0, err_msk = 0x1; i < 8 ; i++, err_msk <<= 1) { if (error & err_msk) { TT_STR(UsbErrorMsgs[i]); } } } if (error & 0xFFFFFF00L) { TT_ERR_STR("USB_UNEXPECTED Error <================================"); } if (error == 0) { TT_ERR_STR("UNEXPECTED invoke USB_Error_Event() handler <========="); } TT_EX(); } #endif