The big issue is since i'm using an ASIO driver Audion does not allow me to select Input or Output devices like it does with MME, so I am currently unable to use my headphones or blue yeti mic while recording. The laptops built in mic is still recognized and picks up sound. Is there any way to use these devices while also using asio. The package provides the installation files for Microsoft USB Input Device Driver version 10.0.4. If the driver is already installed on your system, updating (overwrite-installing) may fix various issues, add new functions, or just upgrade to the available version. Download drivers for Apple input device other devices (Windows 10 x64), or install DriverPack Solution software for automatic driver download and update. Are you tired of looking for the drivers for your devices? DriverPack Online will find and install the drivers you need automatically.

To write an input driver, you must first create your owninput module. The sample directory contains asample skeleton for creating a module. We recommend that youuse this as a starting point.

A module is represented by a data type calledinput_module_t. It contains various datafields and function pointers representing its interface.

input_module_t data type

Writing an input module consists of simply creating aninput_module_t representing your module andfilling in the relevant interface functions.

flags

Only one flag has been defined — MODULE_FLAG_INUSE, which indicates a valid module.

type

A combination (OR) of two descriptors:

• driver class:
  • DEVI_CLASS_KBD — keyboard
  • DEVI_CLASS_REL — relative
  • DEVI_CLASS_ABS — absolute
• driver layer that this module represents:
  • DEVI_MODULE_TYPE_FILTER — filter
  • DEVI_MODULE_TYPE_PROTO — protocol
  • DEVI_MODULE_TYPE_DEVICE — device

args

List of module parameters where each parameter isrepresented by a single character. If there's an optionalargument, the parameter has the format x: (the: means that the optional argument is expected).

data

Usually a pointer to a module's local data. This can beassigned in the init() module function.

In the sample directory

The code in the sample directory provides lots of commentsdetailing the steps required to initialize your module, andwhat to put in your module's functions.

You'll also find two modules:

• samp_dev — an example of a device module.
• samp_proto — the MS-mouse protocol code with lots of comments.

You'll also find a README file that providesfurther background info on how the system processes datafrom keyboard and absolute devices.

In many embedded systems, a combination device/protocolmodule is called for. For details, see the section on“Writing a combination device/protocol module”in this chapter.

Device modules can pass data in any format they want up toprotocol modules. But protocol modules must pass data ina specific format to filter modules.

This protocol module:	Must format data into a:
Keyboard	struct packet_kbd
Relative	struct packet_rel
Absolute	struct packet_abs

See the header <devi.h> for the format of these structures.All these structures have a timestamp field; you fill them inusing the library call clk_get().

When writing keyboard device modules, keep in mind that theprotocol/filter layers will expect make-and-break scan codesindicating when a key is pressed down and released. Theeasiest thing to do is to map the scan codes your devicesends to the standard PC scan codes. This way you won't haveto make any filter-layer changes — it will all justwork like a normal PC keyboard. Standard PC scan codes areavailable in any PC hardware book.

When passing up a struct packet_kbd to the filter layer, all youneed to do is:

1. Fill in the key_scan field of the struct _keyboard_datawith the scan code.
2. Fill in the flags field with KEY_SCAN_VALID.

The keyboard filter layer will read in a keyboarddefinition file and interpret the scan codes itreceives based on the contents of this file.

The keyboard definition files are typically kept in thelocation$PHOTON_PATH/keyboard, where$PHOTON_PATH depends on you systemconfiguration (e.g. this might be /usr/photon on your machine).In this directory there's a file calledsample.kdef, which provides a sample definition file. The .kdeffiles are compiled into .kbd files using the utilities kbcvtand mkkbd.

Both of these utilities are shipped with Photon for QNX 4.

You shouldn't have to play around with these mapping filesvery much if you map your scan codes appropriately. The onlyplace where you might need to modify these files is if your keyboardhas special keys. In this case, you would start with a standard definitionfile (e.g. en_US_101.kdef), and add your uniquescan codes.

When the driver starts up and initializes the keyboard filter module,the module will try to load in a mapping definition file.It uses the following algorithm to look for the file:

