You're right, but much depends on how much performance you need and how critical your realtime performance is. A lock-free algorithm may retry, but it will likely only retry once or twice. Your running time on any given operation may occasionally double or triple, but it won't hit you with six order of magnitudes like might happen with a mutex if it's contended and the thread that owns a lock takes a page fault or something.
I'd probably want to go wait-free if I was writing software for a Mars lander, but lock-free is good enough for consumer audio tasks, where mutexes generally aren't.
For people who are only skimming that message, note that this is not limited to ActiveX. In fact, the mention of ActiveX in the message's subject is regarding an unrelated topic that Ormandy happened to reply to.
Web APIs for audio are under active development. The W3C has formed a working group where use cases and two specifications (Web Audio API and MediaStream Processing API) are being developed. Chrome and Safari are shipping experimental versions of the Web Audio API now, and Firefox will soon be shipping experimental versions of the MediaStream Processing API (it's available now in a special build). Firefox 4 onwards also includes the simpler Audio Data API. I believe all of these APIs provide sufficient functionality to build the audio portions of media playback with working audio-visual synchronization.
