Creation of an Object Model and Object Oriented API for
the Windows mLAN Driver
Shaun Miles
Computer Science Honours, Rhodes University
Supervisor: Prof. R. Foss
Abstract
This short paper is serves the purpose of exposing the inner-workings of the Windows music Local Area
Network (mLAN) driver to aid in further research of the mLAN system. mLAN represents an innovative
environment for networked high-speed transmission of real-time audio and MIDI streams. An exploration
of the mLAN architecture and the Windows Driver Model gives us insight into the core concepts central
to the creation of the mLAN driver. This understanding will be expressed by developing an object model
of the mLAN driver.
1. Introduction
Prompt and on time delivery of data is the
cornerstone of any real-time system. In a
professional environment, such as a music studio,
the precise delivery of audio data dictates the
speed (and to an extent, the success) of the
project. Legacy studios are an array of equipment
and a mass of analogue and digital audio cables.
Configuring the studio becomes a task unto its
own, time consuming and complex. The
assortment of analogue and digital cables depends
on the nature of the equipment used, representing
a number of different formats of transmitting
audio and control data. mLAN provides a
scalable high-performance real-time audio
network system, which allows the digital transfer
of audio and control data.
This short paper takes a brief look at the mLAN
system and other topics relevant to development
of a Windows Driver. A look at the concepts
inherent to the development of the mLAN system
will take place in the next section. Exploring the
underlying mLAN architecture will set the
context for the mLAN driver. A brief summary of
relevant concepts of the Windows Driver Model
will help to give the needed background to
understand what the mLAN driver accomplishes.
This will all help in explaining a high-level object
Page 1 of 6
model of the mLAN driver. With this as a base to
understanding the structure of the mLAN driver,
there will be a description of the nature of the IO
Control (IOCTL) codes.
2. The music Local Area Network (mLAN)
Architecture
Yamaha began developing a system to proved
single cable connections between the arrays of
standard audio studio equipment in an attempt to
1394 (Firewire) was chosen as the foundation on
top of which to build the mLAN system, for it
addressed the many aspects required of the
proposed system. The mLAN system can operate
independently of a central server or a host
controller, not requiring the use or the power of a
computer. Responsibility of management and
control of the bus is automatic and falls to
selected nodes on the bus. Using the computer as
a tool to visually model the bus and to manage
the connection of nodes extends the functionality
of the mLAN system.
2.1 IEEE 1394
IEEE 1394 is a specification that defines a serial
bus architecture with a common set of core
features that is an extension to the Control and
Status Registers (CSR) architecture [Anderson,
Creation of an Object Model and Object Oriented API for the Windows mLAN Driver
1999]. The CSR is a standard definition to permit
easier implementation of software, and allows
interoperability between Firewire on different
platforms. It is based on the ISO/IEC 13213
specification that standardises the offset locations
within the initial register address space. The CSR
specifies the arrangement of an addressable space
range containing data structures that identify the
components of the bus, be it a bus, a bridge or a
node, the components state and other information.
Features responsible for the usage of Firewire as
the mLAN system are as follows:
 High speed bus with scalable performance
The throughput speed of the bus satisfies
the high bandwidth of any real-time audio
processing system, allowing a network of
many devices capable of transmitting and
receiving streams of audio data.
 Plug and play support
The bus orchestrates the automatic
configuration of newly added devices.
Each time a device is added or removed
the bus automatically re-enumerates itself,
forming a new bus topology. This is done
independently
and
without
the
intervention of a host system.
 Eliminate host processor/memory bottleneck
Processing any amount of multimedia data
requires a robust system to handle the
large and time-dependant flow of data. By
eliminating the need for a central server
the bus is free to automatically direct the
transfer of data between the devices,
thereby removing a potential bottleneck.
This is supported by the use of peer-topeer transactions
 Support for Isochronous data streams
