Берем 4-е штуки AD1974 в режиме ADC TDM Daisy-Chain Mode.

Подключаем к Kinetis серии MK66. На борту там уже есть USB HS и 32 DMA канала. Скорость в 9 и более мбайт/c в bulk режиме там достигается легко.

И все, 16-ть 24-х битных 196 КГц каналов обеспечено! Работы на пару недель, говорить не о чем.

Какой bulk режим? Аудио класс работает в изохронном режиме Или вы хотите свой bulk драйвер писать?
Тогда забудьте про управление усилением и громкостью по аудио классу USB В аудасити и тд движок такой видели?
И множество других переключений по аудио классу
Пару недель ?
Вы с вашим уровнем и за пару лет не управитесь
USB это болото которое годами осушается

А зачем нам Audacity?
Я Audacity сразу отбросил из рассмотрения когда мне нужно было сделать редактор аудиозаписей.
Это дичайший анахронизм, они там даже QT не использовали, весь GUI реализован на голом C/С++ без намека на использование RAD инструментов или визуальных сред!

А драйвер на USB писать не надо.
Для RAD Studio есть компоненты напрямую работающие с конечными точками.
bulk - режим с гарантированной доставкой, это будет иметь преимущество в глазах заказчика перед вашим изохронным.

А мистическая сложность USB у вас видимо от того, что имеете дело с embedded Linux от TI.
Я вам сочувствую, но уверяю на Cortex-M4..7 тоже самое делается гораздо проще, надежней и быстрее.

Вам ни нафиг не нужна "аудиоплата". Вам нужно делать "устроство диагностики", а не заниматься изобретеним "аудиоплат" и их лобовым использованием. Так же, как не следует цепляться за какой-то конкретный интерфейс с компьютером. Более того для Вашей области применения тот-же USB есть последний вариант который следует рассматривать.

Ой! Дяденька "дИРЕКТОР" не надо!! Очень испугался!!!

Спасибо за сочуствие мил-человек
Особенно трогательно звучит от человека который любит QT который везде глючит ( и не может не глючить теоретически , поскольку кросс платформ
не знает деталей а вся суть в деталях, ну если только вообще не обращаться к железу)
И не любит TI C ( Code Composer) который позволяет отлаживать как отдельное firmware так и системные Линукс программы
с АППАРАТНЫМИ брекпойнтами что на порядок-два сокращает время отладки Для usb firmware без этого вообще никак
Про редактирование и перекомпиляцию uboot вообще боюсь спрашивать - видимо презрительно отвергаете сам факт его существования
дл 95% эмбеддед инженеров

Bulk -> tcp/ip тоже имеет преимущество перед udp но когда в реал тайм используют первый , если нет акноледжа или не совпала контрольная сумма - что делать
системе? Перезасылать последний кадр? Это невозможно поскольку ширина канала рассчитана под спектр речи не более а также получение
акнолежда по обратному каналу и перезасылка удвавают задержку и не вписывается в реальное время А пульсирующий по ширине канал неприемлим в системах
уплотнения А резервировать более широкий канал это денежки Так что все равно кадр пропускать Так сделано во всех аудио и видео системах интернет вещания.
это не диск который можно перечитать , это реал тайм
Эх , голова садовая

Audacity - стандартный редактор Линукс им пользуются все
В виндах их множество но все они работают с usb аудиоклассом в тч с плагинами Это 99% звукового софта
Странно слышать от человека дожившего до своих лет призывающего лепить нестандартные несовместимые поделки
Мы в штатах ( www.сentrance.com ) сначала не смогли освоить управление по аудио классу , несколько лет управляли девайсами по midi( usb-midi)
- изделия micport, axeport, dacport, dacmini Потом научились

Cortex-M4..7 - в TI их множество разных модификаций (TIVA etc) По usb и Ethernet регистрам совместимы с старшими моделями
Линукс почти нигде не нужен такчто можно сделать контроллер и за доллар переместив софт сверху вниз
Кстати HyperMic2 и HyperMic16 работают без всякого Линукса А библиотеки TI по обьему и удобству сопоставимы с обьемом всех остальных embedded производителей Запада
( FreeScale, STM , Atmel etc) и Азии

Если бы вы упоминули QNX или POSIx цепочки под линуксом ( как делают для видео драйверов) тогда еще о чем то можно говорить А QT писали программисты ,
а embedded &realtime должны писать железячники , программистов гнать пинками

Сообщение отредактировал DSP_ACE - Jul 7 2016, 18:36

Ну так я и говорю, что копеечное дело, а вы - годы...

>Вам ни нафиг не нужна "аудиоплата". Вам нужно делать "устроство диагностики", а не заниматься изобретеним "аудиоплат" и их лобовым использованием. Так же, как не следует цепляться за какой-то конкретный интерфейс с компьютером.
>Более того для Вашей области применения тот-же USB есть последний вариант который следует рассматривать.

А может напрячься , и поключить плату 16 каналов (которую нигде нельзя купить и поэтому пришлось делать свою)
к одному из 2 стандартных интерфейсов - USB который есть в любом смартфоне нотбуке и лаптопе или десктопе
или wifi