1. The module tries to open the keyboard configuration file/etc/system/trap/.KEYBOARD.If this file exists, the module just reads thekeyboard filename from it.
2. If the keyboard mapping filename is empty, the moduletries to take it from the KBD environmentvariable.
3. If the keyboard mapping filename is still empty, themodule assigns the standard US keyboard definition file(en_US_101.kbd) to it.
4. The module tries to find this file in the %PHOTON%/keyboard directory.
5. If the PHOTON environment variable isn'tdefined, the module tries to open it in the /usr/photon/keyboard directory.

The elo directory contains an example of atouchscreen protocol module.

Absolute devices (e.g. touchscreens) need to be calibrated.They typically generate “raw” coordinates thatmust be translated into actual screen coordinates. Thescreen coordinates they're translated into depend on thescreen resolution.

The device/protocol layer module receives raw coordinates fromthe touchscreen device, formats a packet_abs structure, and passes itup to the absolute filter.

The absolute filter module takes care of translating rawcoordinates into screen coordinates. To do this, the moduletries to locate and read in a calibration file on startup via:

1. Command-line option to the absolute filter (-ffilename)
2. ABSF environment variable
3. /etc/system/config/calib.hostname

Calibration file format

The format of this file is as follows:

where:

XL

X screen coordinate of upper left side (typically 0).

YL

Y screen coordinate of upper left side (typically 0).

XH

X screen coordinate of lower right side (typically X screen resolution − 1).

YH

Y screen coordinate of lower right side (typically Y screen resolution − 1).

XRL

Raw touchscreen X coordinate at upper left side.

XRH

Raw touchscreen X coordinate at lower right side.

YRL

Raw touchscreen Y coordinate at upper left side.

YRH

Raw touchscreen Y coordinate at lower right size.

SWAP

Whether to swap X or Y axes (0 is no, 1 is yes.) It's safe to leave this as 0.

This calibration file is typically generated by the Photontouchscreen calibration application, calib.When the utility starts, it sends a message to the devi- driver asking it to switch toraw mode, and then solicits coordinate info by asking the user totouch the screen at all four corners and the middle. Afterdoing this, calib formats the absf file, sends acalibration message to the devi-* driver, and writes the file.

The hirun directory contains examples of amouse device (kb.c) and protocol (msoft.c, ps2.s, msys.c) modules.

Since these modules cover all the main types of relativedevices, you probably won't need to develop something newfrom scratch. If you need to implement support for anydevice that's not completely supported by this driver, youcan simply copy the files from this directory into a new oneand modify them.

Note that Microsoft and Mouse Systems class devices don't have a device module — they justuse /dev/serN to get raw data from a serial communication port.A PS/2 mouse shares the 8042 controller device driver (kb.c) with a standardkeyboard.

The protocol layer module receives raw coordinates fromthe mouse, formats a packet_rel structure, andthen passes it up to the relative filter.

The relative filter module implements an accelerationalgorithm, converts raw data received from the protocollevel according to the current speed parameter, and emitsthis data in the form of events to Photon.

The main part of developing a new module involvesimplementing several standard callback functions, combined“under the roof” of the module's instance ofthe input_module_t structure.

Consider implementing the following callbacks:

init()

Should be called for a one-time initialization of amodule's state after it's loaded.

reset()

Used to reset a module's and/or device's state. Youwould call it when the module is linked into an event busline; if necessary, it could be called from your code as areaction to any sort of device trouble.

input()

You usually implement this callback function in protocolmodules as part of the device-to-interface data channel.

output()

Usually called by higher-layer modules asking for datato be sent to the device. You can use this callback forpassing commands to control an input device.

pulse()

Usually implemented in device class modules. Thiscallback is automatically activated each time that aregistered interrupt handler wants to notify a device moduleabout input activity.

parm()

Called by the Input Runtime System to parse anycommand-line parameters given to the module.

devctrl()

Used by modules in an event bus line to send commands toeach other. This callback may also be called as a responseto the external devctl() call. You can use thiscallback for reconfiguring a driver on the fly.

shutdown()

Called when the Input Runtime System is shutting down.

Which callbacks are required?

To decide which callback functions should be implemented ina module, you'll need to consider the module's purpose. Ingeneral, a device module must have the followingfunctions:

