Wdm драйвер что это
Фирма Steinberg опубликовала спецификации технологии драйверов ASIO 2.0 и формата подключаемых модулей VST 2.0.
Технология ASIO (Audio Stream Input Output) была создана для улучшения работы многоканальных устройств и снижения времени ожидания (latency). В версии 2.0 добавлен механизм синхронизации с точностью до семпла при работе с цифровым интерфейсом формата ADAT, стало возможным одновременное использование нескольких программ с одним устройством, появилась возможность прямого мониторинга (с нулевым временем ожидания) любого входа через любой выход.
В версии 2.0 формата VST количество используемых модулем параметров увеличено до 16 и стало возможным управление параметрами посредством MIDI. Последнее позволяет, например, создание программных синтезаторов и семплеров, управление временем задержки в зависимости от темпа. Возможна самостоятельная адаптация модуля к условиям использования (стерео или моно, в зависимости от установки в разрыв или в посыл-возврат). Появилась возможность ввода параметров с клавиатуры. Вместе с SDK прилагается библиотека интерфейсов. Разработчики могут получить SDK и другие необходимые материалы для ASIO 2.0 и VST 2.0 на сайте Steinberg.
romVsen
Member
2 D FORM: миди здесь почти совсем не причем (с миди клавиатурой можно будет работать в секвенсоре при выборе любого стандарта).
Если просто то: ASIO по сравнению с WDM - более продвинутый и быстрый интерфейс общения с аудио железом. Подробности - на официальных сайтах.
D FORM
New Member
Reason 3,5 - Edit / Preferences / Audio / Audio Card Driver : (ASIO Creative ASIO) - "Control Panel" button / ASIO Bufer Latency : 4ms (try from 2ms to 10ms) Enjoy !
FL Studio 6,3 - Options / Audio Settings / Output: ( Creative ASIO ) - "Show ASIO Panel" button / ASIO Bufer Latency : 4ms (try from 2ms to 10ms) Enjoy !
Reason с данными настройками работает отлично. FL Studio - тот ещё фрукт , ругается ,что не может работать с 44100 KHZ,но всё равно работает . Если во Фрутике драйвер "Creative ASIO"не пойдёт ,пробуй заменить его на "Creative Audigy 2 ASIO [FCCO]" , или на "Creative Audigy 2 ASIO 24/96 [FCCO]" Enjoy !
В другом софте не пробовал ,ну разве что в Sony ACID 6, а с остальными прогами думаю тоже проблем не будет. Картёха у нас отличная ! Особенно радует WAVами отрендерёнными на 192 KHZ - Обалденная глубина у звука появляется и обьём . Хоть эта карточка не позиционируется как Профессиональное Решение для Звукозаписивающих студий - но, ЗАПИСь у неё - отпад ! Возможно её не внесли в список PRO устройств только по одной причине - Басы - уж больно они богатенькие (Геймерско-киношные) на мой взгляд Хотя это вполне регулируется. Surround Sound - отдельный разговор - можно кончить в процессе создания трека Ну в общем понятно в каком я восторге.
В данной статье описан процесс написания простейшего драйвера, который выводит скан-коды нажатых клавиш.
Также в данной статье описан процесс настройки рабочего места для написания драйверов.
Если Вам интересно, прошу под кат.
Подготовка стенда
Установка необходимого ПО для написания простейшего драйвера
- Windows DDK (Driver Development Kit);
- VMware Workstation или Virtual Box;
- Windows XP;
- Visual Studio 2005;
- DDKWizard;
- KmdManager
- DebugView;
Настройка рабочего места
Установка DDK
Установка предельно проста. Единственное на что необходимо обратить внимание — это диалог, в котором Вам предлагается выбрать компоненты, которые будут установлены. Настоятельно рекомендую отметить всю документацию и примеры.
Установка и настройка Microsoft® Visual Studio 2005
Установка Microsoft® Visual Studio 2005 ничем не сложнее установки DDK. Если Вы будете использовать её только для написания драйверов, то когда инсталлятор спросит какие компоненты необходимо установить, выберите только Visual C++.
Далее можно установить Visual Assist X. С помощью этой программы (аддона) можно будет легко настроить подсказки для удобного написания драйверов.
После установки Visual Assist X в Visual Studio 2005 появится новое меню VAssistX. Далее в этом меню: Visual Assist X Options -> Projects -> C/C++ Directories -> Platform: Custom, Show Directories for: Stable include files . Нажимаем Ins или на иконку добавить новую директорию и в появившейся строке, если у вас Windows XP вписываем %WXPBASE%\inc\ddk\wxp .
Установка и настройка DDKWizard
- Создать системные (рекомендуется) или пользовательские переменные со следующими именами и значением, которое соответствует пути к DDK
Версия DDK Имя переменной Путь по умолчанию Windows XP DDK WXPBASE C:\WINDDK\2600 Windows 2003 Server DDK WNETBASE C:\WINDDK\3790.1830 Windows Vista/Windows 2008 Server WDK WLHBASE Windows 7/Windows 2008 Server R2 WDK W7BASE
Например, если я использую Windows XP DDK, то я должен создать переменную WXPBASE со значением, которое соответствует пути к DDK. Так как я не изменял путь установки, то значение у меня будет C:\WINDDK\2600. - Скопируйте скачанный скрипт ddkbuild.cmd, например, в папку с DDK. У меня это C:\WINDDK\.
- Добавьте в конец системной переменной Path путь к скрипту ddkbuild.cmd.
Установка необходимого ПО для запуска драйверов
- DebugView (link) — это утилитка, которая позволяет просматривать отладочный вывод как режима пользователя так и режима ядра.
- KmdManager (link) — утилита динамической загрузки/выгрузки драйверов
Постановка задачи
Задача: написать драйвер, который будет выводить в дебаг скан-коды нажатых клавиш и их комбинаций.
Немного теории
- драйверы классов;
- минидрайверы;
- функциональные драйверы;
- фильтрующие драйверы.
Необязательно определять все возожные функции в своем драйвере, но он обязательно должен содержать DriverEntry и AddDevice .
IRP — это структура, которая используется драйверами для обмена данными.
- верхние фильтрующие драйверы;
- нижние фильтрующие драйверы.
Отличия между верхними и нижними фильтрующими драйверами
Через верхние фильтрующие драйверы проходят все запросы, а это значит, что они могут изменять и/или фильтровать информацию, идущую к функциональному драйверу, ну и далее, возможно, к устройству.
Пример использования верхних фильтрующих драйверов:
Фильтр-хук драйвер, который устанавливает свою хук-функцию для системного драйвера IpFilterDirver, для отслеживания и фильтрации траффика. Такие драйверы используются в брандмауэрах.
Через нижние фильтрующие драйверы проходит меньше запросов потому что большинство запросов выполняет и завершает функциональный драйвер.
Проблемы синхронизации
В драйвере, который мы будем писать, есть несколько «проблемных» секций. Для нашего драйвера вполне достаточно использования ассемблерных вставок:
Префикс lock позволяет безопасно выполнить идущую за ним команду. Она блокирует остальные процессоры, пока выполняется команда.
Экшен
Для начала необходимо включить заголовочные файлы «ntddk.h», «ntddkbd.h»
Также необходимо описать структуру DEVICE_EXTENSION
Объект pLowerDO это объект устройства, который находится ниже нас в стеке. Он нужен нам для того чтобы знать кому дальше отправлять IRP-пакеты.
Еще для работы нашего драйвера нам нужна переменная, в которой будет храниться количество не завершенных запросов.
Начнем с функции, которая является главной точкой входа нашего драйвера.
theDriverObject – объект драйвера, содержит указатели на все необходимые операционной системе функции, которые мы должны будем инициализировать.
ustrRegistryPath – имя раздела в реестре, где хранится информация о данном драйвере.
Для начала необходимо объявить и обнулить переменные:
Далее, как я и писал выше, нужно инициализировать указатели на функции
Функция DispatchRead будет обрабатывать запросы на чтение. Она будет вызываться, когда нажата или отпущена клавиша клавиатуры.
Функция DriverUnload вызывается, когда драйвер уже не нужен и его можно выгрузить из памяти, или когда пользователь сам выгружает драйвер. В данной функции должна производиться «зачистка», т.е. освобождаться ресурсы, которые использовались драйвером, завершаться все незавершенные запросы и т.д.
Функция DispatchThru это функция-заглушка. Все что она делает это передача IRP-пакета следующему драйверу (драйверу который находится под нашим в стеке, т.е. pLowerDO из DEVICE_EXTENSION ).
Далее мы вызываем нашу функцию, для создания и установки нашего устройства в стек устройств:
Эту функцию я опишу чуть ниже.
Возвращаем status , в котором, если функция InstallFilter завершилась удачей, хранится значение STATUS_SUCCESS .
Переходим к функции InstallFilter . Вот её прототип:
Эта функция создает объект устройства, настраивает его и включает в стек устройств поверх \\Device\\KeyboardClass0
pKeyboardDevice – это объект устройсва, которое мы должны создать.
Вызываем IoCreateDevice для создания нового устройства
- Первый аргумент это объект драйвера, который мы получили как параметр функции InstallFilter. Он передается в IoCreateDevice для того чтобы установить связь между нашим драйвером и новым устройством.
- Третий параметр это имя устройства
- Четвертый параметр это тип устройства
- Пятый параметр это флаги, которые обычно устанавливаются для запоминающих устройств.
- Шестой параметр описывает можно ли открывать манипуляторы устройства в количестве больше одного. Если FALSE можно открыть только один манипулятор. Иначе можно открыть любое количество манипуляторов.
- Седьмой параметр это память, в которой будем сохранен созданный объект устройства.
Флаги, которые мы устанавливаем для нашего устройства, должны быть эквивалентными флагам устройства, поверх которого мы включаемся в стек.
Далее мы должны выполнить преобразования имени устройства, которое мы включаем в стек.
Функция IoAttachDevice внедряет наше устройство в стек. В pdx->pLowerDO будет храниться объект следующего (нижнего) устройства.
Далее разберем функцию DispatchRead с прототипом:
Данная функция будет вызываться операционной системой при нажатии или отпускании клавиши клавиатуры
Увеличиваем счетчик незавершенных запросов
Перед тем как передать запрос следующему драйверу мы должны настроить указатель стека для драйвера. IoCopyCurrentIrpStackLocationToNext копирует участок памяти, который принадлежит текущему драйверу, в область памяти следующего драйвера.
Когда запрос идет вниз по стеку в нем еще нет нужных нам данных, поэтому мы должны задать функцию, которая вызовется, когда запрос будет идти вверх по стеку с нужными нам данными.
где ReadCompletionRoutine наша функция.
Передаем IRP следующему драйверу:
Теперь разберем функцию, которая будет вызываться каждый раз при завершении IRP . Прототип:
Структура PKEYBOARD_INPUT_DATA используется для описания нажатой клавиши.
Проверяем, удачно завершен запрос или нет
Чтобы достать структуру KEYBOARD_INPUT_DATA нужно обратиться к системному буферу IRP -пакета.
Узнаем количество клавиш
И выводим каждую клавишу:
И не забываем уменьшать количество не обработанных запросов
Возвращаем статус запроса
Разберем функцию завершения работы. Прототип:
Извлекаем устройство из стека:
Проверяем есть незавершенные запросы или нет. Если мы выгрузим драйвер без этой проверки, при первом нажатии на клавишу после выгрузки будет БСоД.
Как запустить драйвер и просмотреть отладочную информацию
Для запуска драйвера я использовал утилиту KmdManager. Для просмотра отладочной информации использовалась утилита DbgView.
P. S. Статью писал давно, ещё на третьем курсе, сейчас уже почти ничего не помню. Но если есть вопросы, постараюсь ответить.
P. P. S. Прошу обратить внимание на комментарии, в частности на этот
There are three kinds of WDM drivers: bus drivers, function drivers, and filter drivers.
- A bus driver drives an individual I/O bus device and provides per-slot functionality that is device-independent. Bus drivers also detect and report child devices that are connected to the bus.
- A function driver drives an individual device.
- A filter driver filters I/O requests for a device, a class of devices, or a bus.
In this context, a bus is any device to which other physical, logical, or virtual devices are attached; a bus includes traditional buses such as SCSI and PCI, as well as parallel ports, serial ports, and i8042 ports.
It is important for driver developers to understand the different kinds of WDM drivers and to know which kind of driver they are writing. For example, whether a driver handles each Plug and Play IRP and how to handle such IRPs depends on what kind of driver is being written (bus driver, function driver, or filter driver).
The following figure shows the relationship between the bus driver, function driver, and filter drivers for a device.
Each device typically has a bus driver for the parent I/O bus, a function driver for the device, and zero or more filter drivers for the device. A driver design that requires many filter drivers does not yield optimal performance.
The drivers in the previous figure are the following:
A bus driver services a bus controller, adapter, or bridge. Bus drivers are required drivers; there is one bus driver for each type of bus on a machine. Microsoft provides bus drivers for most common buses. IHVs and OEMs can provide other bus drivers.
A bus filter driver typically adds value to a bus and is supplied by Microsoft or a system OEM. There can be any number of bus filter drivers for a bus.
Lower-level filter drivers typically modify the behavior of device hardware. They are optional and are typically supplied by IHVs. There can be any number of lower-level filter drivers for a device.
A function driver is the main driver for a device. A function driver is typically written by the device vendor and is required (unless the device is being used in raw mode).
Upper-level filter drivers typically provide added-value features for a device. They are optional and are typically provided by IHVs.
The following topics describe the three general types of WDM drivers—bus drivers, function drivers, filter drivers—in detail. Also included is an example of WDM driver layering that uses sample USB drivers.
This section discusses the Microsoft Windows Driver Model (WDM) architecture. This architecture started in Windows 2000 as an enhancement to previous Windows NT device drivers.
Note Drivers for versions of Windows NT-based operating systems before Windows 2000 are not supported, and you should update these drivers. The WDM architecture does not support drivers for non-Windows NT-based operating systems (such as Windows 98), and you should rewrite such drivers.
This section is divided into three parts:
Windows Driver Model describes the Windows Driver Model (WDM), including types of WDM drivers, device configuration, and WDM versioning.
Device Objects and Device Stacks describes device objects and device stacks. The section includes information about physical device objects (PDOs), functional device objects (FDOs), and filter device objects (filter DOs). Drivers are often built from a set of device objects that work together. This set of device objects is called a stack. Stacks can help you understand the flow of information to and from a driver and how different parts of the driver communicate internally.
Kernel-Mode Driver Components describes which routines you must implement to have a functional driver and which routines are optional.
A device driver is a set of software code that must integrate into the operating system. To complete this integration, you must write a set of handler routines in your driver that process calls from the operating system. These routines can be simple function calls, but many of them implement the processing of I/O request packets (IRPs), which facilitate communication between drivers and the operating system.
Note WDM drivers can also use the Windows Driver Frameworks (WDF) library to make some parts of a device driver easier to write. Specifically, kernel-mode drivers can use the Kernel-Mode Driver Framework (KMDF), which is part of WDF. For more information about KMDF for kernel-mode drivers, see Kernel-Mode Driver Framework Overview. Note that KMDF does not replace WDM. You must still understand many parts of WDM to write a KMDF driver.
Читайте также: