Why are we rewriting the QNX RTP audio drivers?
By James MacMillan, QNX Software Systems Ltd.
Also available at
http://support.qnx.com/support/articles/nov092000/audiodrivers.html
As most of you probably have noticed from posts in the qdn.* newsgroups,
we’re in the midst of rewriting our audio drivers. I imagine that this has
confused some of you. In this article, I hope to explain our reasoning
behind this effort and to provide a glimpse into where we are now and where
we’re going.
The drivers that shipped with the QNX RTP prerelease are based on the ALSA
(Advanced Linux Sound Architecture) 0.5.2 sources
(http://www.alsa-project.org). The ALSA API provides highly detailed control
of the internals of a sound card. Many of the contributors are experts in
the field. However, we reevaluated ALSA’s suitability and were faced with a
number of issues that brought us to the decision to write our own drivers.
GPL and embedded systems
Chief among the issues was the GNU Public License (GPL). While the
open-source movement is rapidly gaining acceptance in the business world and
with the public in general, the embedded world has constraints above and
beyond those in the desktop arena. A number of our customers had expressed
concerns about sections of the license. To address these concerns we are
rewriting our drivers without GPL code.
Vortex and beyond
As a side effect of restarting without GPL, we’re in a much better position
to support our customers. Chip manufactures that require a Non-Disclosure
Agreement (NDA) are now accessible to us once again, and OEM’s can ship
products without the worry of GPL drivers. With the new drivers, we should
finally be able to release support for the Aureal Vortex chipsets. The
Vortex is only the first in a long line of chips that weren’t available to
us without an NDA.
Our drivers are resource managers
Being able to support NDAs isn’t the only advantage of the new drivers. The
GPL ALSA drivers, which were ported to QNX Neutrino, contain a lot of code
that adapted Linux system calls and structures. Our new drivers are native
QNX Neutrino resource managers. This makes for code that’s simpler, leaner,
and easier to understand. As a resource manager, each driver resides in its
own process space and uses QNX Neutrino’s fast message passing for
communication.
A move to consistency
We’re also striving to make the new drivers as consistent as possible. The
GPL ALSA drivers are still in a state of flux. In the time since we branched
from them, ALSA have redone most of their PCM and mixer functionality. The
PCM output paths and techniques are relatively consistent across all GPL
ALSA drivers, but other areas can vary widely. This is acceptable in a
development environment, but since we’re shipping released product,
consistency is required. Without consistency across all drivers, support and
documentation would be a nightmare and third-party applications would be
virtually impossible to create.
You won’t have to recode
It wouldn’t be fair to expect everyone to recode their applications to a
completely new API at this stage of the game, so we’re limiting the changes
as much as possible. Applications written to the GPL drivers shouldn’t break
on the new drivers, but they may bend a little. This is due in part to the
different structure of the internals of the drivers and also to correct
behaviors that are inconsistent with other QNX Neutrino drivers (e.g.
blocking on open() if no channel is available). Depending on your
application, there may be some benefits to restructuring and/or recoding,
but it shouldn’t be absolutely required.
