¿vista mueve el subsistema de sonido a espacio de usuario? Nah...

En Osnews han destacado una entrada del blog de Larry Osterman (uno de esos programadores de microsoft que SI que hacen las cosas bien) en el que habla de como han movido cosas de audio del kernel al espacio de usuario

En osnews lo han tomado como que "han movido todo el subsistema de audio a espacio de usuario". ¿Todo? Uh...

"The first (and biggest) change we made was to move the entire audio stack out of the kernel and into user mode. Pre-Vista, the audio stack lived in a bunch of different kernel mode device drivers, including sysaudio.sys, kmixer.sys, wdmaud.sys, redbook.sys, etc. In Vista and beyond, the only kernel mode drivers for audio are the actual audio drivers (and portcls.sys, the high level audio port driver)"

Si uno se fija en el post de larry, no se dice exactamente que se estén moviendo todo fuera del kernel: Los drivers siguen dentro: "the only kernel mode drivers for audio are the actual audio drivers"

¿Entonces que han sacado del kernel y a que viene la noticia, si los drivers siguen ahi? Pues viene a que por lo visto (y no era desconocido), en los windows de hoy, el subsistema de sonido en el kernel no tiene solo drivers: Tiene drivers y más cosas. Ejemplo: Ese "kmixer.sys" del que habla Larry. Equivalente al dmix de ALSA - excepto que el dmix de alsa se implementa en las librerias de espacio de usuario de ALSA. Es decir, no es que Vista este "moviendo todo el subsistema de sonido fuera del kernel". Es que está sacando del kernel cosas que no deberian estar ahí. En otras palabras, están dejando en el kernel básicamente lo equivalente a ALSA. Tal como yo lo entiendo.

Y hay otro detalle muy sutil, pero muy curioso: The amount of code that runs in the kernel (coupled with buggy device drivers) causes the audio stack to be one of the leading causes of Windows reliability problems.. No se que tipo de organización tiene windows con respecto a los codecs, pero los malos codecs siempre han sido fuente de inestabilidad en windows, y me temo que esté relacionado con todo esto: Con que los codecs tuvieran que tocar más internalidades de las necesarias para hacer su trabajo, y que a veces lo hicieran mal

Pero el detalle realmente sutil es este, no el anterior. En este mismo blog he escrito mas de una vez el infierno que iba a suponer para microsoft el dual core. Un driver no preparado para maquinas SMP significa un cuelgue potencial en una máquina con dual core. Y los fabricantes de hardware, cuyos programadores y clientes nunca han utilizado máquinas SMP, tienen los drivers como yo le diga a usted. Me alegra saber que no estaba equivocado, porque este comentario de ese blog lo atestigua perfectamente...:

"one of the leading causes of Windows reliability problems" - tell me about it. I had to return about 90% of audio cards I bought because the drivers simply would not work for more than few minutes of playing audio on a multiple cpu system (and I mean multiple CPU, not just HT). Mixing multiple sources when you can actually have multiple requests coming in at literally the same time proved to be beyond most hardware manufacturers' skill. The only card that worked reliably for me was an old AWE32 running Microsoft's drivers but I can't use that anymore as my current mobo does not have an ISA slot. I'm currently using a card based on VIA's Envy24-HF chip with VIA's drivers, it doesn't sound as good as some other cards but at least it does not crash my box.

Podría apostarme algo a que los desarrolladores del subsistema de audio de windows van a sentir tentaciones de poner un pedazo de punto de sincronización a la entrada del subsistema de audio para evitar que más de dos procesos puedan entrar simultaneamente en esa parte del kernel...y que dejen de echarles la bronca cuando los dualcore se usen mucho...