Или может потратить деньги заказчика на создание собственного компа с экраном диском и тд чтобы подключить 16 микрофонов по
нестандартной шине?
А - вы видимо хотите создать свой смартфон и подключать ацп по serial портам внутри корпуса девайса
Думаю заказчик не станет платить лишнее за стандартное устройство - например планшет или смартфон Потому что у него он уже есть
Бывают и переборы в экономии Например фирма dji стала использовать внешний смартфон\планшет как наземный контроллер
В результате задержка передачи fullHD video 30fps составила 240 ms что смерть для управления коптерами В след версии они отказались
в пользу собственного контроллера Но в нашем случае задержка непричем поэтому только девайс пользователя и только стандартный интерфейс

А производить надо то чего у него нет - 16 каналов микрофонов в одном флаконе и диагностический софт

То есть продавать интеллект Впрочем , кому я это говорю?

>Ой! Дяденька "дИРЕКТОР" не надо!! Очень испугался!!![/quote]

Сообщение отредактировал DSP_ACE - Jul 7 2016, 12:59

А нафига? Платы для такого проекта - это мелочь.
Да и не должны интересовать инвестора никакие платы. Инвестора должен интересовать только профит.
Другой вопрос, что инвестору иногда приходиться погружаться в предметную область, чтобы в минус не упасть.
И вот тут у ТС как раз и наступят проблемы, т.к. нормальный инвестор определяет риски по большому числу факторов с самых разных сторон.



Вот именно.

Так а где интеллект?

16 микрофонов подключить по USB это не интеллект. Заюзать Audacity тем более.

Обработка?
Ну так вам надо вот в эту ветку - http://electronix.ru/forum/index.php?showtopic=134989
Посмотрим что вы можете действительно интеллектуального.

Копеечно дело контроллер
Софт совместимый с usb стандартом годы
Я занимаюсь usb c 2001 года
Спецификацию usb-midi освоил только в 2007 году
Спецификацию usb-auidio освоил только в 2014 году в полной мере

Когда сделаете первый usb девайс поймете о чем я
С bulk проблем нет
Какие то исходники по usb-audo play найдете в инете , но потом завязнете точно
По usb-record для ARM ничего нет , возможно коммерческая тайна, скорее всего придется писать с нуля по спецификации
Про usb audo class control message могу сказать это отлаживается только с hardware debagger



Верно 95% системы это дигностический софт
Однако многоканальный аудио ввод это тоже определенная проблема
Прежде всего если подключать несколько скажем 2-4 канальных USB ИЛИ FIREWIRE плат болтание фронтов или например переворот фазы на
180 градусов убивает полезную информацию Проходили это Даже джиттер клока сильно гробит особенно на спектрах видно
В общем все ацп должны сидеть на одно мастер клоке хорошо страссированном
Что то подобное делает фирма holophone.com, есть 8 каналка но очень дорого
В Штатах в 2005 году мы по их заказу сделали первую 6 канальную железку с управлением усилением по каждому микрофонному каналу кодом, но тогда не по audio class


Сообщение отредактировал DSP_ACE - Jul 7 2016, 12:56

Вам уже говорили, что это не проблема.
Для того, что бы поднять такую тему, надо думать о другом.
По моему опыту именно в этой области, шансы у Вас почти никакие.

А, так речь идет не о распознавании, а о локализации шумов?
Т.е. найти точные координаты точек излучающие звуки в объемной модели двигателя?
Так что ли?

Мне кажется начинать тогда надо с COMSOL-а и твердотельных моделей.



Как тут малый джиттер поможет если микрофоны будут располагаться на двигателе почти где попало в условиях гаража?

Спектральный анализ шумов это такая лабуда про которую пишет апноты чуть ли не каждый производитель акселерометров.
Вы этим хотите похвастаться?

Пожаоуйста внимательно читайте то что вам говорят

болтание фронтов или например переворот фазы на
180 градусов убивает полезную информацию Проходили это Даже джиттер клока сильно гробит особенно на спектрах видно
В общем все ацп должны сидеть на одно мастер клоке хорошо страссированном

И высказывайтесь только о том в чем вы специалист
Если вам специалист по акустике говорит что проблема, советую поверить
То что думать надо не только о железе и о программировании я сам знаю, в отличии от USA где я проработал 7 лет
Особенно здесь любят давать советы у кого за душой нет ни копейки

Сообщение отредактировал DSP_ACE - Jul 7 2016, 13:35

Эт чё, в древности значит умудрялись делать на разных клоках аудио-ацп?
И десяток мегагерц могли криво страссировать? На однослойке чтоль трассировали?

В наше время полагаю можно эту тему пропустить.

Так вы предлагаете работу , или предлагаете таки покупать ваши уникальные платы?

Вам работу не предлагаю к сожалению
своих хватает кто без работы сидит и понимает все с полуслова
Нужен владелец автосервиса с соотв образованием и готовый вложить деньги
Свои машины ( Вольво-940 и Cудзуки Гранд Витара 2.5 л) я записал
будет это дело постепенно расширяться
Жалко что когда я ставил на них контрактные моторы этой системы с микрофонами
еще не было создано Но сейчас двигатели от 100тк пробега будут изнашиваться будем писать призвуки



Сообщение отредактировал DSP_ACE - Jul 7 2016, 14:00