MP safe audio framework and drivers

[Andrew Doran <ad%netbsd.org@localhost>]

Hi,

Someone asked me to post about this. There is work on the ad-audiomp branch
to make the audio subsystem MP safe. The branch is really, really out of
date but a lot of the changes should apply to -current if a diff is
extracted from it.

Reasons to make the drivers MP safe:

- Audio interrupts are sensitive to latency, since we have to provide the
  card with the next block of memory to record/play as soon as possible,
  otherwise the human may notice glitches. Because the interrupt handlers
  currently need kernel_lock, they cannot run above the priority level
  IPL_VM. If they didn't need the global lock, we could push them up to
  IPL_SCHED which would cut back the potential for latency.

- Again for reasons of latency, kernel_lock is a problem because it means
  audio ISRs have to compete with code from different subsystems for the
  lock. If you have a broken bit of code that can hold the lock for seconds
  at a time (eg LFS), then your audio playback is shot.

- It would be the first signficant inroad we make into MP safe device
  drivers.

The basic strategy on the branch is:

- splaudio() calls are replaced with a spin mutex (intr_lock)
- an adaptive mutex covers all ops originating from /dev/audiofoo (lock)

Each audio driver has a bunch of methods that they provide to the MI audio
framework. Here's a dumb chart that shows which locks the MI framework holds
when it calls into the driver:

http://www.netbsd.org/~ad/audio-locks.txt

There might be other methods now, I don't know. Some futher notes:

- If I remember correctly, midi needs to be locked. I think I got part way
  through that. It might not even compile as a result.

- audio.c contains some nasty hacks in order to abuse the high-level
  spinlock to lock against the software interrupt. The softint is used is to
  send signals, etc.  That's no longer necessary, since software ints can
  now take adaptive mutexes, so the code there could be pared back and made
  a lot simpler. It could use the adaptive mutex instead (lock).

- About 1/2 the drivers are converted. From what I remember it took me
  between 1 to 30 minutes to convert a driver, depending on the level of
  complexity. Most of them were simple. There are maybe 25 or 30 drivers
  left to do.

It should be possible to extract the diff this way:

cvs rdiff -u -kk -r ad-audiomp-base -r ad-audiomp src/sys > audiomp.diff 

Andrew