tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
MP safe audio framework and drivers
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
Home |
Main Index |
Thread Index |
Old Index