Разработка WDM Audio драйвера для Аудио Девайса
356 USDПроект имеет несколько стадий и будет дополнительно оценён после согласования с исполнителем ТЗ!
Существует разработанный с нуля Аудио Девайс (Звуковая Карта) использующий для транспорта цифровых аудио данный и управления - TCP/IP Ethernet.
Для девайса написан ASIO драйвер и Контролер управления под Windows, но написан в Юзерс Спэйс, не в Ядре.
В данный момент ASIO драйвер переписывается как мультиклиентный - т.е. пишется ASIO Server и Client.
Будет необходимо - переписать ASIO Server в ядро операционки и написать к этому же девайсу WDM драйвер
PS: Регион нахождения Фрилансера обозначен как Украина, Киев - но это только пожелание, не требование -
с грамотным и подготовленным человеком готовы сотрудничать в не зависимости от места его нахождения, у нас уже команда интернациональная!
На сколько я понимаю, то это и не совсем драйвера, так как они не будут работать с аппаратной частью девайса - только с цифровыми данными поступающими на сокет и в него передающиеся, хотя запускать их нужно именно как драйвера.
Код, который получает и передает данные от девайса (девайсов) в саму серверную часть - там простой, и его даст автор самой технологии. Это для WDM-драйвера. Как писать сам WDM-драйвер звуковой подсистемы - это програмист должен знать. Но ввод-вывод именно данных - не его проблема.
Что касается переноса серверной части ASIO в ядро - то там, в общем-то, должно быть достаточно просто все (она ведь уже написана в юзерс спэйсе) - там работа с сокетами, shared memory, примитивами синхронизации Windows и ничего больше. Никакой прямой работы с аппаратной частью там нет.
сокеты в ядре отличаются по интерфейсу и всему прочему от сокетов в режиме пользователя (который уже реализован).
Т.е. делают-то то же самое, но способы работы другие. Так что это нужно тоже знать.
-
15 days356 USD
141 15 days356 USD
Здравствуйте, готов выполнить заказ.
Быстро и качественно.
Опыт работы есть.
-
Заменить категорию Прикладное программирование на Системное программирование будет нелишним: ваш проект - один из немногих, который в эту категорию идеально вписывается 🙂
-
Спасибо! Попробую сделать
-
Изменил
-
А конкретнее, под какую windows нужно писать драйвер? Давно не писал в ring0
С тех пор и драйвера уже вынесли то из нулевого кольца, на сколько я знаю. Но написать в ядро это крутая мысль... Очень крутая.
Я не в Киеве и с профессиональным аудио оборудованием никогда не сталкивался. Соответственно кроме всего прочего ещё и об ASIO имею самое смутное представление. Но люблю вникать в новое. Если не пугает очень длительное написание то буду рад. О задаче имею представление где начинать искать. Это и интересно ))
-
А почему не думали, если это требует максимум производительности, написать простенькую серверную ОС, с минимальным функционалом и упором на конкретное железо? Может быть проще на самом деле. Функционал конечно будет не такой разнообразный как у готовой ОС, но я так понимаю цель обработка конкретно звука на лету и максимум производительности именно на это. Надо хорошо подумать. Писать в ядро готовой ОС со своими требованиями по безопасности или написать новую без поддержки лишних устройст.. магический ring0 заставляет задуматься о смысле жизни..
-
Программы, которые нужно написать, должны работать начиная с Windows 7 и выше.
На сколько я понимаю, то это и не совсем драйвера, так как они не будут работать с аппаратной частью девайса - только с цифровыми данными поступающими на сокет и в него передающиеся, хотя запускать их нужно именно как драйвера.
Код, который получает и передает данные от девайса (девайсов) в саму серверную часть - там простой, и его даст автор самой технологии. Это для WDM-драйвера. Как писать сам WDM-драйвер звуковой подсистемы - это програмист должен знать. Но ввод-вывод именно данных - не его проблема.
Что касается переноса серверной части ASIO в ядро - то там, в общем-то, должно быть достаточно просто все (она ведь уже написана в юзерс спэйсе) - там работа с сокетами, shared memory, примитивами синхронизации Windows и ничего больше. Никакой прямой работы с аппаратной частью там нет. -
Созданный Аудио Девайс будет работать со стандартными операционками и так называемыми - DAW (Digital Audio Workstation) - Так что писать собственную ОС под это нельзя.
Кстати, подд Mac OS - Core Audio драйвер уже написан и проходит отладку. -
А через сетевую будет проходить (проходят) битрейты которые нужно только передать куда надо и все? Дополнительно (кодировка/обработка/не знаю что бывает) у этой части не требуется?
Почему выбор на TCP/IP а не UDP или хотя бы "голый" TCP? Где подвох ?
Какая пропускная способность требуется при передаче данных (в штуках одновременно подключившихся клиентов)?
Реализация сетевой части отдельно от аудио рассматртвается?
-
Я уже писал выше -
код, который получает и передает данные в саму серверную часть - уже есть!
Так что и передавать ни чего не нужно и тем более не нужна кодировка/обработка/и т.д.
Почему TCP/IP а не UDP - потому как UDP протокол передачи данных без подтверждения, а нам ОБЯЗАТЕЛЬНО нужно чтоб данные дошли. Чтоб это реализовать с UDP нужно писать свою систему подтверждений, что сведёт на нет все преимущества UDP.
Наша технология гарантирует доставку Аудио данных до 32-х кратного перепосылания не дошедших. При этом это очень низколатенсный интерфейс, который по производительности УЖЕ догнал Аудио Девайсы работающие на PCI-Expres-е. -
WDM то WDM.. задача ж не заставить пищать карту за 0,5$ мешок без претензий по качеству. Можно хорошо облажаться если никогда не сталкивался с очень схожей задачей. Что касается опускать работу с сетевой картой на уровень ядра (я правильно понял? WDM с кольца пользователя то туда никак не запихнем) то вопрос а действительно ли надо? Сокеты это уже работа через драйвер. Это не ядро. Ring1, ring2 но не ядро. С другой стороны тоже вопрос - сокеты позволяют пропускать трафик без проблем с большой скоростью и гигантским колличеством единовременных соединений. Сейчас как раз пишу такой многопоточный TCP сервер задача которого не принимать и удерживать кучу входящих подключений а именно обслуживать (устанавливать порарные соединения через сервер)
-
Пишу как службу. Не драйвер.
-
Интересная задача. А какая задержка у Вас сейчас получается, например, от аналогового входа, или прихода в DAW сообщения от MIDI до аналогового выхода? С учётом хотя-бы одного перезапроса по TCP, хотя-бы без промежуточных свитчей и роутеров. И какую задержку вы хотели бы получить, переписывая драйвер для ядра?
Зависит ли эта задержка от сетевого адаптера, его драйвера, реализации TCP в ОС?
-
Ну MIDI тут не при чём, MIDI живёт отдельным потоком...
А вот раундтрип AD/DA сейчас минимальный могу показать -
-
MIDI-звук когда-то синтезировался аудио-картами. Сейчас - только ЦП через DAW или специальный программный синтезатор. И задержка от нажатия клавиши до появления звука очень важна. Без ASIO или JACK играть невозможно.
Да, задержка 78 сэмплов впечатляет. Сравнима с собственной задержкой фильтров в кодеке. Это без TCP-перезапросов?
-
По поводу midi - он тоже есть на борту и тоже передаётся по тому-же TCP/IP.
MIDI передаётся от внешних клавиш через наш девайс в DAW (не через ASIO конечно) и там в VSTi инструменте формируется уже аудио и далше через ASIO в сокет и Ethernet на наш девайс и на DA.
Задержка тут считается как время прихода midi сообщения в DAW (не могу точно его назвать, так как его очень сложно померять, но MIDI тот ещё тормоз, как протокол), ну а потом это ASIO буфер + Tail буфер и около 6 сэмплов на DA.
С TCP перезапросами, перепосылами - тут всё организованно вот как -
поскольку ЗАПИСЬ это СВЯТОЕ и потерять какую то часть записи на ответственном концерте или в студии - это преступление, сделан механизм при котором, даже если пакет (кстати он по 8 сэмплов) не дойдёт, девайс его будет ещё 32 раза пробовать доставить - и тут понятно, что доставка опоздает на это кол-во пакетов. А вот воспроизведение, ну или директ мониторинг через DAW - будет с артефактами в этом месте.
Но поскольку ЗАПИСЬ важнее во много раз - сделано вот так.
Ну и потом - по факту мы же видим (есть мониторинг дропаутов) и слышим эти дропауты в звуке и можем поднимать буфер до ситуации, когда всё в полном порядке - механизм перепосыла для всякого рода ЧП. -
78 сэмплов это не предел.
Если комп мощный, то можно и вот так -
-
Желание переписать ASIO сервер в ядро не продиктованно необходимостью ещё меньшей задержки, она и так сравнима с PCI-Expres Audio картами RME - лидиром на рынке Pro Audio. Это желание продиктованно необходимостью повышения стабильности работы, особенно в условиях мультиклиентных решений.
Ну и, если честно, мы ещё не тестировали как следует ИМЕННО мультиклиентный ASIO, он только только сшивается в то, что можно тестировать кому-то кроме разработчика. Но даже если всё будет ОК - хотим, чтобы ASIO сервер работал в ядре операционки.
Ну и - всё равно очень нужен WDM драйвер. -
Что касается свичей, роутеров, эзернет адаптеров и прочего -
чем "глупее" и дешевле свич - тем лучше, роутер ставить между девайсами и компами (решение у нас ведь сетевое и как девайсов наших, так и компов, работающих с ними - может быть много) не желательно - в них много всякого, с чем прийдётся разбираться, что влияет на риалтайм, эзернет карты - самые обычные, но мы их твикаем немного (что, кстати, тормозит работу с Core Audio - Так как Apple умнее всех на свете и не даёт доступ ни к каким настрокам аппаратным эзенет карт).
-
Меня, на самом деле, Ваше решение интересует, не как исполнителя, а как пользователя. USB даже с хабами сильно далеко не провести, а Ethernet даёт ещё и бесплатную гальваническую развязку на обоих концах.
-
Присоединяюсь. Сам бы взялся но просто много как для меня узких мест, где я не уверен что справлюсь быстро или адекватно (потому что долго буду разбираться и опыты ставить, а попросту - учиться под конкретные задачи), но сам проект просто блеск. Восхищает и вызывает уважение.
-
Игорь, а может всё же глянете исходники того, что написанно в Юзер Спейсе?
Имею в виду ASIO сервер.
Может не так страшен чёрт как его малюют?
Где-то в течении недели ASIO сервер будет причёсан... -
Страшно в данном случае подвести. Действительно страшно. Так же как и ваш программист, я смогу рано или поздно это сделать. Но так же это с ходу будет не быстро. Только ваш уже это прощупал и прочувствовал а я начну разбирать сначала. Хотя глянуть не откажусь. Интересно.
А про wdm вы таки думаю очень правы и если вопрос что под конкретной ОС что то не так, то тоже думаю вопрос решается переписыванием wdm драйвера и в ядро лезть не придется хотя бы на первых парах...
Но и тут НО - это ж не pc-спикер пищать джаз заставить... с какого раза я напишу лучше чем есть тоже большой вопрос, а опыта в этом и нет.
Исходники гляну с удовольствием. Хоть опыт визуальный приобрету и узнаю что такое ASIO чуть больше чем просто "слышал что есть"
-
ОК, мой партнер закончит работу и я вас сведу вместе - а вдруг там не так и страшно все для вас будет.
-
Девайс уже проходит стадию Тестирования... Мы сделали можно сказать - действующий макет... Кстати, тут нашли и дизайнера в команду.
-
Девайс красавец. Хоть на моей рабочей машине и колонок то нет.. ну не слушаю я звуки. Девайс шикарно выглядит.
-
Около полутора десятков девайсов разосланы звукорежам и музыкантам в разные страны..., уже имеем фидбэки, которые нас радуют, но и заставляют двигаться дальше.
-
Кстати, Александр, я вижу вы из Питера?
В Питере сейчас два наших девайса проходят тестирование. 🙂 -
Я бы глянул. А у кого?
На второй картинке задержка в мс такая-же.
Для живой записи задержки действительно не принципиальны. А вот воспроизведение без ошибок и с задержкой <5 мс как-раз таки очень важно именно при игре через MIDI. Во вторую очередь - при послойной записи, когда музыкант мониторит сигнал уже с эффектами.
А Вы не пробовали просто удвоить или утроить UDP-пакеты? Каналов то у Вас не так много, и пропускной способности хватит на всех. В сетях такое явление бывает, и стандартный драйвер UDP-аудио-потока вполне с этим может справиться. В итоге можно получить компромисс между задержкой и помехоустойчивостью соединения.
PCIe работает с перезапросами, но они делаются аппаратно на каждом физическом соединении в дереве мостов и конечных устройств. USB-audio работает без перезапросов, зато все кодеки, подключённые к одному мастеру, работают строго синхронно, и каналы легко наращивать. А как обстоят дела с синхронностью по Ethernet?
-
Я узнаю как обстоят дела с тестированием на сегодня в Питере и отпишу.
Один из девайсов на студии Мелодия.
По второй картинке - а вы обратите внимание на частоту дискретизации.
Задержки принципиальны еще для живой игры через программную обработку , и не только миди, а и аудио....
По поводу UDP и кол-ва каналов -
Так у нас ведь подключаешь 20 таких девайсов и все каналы в одном ASIO драйвере и видишь.... так что пакеты будут по 8 сэмплов и не сэмплом больше.
Синхронизация у нас устроена по принципу - кто первый встал, того и тапки.
Мастер Клок в сети всегда один из девайсов, и если его выключили - тут же станет мастером другой.
-
В общем, за драйвер скорее всего не возьмусь - давно не брал в руки шашек, да и про виндовс почти забыл, разбираться с ASIO буду не меньше месяца. Но если Вам понадобится разработка аппаратной части, или DSP, обращайтесь.
-
Спасибо
-
Current freelance projects in the category C & C++
Reverse engineering of console utilities for querying SSD controllers (Flash ID)1. Purpose of the work Extraction of the application programming interface (API) for interaction with SSD/NVMe controllers from the provided set of console utilities (Phison, Silicon Motion, Realtek, Maxiotek, Marvell, JMicron, etc.). The result should be working code in C/C++… C & C++, Desktop Apps ∙ 7 days 8 hours back ∙ 6 proposals |
Development of a Minecraft Java Seed Map / Seed Viewer for the websiteDevelopment of Minecraft Java Seed Map / Seed Viewer for the websiteProject Description A browser-based tool Minecraft Java Seed Map / Seed Viewer needs to be developed, which will work on our website and allow the user to enter a seed from Minecraft Java Edition and view an… C & C++, HTML & CSS ∙ 7 days 15 hours back ∙ 15 proposals |
Comparative analysis of the effectiveness of custom software (v2.2-field) and reference software (Meshtastic v2.x)
22 USD
Comparative analysis of the effectiveness of custom software (v2.2-field) and reference software (Meshtastic v2.x) on the identical hardware platform (ESP32 + SX1268, 2W) based on the criteria of range, throughput, link stability, and power consumption. Conduct tests with… C & C++, C# ∙ 11 days 22 hours back ∙ 2 proposals |
Kyiv