• pulse() (if it doesn't use an interrupt handler)
• init()
• parm()
• devctrl()

A protocol module, in turn, must have at least theinput() function (and optionallyinit(), parm(), anddevctrl()).

Callback sequence

At startup, the Input Runtime System always calls a module'scallback functions in the following sequence:

init() → parm() → reset()

If you're writing a driver for a custom type of device whereit doesn't make sense to split up the functionality ofdevice and protocol, you can write acombination module.

To do this, you simply proceed as you would when writing a“normal” driver: fill in your callbacks, talkto your device, interpret its protocol, etc.

In addition, there are two things you have to do:

1. In the type field, put in DEVI_MODULE_TYPE_DEVICE | DEVI_MODULE_TYPE_PROTOin addition to the DEVI_CLASS_ manifest.
2. When you've interpreted the data from your device,package up a struct packet_* (depending onyour class of device) and send it up.

Ultima Input Devices Driver Device

Because the devi-* framework is multithreaded,you should be aware of a possible reentrancy issue. When adevi-* driver is invoked, a module may bespecified multiple times, where each invocation will belongto a separate event bus line.

An example is the keyboard controller device module(kb). This module can communicate with akeyboard and with a PS/2 mouse. We would invoke the driveras follows:

Here we'll have two event bus lines: one for the keyboard andone for the mouse. Upon initialization, the input frameworkwill use the static kb data structure (input_module_t) for one ofthe bus lines and dynamically allocate/copy another one for theother bus line.

If you keep your module-specific data confinedto the private data member of the module structure, you won't haveany problems with reentrancy. But if your module contains globalvariables, then you'll have to use some sort of mutual exclusionmechanism for protection.

Note that you don't have to ensure that theinit(), reset(), and parm()callbacks are reentrant, because they're always called froma single thread upon initialization. (However, if for somereason you need to call them when the runtime system is up,then you'd have to ensure that they're reentrant.) Thecallbacks used at runtime (e.g. the pulse()callback) are the ones at risk.

For more information, see the keyboard controller module code (hirun/kb.c).

-->

Application programs rely on a combination of user-mode and kernel-mode components to capture (input) and render (output) wave streams. A wave stream is a digital-audio stream whose data format is described by a WAVEFORMATEX or WAVEFORMATEXTENSIBLE structure.

An application can use either of the following software interfaces for wave rendering and capture:

• Microsoft Windows Multimedia waveOutXxx and waveInXxx functions

• DirectSound and DirectSoundCapture APIs

The behavior of the waveOutXxx and waveInXxx functions is based on the capabilities of legacy wave drivers and devices. Beginning with Windows 98, the WDMAud system driver translates calls to these functions into commands to WDM audio drivers. However, by emulating the behavior of older software and hardware, the waveOutXxx functions sacrifice the 3-D sound effects and hardware acceleration that are now available through the DirectSound API. For more information about DirectSound and the Windows Multimedia wave functions, see the Microsoft Windows SDK documentation.

DirectSound and the Windows Multimedia wave functions are clients of the SysAudio system driver, which builds the audio filter graphs that process the wave and DirectSound streams. Graph building is transparent to the applications that use these software interfaces.

Wave Components

The following figure shows the user-mode and kernel-mode components that a wave application uses to render or capture a digital audio stream consisting of wave PCM data.

The rendering components appear on the left side of the preceding figure, and the capture components appear on the right. The boxes representing the wave miniport driver are darkened to indicate that these are vendor-supplied components. The other components in the figure are system-supplied.

At the top left of the figure, the wave-rendering (or 'wave-out') application interfaces to the WDM audio drivers through the waveOutXxx functions, which are implemented in the user-mode WinMM system component, Winmm.dll. The application reads blocks of wave audio samples from a file and calls the waveOutWrite function to render them.

WDMAud, which consists of both user-mode and kernel-mode components (Wdmaud.drv and Wdmaud.sys), buffers the wave data from the waveOutWrite call and outputs the wave stream to the KMixer system driver, which appears below WDMAud in the figure.

KMixer is a system component that receives wave PCM streams from one or more sources and mixes them together to form a single output stream, which is also in wave PCM format.

KMixer outputs a wave stream to a WaveCyclic or WavePci device, whose port and miniport drivers appear below KMixer on the left side of the preceding figure. The miniport driver binds itself to the port driver to form the wave filter that represents the underlying audio rendering device. A typical rendering device outputs an analog signal that drives a set of speakers or an external audio unit. A rendering device might also output digital audio through an S/PDIF connector. For more information about WaveCyclic and WavePci, see Wave Filters.

Alternatively, KMixer can pass its output stream to a USB audio device, which is controlled by the USBAudio class system driver (not shown in figure), instead of a WaveCyclic or WavePci device.

An adapter driver creates an instance of a WaveCyclic or WavePci port driver by calling PcNewPort with a GUID value of CLSID_PortWaveCyclic or CLSID_PortWavePci, respectively.

The right side of the preceding figure shows the components that are needed to support an application that captures wave data to a file. The wave-capture (or 'wave-in') application communicates with the WDM audio drivers through the waveInXxx functions, which are implemented in the WinMM system component.

At the lower right corner of the figure, the wave-capture device is controlled by wave miniport and port drivers. The port and miniport drivers, which can be of type WaveCyclic or WavePci, bind together to form a wave filter that represents the capture device. This device typically captures an analog signal from a microphone or other audio source and converts it to a wave PCM stream. The device might also input a digital audio stream through an S/PDIF connector.

Ultima Input Devices Driver Updater

The wave port driver outputs its wave stream either to KMixer or to WDMAud directly. The stream must pass through KMixer if it needs to be sample-rate converted before WDMAud receives it. A system that performs simultaneous rendering and capture of audio streams might require two instances of KMixer, as shown in the figure. Note that SysAudio automatically creates these instances as they are needed.

Alternatively, the source of the captured wave stream can be a USB audio device instead of a WaveCyclic or WavePci device. In this case, the USBAudio driver (not shown in figure) passes the stream to KMixer.

Regardless of whether the wave stream is captured by a USB device or by a WaveCyclic or WavePci device, KMixer performs sample-rate conversion on the stream, if needed, but does no mixing with other streams. KMixer outputs the resulting stream to Wdmaud.sys, the kernel-mode half of the WDMAud system driver. The user-mode half, Wdmaud.drv, outputs the wave stream to the application program through the waveInXxx functions, which are implemented in Winmm.dll. Finally, at the top of the figure, the wave-capture application writes the wave data to a file.

At the time that the wave-capture application calls the waveInOpen function to open the capture stream, it passes in a pointer to its callback routine. When a wave-capture event occurs, the operating system calls the callback routine with a buffer containing the next block of wave samples from the capture device. In response to the callback, the application writes the next block of wave data to the file.

DirectSound Components

The following figure shows the user-mode and kernel-mode components that are used by a DirectSound application program to render or capture wave data.

The rendering components are shown in the left half of the preceding figure, and the capture components appear on the right. The wave miniport drivers are shown as darkened boxes to indicate that they are vendor-supplied components. The other components in the figure are system-supplied.

At the top left of the figure, a DirectSound application loads wave data from a file to a sound buffer that the user-mode DirectSound system component (Dsound.dll) manages. This component sends a wave stream to a WaveCyclic or WavePci device, whose port and miniport drivers appear at the lower left in the figure. If a hardware mixer pin is available on the device, the stream passes directly to the wave port driver, bypassing KMixer. Otherwise, the stream first passes through KMixer, which mixes it with any other simultaneously playing streams. KMixer outputs the mixed stream to the port driver.

As before, the miniport driver binds itself to the port driver to form the wave filter that represents the underlying audio rendering device. This device might play the stream through a set of speakers, for example.

Alternatively, the wave stream can be rendered by a USB audio device instead of a WaveCyclic or WavePci device. In this case, the stream cannot bypass KMixer; the USBAudio class system driver (not shown in figure) always passes the stream to KMixer.

The right side of the preceding figure shows the components that support a DirectSoundCapture application. The application records wave data that is receives from a WaveCyclic or WavePci capture device. This device converts an analog signal from a microphone, for example, to a wave stream. The device's wave port and miniport drivers appear at the lower-right corner of the figure. As shown in the figure, the port driver receives as input the stream from the miniport driver and outputs it either directly to the user-mode DirectSound component, Dsound.dll, or indirectly through KMixer. This depends on whether a hardware capture pin is available from the capture device.

Alternatively, the source of the captured wave stream can be a USB audio device. In this case, the stream cannot bypass KMixer; the USBAudio driver (not shown in figure) always passes the stream to KMixer.

If KMixer is inserted into the path of the capture stream, it performs sample-rate conversion on the stream, if needed, but does no mixing with other streams.

At the top-right corner of the preceding figure, the application reads the wave data from the DirectSoundCapture buffer and writes it to the file.