Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Decoupling audio device interrupts
1.2. Name of Document Author/Supplier:
Author: Garrett D'Amore
1.3 Date of This Document:
11 December, 2009
4. Technical Description
Abstract
We propose to move processing of the audio data (that performed by
audio_consume() and audio_produce()) from device interrupts to a regular
framework internal periodic function. There are changes to the Boomer DDI
(PSARC 2008/318) as a result.
Detail
Historically, the audio framework (both the legacy SADA framework and Boomer)
have used device-driven interrupts to drive processing of audio data. While
this has worked very well, it turns out that there can be challenges from
this as different devices have different interrupt needs, and driving the
mixing framework from a device interrupt makes the framework subject to the
interrupt requirements of the device. Ultimately, this either prevents, or
makes much more difficult, some of the changes we would like to make for
virtualization, Sun Ray, and automatic hotplug in the future.
It turns out that the nature of audio data is that the streaming data
moves at a regular fixed rate. So we are able to drive use a timer-driven
event instead of a device specific interrupt to perform our internal
audio processing.
This also lets us decouple the rate at which the audio framework processes
audio data from from any configuration requirements of the device. (There
are still some minor requirements... the device must be able to pre-buffer
at least enough audio data to cover one and a half periodic intervals, and
the device must be able to report its DMA position. Additionally, if the
device needs deeper buffering, it must report that to the framework via
the audio_engine_playahead(9E) entry point in its audio_engine_ops vector.
It turns out that for most devices, we are simply able to remove all hardware
interrupt handling, eliminating about 20% of the code complexity for most
typical AC'97 drivers.
Initially, we are using a ddi_periodic (see ddi_periodic_add) to drive
the internal framework. This limits us to a 10 msec granularity/latency.
In the future, we might investigate other options to use higher resolution
clocking and lower latencies. (The use of ddi_periodic's is a framework
internal detail, and not necessarily intrinsic to this case.)
DDI Changes
The audio_engine_open() entry point in the audio_engine_ops vector is
changed to have the following signature:
int (*audio_engine_open)(void *state, int flags, uint_t *nframesp,
caddr_t *buf);
The nframesp argument is new, and is the total number of frames that buf
can hold. (It replaces the former nfragsp and fragframesp members, which
used to report the individual fragment size and total number of fragments.
With this change, the audio framework has no need to know if the engine
fragments data into regular blocks, nor any of said details. The framework
is totally decoupled from this particular set of device details with this
change.)
We also have removed the audio_engine_consume() and audio_engine_produce()
functions. Device drivers no longer have any need to trigger this
functionality.
Finally, we have bumped the value AUDIO_ENGINE_VERSION to 2. While the
changes to the DDI are only being made to Consolidation Private interfaces,
this prevents someone from trying to mix-and-match old devices with the
new framework. (Generally they would not load anyway, due to a failure
to resolve the audio_engine_produce or audio_engine_consume symbols, but
this just makes it absolutely certain.)
As with the previous Boomer DDI, these interfaces remain Consolidation
Private.
Release Binding
We are seeking Patch binding for these changes, dependent upon Boomer (PSARC
2008/318). While the Boomer case was integrated with Minor binding, and while
we are dependent on Boomer, there is some risk that an actual minor release
may be cut with Boomer before this change is integrated. In such an
event, we believe it would be approriate for the changes described here
to be integrated in a patch to such a release.
Note that this case explicitly does _not_ seek to alter the original
commitment of Boomer, so it would not be appropriate to deliver this
as a patch to a release that did not already have Boomer integrated.
(I.e. it would not be appropriate to backport this to Solaris 10.)
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
