- Mac os iac driver
- Soundflower
- Audacity 2.0.5
- Audio MIDI Setup
- AU Lab Setup
- New Configuration
- Making the Changes Semi Permanent
- ChucK and MIDI
- Open Au Lab
- IAC Driver Bus 1
- DLSMusicDevice
- Quick ChucK MIDI Output Test
- Recording ChucK Audio
- Как вручную установить драйвер на MAC OS?
- Основы работы с IOKit. Тонкости программирования драйверов
- Экскурс в глубины теории
- Кое-что об IOKit
- Проба пера
- Сделаем что-нибудь полезное?
Mac os iac driver
Au Lab can be found in the course Common folder. Choose the version that corresponds to the Mac OS X version you are using. To install, drag the Au Lab icon into the /Applications folder.
Au Lab instructions below beginning with Audio MIDI Setup.
Soundflower
Soundflower was used in Lab 4, p. 41 ff. It describes a modified Au Lab setup to the one presented here.
Audacity 2.0.5
Audio MIDI Setup
Open Audio MIDI Setup
The Audio MIDI Setup (AMS) application is found in the /Applications/Utilities folder.
Shortcut: Apple-Shift-U in the Finder.
Choose Show MIDI Window from the Window menu if it is not already open.
You’ll need to create a new AMS configuration for yourself. Choose New Configuration from the Configuration popup menu.
Name the new configuration m208 and Click OK.
In the MIDI Studio window you’ll need to Activate the IAC (Inter Application Communication) Driver. In this picture it’s shown as a deactivated gray icon.
Double click the IAC Driver icon in the MIDI Studio window. Make sure the «Device is online» checkbox is checked.
Close the Window.
The IAC Device icon should be displayed in its active state (not grayed out). You may have to use the Confuguration popop menu and switch to Default and then back to m208 to see the change.
AU Lab Setup
Note: These screen shots are from Au Lab 2.2.1 running on Mac OS X 10.7.5.
If the following window does not appear skip to New Configuration from the File menu.
New Configuration
Click Create Document. An Untitled window will appear.
Choose Add Audio Unit Instrument from the Edit menu.
Make these settings n the dialog that appears:
- select the «IAC Driver’ or «Any MIDI Controller» for your MIDI Input Source
- select DLSMusicDevice for instrument.
The main AU Lab window has added a second Output strip .
and the Stereo Mix: DLSMusicDevice window will appear.
Choose MIDI Editor from the far right drop down menu.
The MIDI Editor window will appear.
Click and hold on Channel box 1 and drag the mouse to the right until channels 1-16 are selected.
Close the window by clicking the red button at the top left of the window.
Choose Save As from the File menu.
Making the Changes Semi Permanent
In the Save As dialog save this file as m208.trak.
Choose Preferences from the AU Lab menu.
Click the Documents tab in the Preferences dialog. Select the «Open a specific document:» radio button. Then click the Choose. button. When the File Open dialog appears, navigate to the YOUR_DRIVE. Select your AULabDLS.trak file and click Open.
Close Preferences. Quit and restart AuLab. The m208.trak file should open automatically with the correct settings.
ChucK and MIDI
Important: You must start AuLab before starting miniAudicle or Terminal if you’re running ChucK in the Terminal.
Open Au Lab
Open /Applications/Au Lab
Open Terminal and Type chuck —probe
At the end of the output you’ll see all MIDI inputs and outputs ChucK can find. In this case it found one input and two outputs.
IAC Driver Bus 1
Input and Output [0] use the IAC driver. IAC stands for Inter Application Communication and is part of MacOS. The IAC Driver allows you to connect ChucK to many commercial MIDI applications like GarageBand, LogicPro, Abelton Live, Reaktor, Reason, and others. ChucK can use this.
DLSMusicDevice
This is the General MIDI software synthesizer supplied by Apple and is part of MacOS. ChucK can use this.
Quick ChucK MIDI Output Test
Enter and run this code in miniAudicle.
Recording ChucK Audio
The above discussion only applies when ChucK is playing MIDI. When ChucK is generating audio you can use ChucK’s wvOut class as described in Lab 4, ABC Song.
Источник
Как вручную установить драйвер на MAC OS?
Перед установкой загрузите драйвер на ваш MAC и подключите адаптер к компьютеру.
Следуйте указанным ниже инструкциям:
1.Разархивируйте архив с драйвером и запустите установочный файл.
2.Появится предупреждающее сообщение (как на изображении ниже). Для решения проблемы перейдите в раздел «Системные настройки», выберите «Безопасность и конфиденциальность», затем нажмите кнопку «Открыть в любом случае» для идентификации драйвера.
Примечание: если у параметра «Разрешить приложения, загруженные из» стоит значение «отовсюду», предупреждающее сообщение не появится.
3.После идентификации драйвера последний будет установлен автоматически. Во время этого процесса появится окно авторизации учетной записи, введите имя пользователя и пароль, используемые в вашем компьютере MAC (если вы не знаете, что это такое и как их найти, обратитесь в службу поддержки компании Apple для получения помощи). После нажмите на кнопку «Установить программное обеспечение», чтобы продолжить процесс.
4.Теперь нажмите «Продолжить установку» и «Перезагрузка», чтобы завершить процесс установки.
5.После перезагрузки MAC нажмите на значок Wi-Fi «Открыть Wireless Utility», где вы можете выбрать свою Wi-Fi сеть и подключиться к ней. (Примечание: этот процесс может занять некоторое время, пожалуйста, ожидайте в течение примерно 1 мин.)
Теперь вы сможете воспользоваться сетью Wi-Fi.
Источник
Основы работы с IOKit. Тонкости программирования драйверов
В рамках поддержки блога разработки под Mac OS X, я представляю свою статью о низкоуровневой разработке под Mac OS X. Обычно тема разработки драйверов не столь популярна, однако и здесь Mac OS X выгодно выделяется из ряда прочих операционных систем. Да, писать драйвера для Mac O S X – просто! Проще чем когда-либо ранее!
Экскурс в глубины теории
Очень часто я слышу фразы, что Mac OS X – это Linux. Или же что OS X основано на ядре FreeBSD и посему драйвера легко портировать из одной системы в другую. А вот и нет! Очень часто концепция разработки под Mac OS X противоречит классическим принципам, к примеру вместо традиционных спин локов (spin lock) Apple предлагает использовать примитив IOCommandGate для синхронизации доступа. Также достаточно жестко регламентируется использование ядерной памяти. Примерный совет от Apple выглядит так: «Выделяйте столько памяти в ядре, сколько вам необходимо использовать и не байтом больше. Предпочитайте основную часть работы с большими буферами памяти переносить в пользовательский режим (user space)».
Сердцем, т.е. ядром, Mac OS X является XNU. XNU – это гибридное ядро, которое сочетает в себе множество преимуществ, а также недостатков, монолитных и микроядерных ОС. Собственно, XNU состоит из микроядра mach, разработанного институтом Карнеги Мелоуна, подсистемы Posix из BSD 4.3 (позже эта часть синхронизировалась с последней веткой FreeBSD, дописывалась самой Apple, а также 3-ми лицами), и объектно-ориентированного фреймворка IOKit, на который положена ответственность взаимодействовать с аппаратной частью Mac’ов. Стоит упомянуть, что ядро mach предоставляет операционной системе следующие сервисы: планировщик потоков и процессов, вытесняющую многозадачность (pre-emptive), механизм виртуальной памяти, защиту памяти, mach-IPC (через передачу сообщений), отладчик ядра.
Кое-что об IOKit
И так, что же из себя представляет IOKit? Как и многие другие наработки, IOKit – это наследие NeXT Computer (гениальные люди видимо работали в NeXT). IOKit – это объектно-ориентированный фреймворк реализующий драйверную модель Mac OS X. Написан IOKit на С++, вернее на его урезанной версии – Embedded C++ [1]. Проще говоря, это старый добрый С++ без множественного наследования, RTTI, шаблонов и исключений. Также в IOKit запрещается определять конструкторы и деструкторы классов. Впрочем, если очень хочется, то использовать можно все, кроме RTTI и исключений, но Apple за это вас по голове не погладит! Ранее IOKit был написан на Objective C, как и фреймворк Cocoa, и назывался Driver Kit. Однако, для упрощения разработки драйверов 3-ми лицами, Driver Kit переписали на C++. Впрочем, по словам одного из основных разработчиков IOKit, Годфри ван дер Линдена (Godfrey van der Linden), это решение было ошибочным. Тем не менее, в IOKit можно невооруженным взглядом увидеть наследие Objective C, к примеру механизм подсчета ссылок и retain/release, именование классов (приставки OS и IO), именование методов классов и многое другое. Еще один интересный факт: Godfrey van der Linden — студент университета Nicta, того самого австралийского НИИ, который открыл исследовательский проект Darbat [2].
Для того, чтобы приступить в делу вам достаточно установленного XCode SDK, собственно самого IDE XCode, а также Terminal.app для загрузки драйверов. При создании нового проекта, выберете Generic IOKit Driver и XCode создаст для вас пустой проект. Вам остается только добавить код драйвера, откомпилировать его, и загрузить с помощью следующих строк (предполагается, что драйвер называется SampleDriver.kext):
sudo chmod –R 0755 ./SampleDriver.kext
sudo chown –R root:wheel ./SampleDriver.kext
sudo kextload –t ./SampleDriver.kext
Как видно из вышеприведенных строк: загрузка драйвера выполняется с правами root с помощью сторонней программы kextload (из набора kext utils, который в свою очередь входит в xnu utils). Драйвер, как и любое приложение Mac OS X (за исключением простых консольных приложений), представляет из себя bundle, т.е. директорию в которой хранятся данные, которые непосредственно относятся к драйверу, а именно: Info.plist файл, файл с локализированными строками и конечно же сам бинарный файл драйвера (SampleDriver.kext/Contents/MacOS/SampleDriver). Также драйвер может содержать дополнительные ресурсы (SampleDriver.kext/Contents/Resources), либо другие драйверы (SampleDriver.kext/Contents/PlugIns).
IOKit в своей концепции активно эксплуатирует две парадигмы ООП: наследование и полиморфизм. Наследование позволяет уменьшить количество использованной ядерной памяти: любой IOKit драйвер, наследует определенный базовый класс, который специфичен для каждого стека устройств в системе. Например для драйверов LAN устройств – это IOEthernetController, WAN устройств – IO80211Controller, звуковых карт – IOAudioDevice и т.д. Механизм виртуальных функций, позволяет драйверу легко переопределить определенные методы базово класса, таким образом реализуя необходимую функциональность.
Проба пера
Любой класс в IOKit драйвере должен быть прямо или косвенно унаследован от класса OSObject. Этот класс обеспечивает подсчет ссылок, поддержку псевдо-RTTI за счет макросов и дополнительной метаинформации, примитивы для создания инстанса класса (перегруженный оператор new) в среде IOKit и многое другое. Самый простой IOKit класс выглядит следующим образом:
*.h файл:
class MyIOKitClass: public OSObject
<
OSDeclareDefaultStructors(MyIOKitClass)
public :
virtual bool init();
protected :
virtual void free()
private :
void *fSimpleMember;
*.cpp файл:
bool MyIOKitClass::init()
<
if (!OSObject::init())
return false ;
// TO-DO: Add basic initialization here
fSimpleMember = NULL;
return true ;
>
void MyIOKitClass::free()
<
// TO-DO: Add deinitialization code here
if (fSimpleMember)
<
// .
>
OSObject::free();
>
Наш класс MyIOKitClass унаследован от класса OSObject, в нем переопределены два метода:
- bool init() – данный метод будет вызван тогда, когда будет создан новый инстанс класса. В методе рекомендуется проводить начальную инициализацию полей класса, в общем все то, что вы бы сделали в конструкторе.
- void free() – данный метод будет вызван во время того, когда будет вызван последний release для экземпляра класса и его счетчик ссылок будет равен 0. Т.е. роль метода – деструктор класса.
Также в переопределенных методах необходимо вызывать методы класса-предка, для того, чтобы IOKit выполнял основную часть работы по инициализации/уничтожению инстанса класса за вас.
От OSObject могут быть унаследованы лишь вспомогательные классы, которые необходимы при реализации более крупной системы. Главный класс драйвера (да и любой другой класс, который претендует на то, чтобы предоставлять операционной системе определенные сервисы) прямо или косвенно наследуется от класса IOService.
IOService помогает реализовать в вашем драйвере поддержку Plug’n’Play, Power Management (организовывает взаимодействие с Power Domain операционной системы), взаимодействие с IORegistry и другими драйверами системы. Здесь следует также упомянуть про IORegistry – это не что иное, как динамическое дерево устройств Mac OS X. Строить это дерево начинает загрузчик ОС (boot loader), ядро ОС, а также вспомогательные драйвера. К примеру драйвер IOACPIPlatformExpert строит в IORegistry дерево всех PCI устройств в системе, основываясь на информации из ACPI таблиц, а также APIC контроллера прерываний.
IOService имеет два достаточно полезных метода, которые вам наверняка следует реализовывать в большинстве ваших драйверов:
- bool start( IOService *provider ) – данный метод будет вызван во время старта вашего драйвера. Здесь вы можете поместить код, который будет заниматься выделением ресурсов, необходимых драйверу.
- void stop( IOService *provider ) – этот метод будет вызван во время останова вашего драйвера.
В сигнатуре вышеприведенных методов, вы могли заметить параметр provider. И так, что же он значит, и для чего нужен? Все очень просто, как было сказано ранее, в Mac OS X существует динамический список устройств IORegistry. В нем существует связка наб-драйвер. Любой драйвер, может регистрировать в системе свои сервисы и делать их набами (nubs) для любых других драйверов. Итак, наб – это класс, который другой драйвер системы зарегистрировал в IORegistry, и теперь этот наб может быть передан как провайдер в ваш драйвер. К примеру, для драйверов PCI устройств набом является инстанс класса IOPCIDevice. Информация о набе, а также идентификаторы устройства задаются в Info.plist файле драйвера. Следующая секция Info.plist файла иллюстрирует этот прием (данный код был взят из моего сетевого драйвера):
dict >
key > Realtek RTL8111B/RTL8168 NIC key >
dict >
key > CFBundleIdentifier key >
string > rtl.r1000.nic.ext string >
key > IOClass key >
string > RealtekR1000 string >
key > IOPCIMatch key >
string > 0x816910ec 0x816710ec 0x816810ec 0x813610ec string >
key > IOProbeScore key >
integer > 500 integer >
key > IOProviderClass key >
string > IOPCIDevice string >
dict >
dict >
Опишем наиболее значимые параметры:
- IOProviderClass – указывает тип наба, который IOKit передаст в метод start нашего драйвера.
- IOClass – это имя класса нашего драйвера. Если обратится к нашему предыдущему примеру — это MyIOKitClass.
- CFBundleIdentifier – bundle идентификатор нашего драйвера, проще говоря этот параметр однозначно идентифицирует наш драйвер в системе.
- IOPCIMatch – список DeviceID-VendorID PCI устройств, которые будет обслуживать наш драйвер. К примеру возьмем 0x816810ec, 0x8168 – это DeviceID нашего сетевого контроллера, 0x10ec – это VendorID, в данном случае Realtek.
Остальные параметры – тема для еще одной статьи 😉 Примерный же код нашего метода start будет выглядеть так: bool RealtekR1000::start(IOService *provider)
<
if (!IOEthernetController::start(pciDev))
return false ;
IOPCIDevice *pciDev = NULL;
pciDev = OSDynamicCast(IOPCIDevice, provider);
if (!pciDev)
return false ;
pciDev->retain();
pciDev->open( this );
// Add initialization of device here
Я надеюсь, что данный код более-менее понятен для вас, добавлю лишь, что OSDynamicCast – это макрос, который заменяет отсутствие RTTI в IOKit за счет использования дополнительной метаинформации.
Сделаем что-нибудь полезное?
Все что вам необходимо сделать, чтобы создать свой сетевой драйвер:
- Создать скелет для драйвера, как было описано выше.
- Унаследовать класс драйвера от класса IOEthernetController.
- Переопределить необходимые методы в своем классе (всего около 10-12).
- Задать необходимые параметры в Info.plist файле.
И драйвер готов! Как видим, Mac OS X в очередной раз поражает нас изяществом. Здесь нет никаких огромных *.inf файлов, никакой системы минипортов, и прочих неочевидных вещей. Портирование драйвера для сетевого контроллера с Linux в Mac OS X заняло у меня около 7 дней, при том, что я должен был также освоить основы IOKit с нуля.
На этом этапе я намеряно делаю паузу до следующей статьи, если конечно же кому-то будет интересна данная тематика на хабре. Я опустил такие интересные вещи, как: Power Management, работа с IO портами и DMA, взаимодействие с user space и т.д. Желающим освоить IOKit могу порекомендовать начать с туторила IOKit Fundamentals [3], а заинтересованным – список тем о низкоуровневой разработке, которые им были бы наиболее интересны. Прошу оставлять свои отклики и пожелания 😉
Источник