Firewire provides support for isochronous
packet streaming, satisfying the need for a
constant transfer rate in an audio system.
This is a high-priority transfer mode that
guarantees delivery of data at constant
rate.
2.2 The mLAN extension
The mLAN system extends the IEEE 1394 CSR
architecture by implementing several different
registers and by using a series of application level
Page 2 of 6
chips [AE Notes, 2005]. The chips, ASICs
(Application Specific Integrated Chips), provide
an interface between the IEEE 1394 node and the
studio equipment. They also control the transfer
bit-rate, the encapsulation and extraction of audio
and MIDI data into sequences, and the
construction of the Common Isochronous
Protocol (CIP) packets. These CIP packets
(comprising a CIP header and several CIP data
blocks) make up the payload data of the
isochronous packets that in turn form the
isochronous streams. The CIP formatting is based
on the IEC 61883-1 specification for data flow
and connection management [AE Notes, 2005].
The payload of the CIP packet is the AM824 (8
bit label and 24 bit Audio/Music data) block
format given by the IEC 61883-6 specification.
The CIP header contains data that provides a
mechanism for synchronising the reassembly of
the audio/music data.
The isochronous packets are constructed by the
IEEE 1394 node Link Layer. Packets are
identified by a channel number that has a single
corresponding stream. Each packet within a
stream comprises several data blocks, which are
made up of a number of quadlets (4-byte blocks)
[AE Notes, 2005]. Sequences are designated by
the series of quadlets corresponding to a position
in each data block of that packet. Sequences and
plugs are core to the functionality of the mLAN
system, in that each sequence is issued from an
output plug and gathered by an input plug [AE
Notes, 2005]. A plug is an abstraction formed by
the Enabler, representing the input and output
capabilities of the studio equipment. The Enabler
is software on the computer that interacts with the
Transporters (device-specific enumeration of the
plugs) and allows connection a management. It is
the plugs that the studio equipment can send and
receive data on the bus.
A computer must have a driver to know how to
interface to any attached hardware device. IEEE
1394 is a bus, such that each device on the bus is
seen as a node. A host controller (the card that
allows the computer to connect to the bus) must
appear as a node in order for the computer to
interact with the bus [McKenzie, 2003]. The
computer’s host controller must have an IEEE
Creation of an Object Model and Object Oriented API for the Windows mLAN Driver
1394 driver in order to interact with the computer.
Microsoft ships low level drivers for all the major
device and bus types for the vendor-supplied
drivers to make use of. These vendor drivers form
client drivers that provide access to the vendor
specific functionality of the device. The Windows
mLAN driver is a client Firewire driver that
makes use of the Windows supplied IEEE 1394
driver. The mLAN driver is able to manipulate
the Unit Directory of the host controller via the
underlying IEEE 1394 driver to make it appear as
a mLAN device.
operations on underlying physical devices or
busses connected to the device. Once again, the
miniport driver is tailored for vendor specific
operations. The hardware bus driver is supplied
by Microsoft and should not be replaced.
3. Windows Driver Model
The Windows Driver Model (WDM) is a
framework for designing and developing drivers
for NT based Windows platforms. WDM drivers
have well-defined responsibilities in facilitating
I/O operations for applications and other drivers
[Oney, 1999].
The core concept of the WDM is the driver stack.
According to Oney, the Windows operating
system comes with base drivers that take care of
generic I/O operations for standard hardware
devices. In this architecture, a driver is supported
by a chain of other drivers below it. The layered
approach is such that at each level of the stack a
driver in that stack has the opportunity to act on a
request being sent down. If the driver cannot
fulfil the request it will pass the request down the
stack until the request can be satisfied. The results
are then passed back up the stack and back to the
application that made the request. This approach
allows drivers to focus on a small area of
functionality and specialisation [Oney, 2003].
Figure 1 illustrates a hypothetical driver stack,
showing the different types of drivers a stack
could have. The kernel-mode client driver
handles requests from an application via the
Win32 API. The class driver, usually supplied by
Microsoft, provides the system-required but
hardware-independent support for a class of
device. The miniclass driver is usually supplied
by the hardware vendor to integrate any unique
functionality their device may have. The port
driver (or in some cases, the host controller or
host adapter driver) supplies required I/O
Page 3 of 6
Figure 1: Layered Driver Architecture [MSDN,
2005]
3.1 Driver structure and the Operating System
Within the kernel of the Windows operating
system there are components that monitor and
allocate system resources as they are required
[MSDN, 2005]. These components are
responsible for the running of the operating
system. Figure 2 is a functional overview of a
driver representing the three entry points into the
driver. The kernel (actor) in the Use Case
Creation of an Object Model and Object Oriented API for the Windows mLAN Driver
diagram comprises the relevant components used
in dealing with drivers. The use cases Manage
Driver and Manage Devices encapsulate the
specific functionality of the driver and
enumerated devices.
the AddDevice routine of the driver. The driver
requests system resources via a system call to
create the device object and is returned a pointer
to the newly created device object. The device
object is stored in the driver allocated memory
space and is used as a means to interface with the
device
3.2 Driver communication
Figure 2: Driver Use Case Diagram [Oney, 2003]
When the OS detects a new Plug and Play device
the PnP manager determines which drivers are
required to support that device and loads those
drivers [Cant, 1999]. Devices are identified by an
electronic signature specifying the device ID and
its Vendor. It is the PnP manager that enumerates
all the OS attached devices. Kernel-mode drivers
form part of the kernel, in that they occupy
allocated system memory and are represented
through the use of system created objects. The
IO manager creates a driver object that represents
the driver. The driver object is assigned system
memory for it to store driver related objects and
information, and becomes responsible for any
device it was loaded for.
It is the IO manager that is responsible for
communicating with the driver and their devices
[MSDN, 2005]. Every driver has WDM defined
entry points that the IO manager can call to
communicate with the driver. A pointer to the
driver object is passed to the driver as a parameter
when it is loaded through a routine called
DriverEntry. Any initialisation of the driver takes
place here. Now that the driver is up and running
it is free to be acted upon by the OS. The newly
detected device must be enumerated by calling
Page 4 of 6
The last entry point routine is an IO Request
Packet (IRP) dispatch routine. The IO manager
communicates with the driver by issuing it IRPs.
IRPs are essentially data structures that contain
certain fields, defining the type of action to be
performed. There are fields which allow for the
transportation of data that is need in servicing the
request. The results can be accessed via similar
fields. Each IRP has an action defined by a
function code. There are two types of function
codes for an action. One is a major function code
which indicates the main action, while the minor
function code further specifies the action. The
IRP is dispatched to IRP handler routines
depending on the function code.
Any user-mode application must make use of the
WIN32 API to access the functionality of any
hardware device provided by its driver [MSDN,
2005]. Applications can interact with a driver by
specifying a custom or a device-specific IO
Control (IOCTL) code. The IOCTL codes expose
the functionality of the driver (i.e. control over
the device) to the application or the operating
system. The IO manager receives this request
from the application then builds and allocates
memory for the IRP. The IRP is passed to the
relevant driver stack. The driver will have handler
routines for the different IOCTL codes.
4. Object Model for the mLAN Driver
The Windows mLAN driver makes use of a
proprietary Driver Development Environment
called DriverStudio from Compuware. This
provides an object oriented driver framework that
conforms to and encapsulates the concepts
inherent in the WDM. The framework is a
collection of objects and classes that form a
foundation and a skeleton for the quick and
Creation of an Object Model and Object Oriented API for the Windows mLAN Driver
efficient development of a driver. The classes and
objects are built specifically to closely model the
WDM architecture. The classes that driver writers
use to derive their own classes for their drivers
contain functionality and resources to allow for
the integration of the driver into the framework.
The objects provide functionality to allow for the
ease of working with the data structures within
the driver context. The purpose of the framework
is to provide a model for the communication
between the different components, which
encapsulates the flow of data required to facilitate
the functioning of the driver. It also reduces the
amount of general work that must done for any
driver, and it handles the more mundane matters
of writing a driver. This leaves the development
team to focus on the specific functionality they
wish to implement.
Figure 3: Object Model of mLAN Bus Driver
Figure 3 represents a high level overview of the
mLAN driver within context of the DriverStudio
framework classes.
The main bus driver is created from the
CmLanBusDriver class by the PnP manager,
derived from the KDriver class. CmLanBusDriver
contains the entry routines to the driver code;
DriverEntry is called when the driver is first
loaded by the system, AddDevice is called when a
new device is detected, and any IRP is sent to the
Page 5 of 6
DispatchFilter routine. An IRP is always directed
to a targeted device object so the dispatch routine
will know where to send the IRP.
A device object is created from the class
CmLanBus, derived from KDevice and
KPnpDevice. This object represents the
functionality of the device by implementing the
IRP and IOCTL handler routines. It is within the
IRP and IOCTL handler routines that the driver
provides its core functionality. A driver can only
respond to system initiated events, never on
accord of its own [MSDN, 2005]. A new device
is created when it is detected and has an
electronic signature that corresponds to those
specified by the driver’s INF file. Conforming to
the WDM, the driver object keeps track of the
device objects under its control. Furthermore, the
device object must connect to the driver below it
in the stack. This is achieved by using an
abstraction of a “lower device” object which
represents the target of further IO requests. In
this case, the lower device object represents the
IEEE 1394 driver that is responsible for access to
the Firewire bus.
The mLAN driver makes use of WDM Streaming
Minidrivers to control and interpret the streams
between the mLAN-node devices on the Firewire
bus. The mLAN driver uses a minidriver to
control an isochronous data stream between the
nodes. This makes use of the Kernel Streaming
architecture, which allows the processing of
streaming data. The DriverStudio framework
encapsulates the WDM Streaming architecture,
allowing the classes to represent the streams and
their respective adapters. These minidrivers fall
under the control of the mLAN bus driver.
5. Object Oriented API for the IOCTL calls
The developer of an application has to have
knowledge of the IOCTL codes and the data
structures it takes as parameters. It is unusual for
the driver source code to be available to the
public, and so access to the device is given
through an API that makes use of the IOCTL
codes. Through the creation of an object model of
the mLAN driver, the understanding of the innerworkings of the driver is established. It is then
Creation of an Object Model and Object Oriented API for the Windows mLAN Driver
possible to modify or expose the IOCTL calls to a
general API. This will allow the development of
applications to fully explore the nature of the
mLAN system.
On the application side, a WIN32 API call
DeviceIoControl is made, passing parameters (a
handle to the device, the IOCTL code, and other
fields specifying the input/output buffers and file
access), and using the buffers to pass information
pertinent to the IOCTL code. An API would
abstract the IOCTL codes and take care of the
necessary parameters. API’s are as useful as their
documentation. This entails specifying the input
and output parameters, and the context of
operation it represents.
The IOCTL codes used by the mLAN driver are
custom in their design, sporting function code
enumerations within the custom range. mLAN’s
implementations of these IOCTL codes span
different realms of usage. There are certain
IOCTL codes in place for communication
between the driver and the mLAN WDM
Streaming minidrivers. Other codes refer to the
underlying usage of the IEEE 1394 and IEC
61883-6 drivers.
5.1 Intended Work
In order to develop an API, complete
documentation of the IOCTL codes must be done.
This involves documenting the data structures
used to store information relevant to handling of
the IOCTL. This in turn involves understanding
the purpose of the IOCTL, and excluding those
that are for the internal communication between
drivers. This understanding will be portrayed
through the use of sequence diagrams.
6. Conclusion
any computer technology, understanding the
inner workings of the system is a prerequisite for
insightful progress. By creating the object model
of the Windows mLAN driver, it becomes
possible to ascertain the functionality contained
within the IOCTL code handler routine. By
implementing custom IOCTL codes and its
handler routine, it becomes possible to extend the
mLAN driver.
7. References
[Anderson, 1999] Anderson, D. FireWire System
Architecture: IEEE1394a, 2nd Edition,
Mindshare Inc., Addison-Wesley, 1999
[AE Notes, 2005] Audio Engineering Course
Notes, 2005
[Cant, 1999] Cant, C. Writing Windows WDM
Device Drivers, R&D Books, Lawrence, 1999
[DriverStudio, 2004] Compuware Corporation,
DriverStudio Version 3.2, 2004
[McKenzie, 2003] McKenzie, B. 1394 NodeTargeted Asynchronous Transfers [Online]
http://www.wd-3.com/archive/
1394NodeTransfers.htm, 2003
[MSDN, 2005] Microsoft Developers Network
(MSDN) Library, April 2005
[Oney, 1999] Oney, W. Programming the
Microsoft Windows Driver Model, Microsoft
Press, Washington, 1999
[Oney, 2003] Oney, W. Programming the
Microsoft Windows Driver Model, 2nd Edition, EBOOK 2003
In dealing with the IEEE 1394 bus architecture, it
becomes immediately apparent about the
correctness in the choice of the foundation for the
mLAN system. Coupling high-performance and
scalability, mLAN sets the basis for any real-time
multimedia system to follow. To support that
claim, further investigation into the potential of
the mLAN system must be carried out. As with
Page 6 of 6
Creation of an Object Model and Object Oriented API for the Windows mLAN Driver