Мне эта статья почему-то попалась только сегодня. Хоть и прошло шесть лет, но старые заблуждения как вокруг ASIO, так и вокруг звуковой подсистемы Windows, остались до сих пор, так что имеет смысл кое-что пояснить.
Необходимость в ASIO возникла исключительно для профессиональных задач
На самом деле никакой необходимости именно в альтернативном интерфейсе не было. На момент появления ASIO (1997 г.) стандартом был MME/WinMM, и только что появился DirectSound. Никакой централизованной звуковой подсистемы в Windows тогда не было - и MME, и DirectSound работали непосредственно через драйверы ядра, разрабатываемые отдельно для каждого звукового устройства. Преобразования форматов тогда не было - все по определению шло "бит-в-бит". Не было никаких технических проблем и добиться сколь угодно малых задержек, а также добавить к стандартным интерфейсам необходимые дополнительные функции. При этом достаточно было бы одного драйвера для всех приложений - и обычных, и профессиональных.
Общая звуковая подсистема в виде KMixer появилась в Win2k, но там же одновременно появился и Kernel Streaming, которого по уши достаточно для любых применений, если грамотно сделать драйвер. Так что и там не было нужды обходить стандартные интерфейсы - достаточно было (как и сейчас) сделать нормальный драйвер KS, чтобы удовлетворить и массы, и аудиофилов, и профессионалов.
есть специальные режимы, в ОС Windows это «Kernel Streaming» (версии до XP) и WASAPI (версии после XP включительно)
Это просто интерфейсы разного уровня. KS был разработан для модели WDM, общей для Windows 98 и 2000. Это чисто ядерный интерфейс в стиле DirectShow, задумывался как раз для эффективной связки DirectShow на пользовательском уровне с драйверами ядра. Но DirectShow в качестве универсального медийного средства не взлетел, хотя всё видео до сих пор делают почти исключительно на нем. В итоге KS остался этаким "карманным" интерфейсом MS, всех возможностей которого никто никогда не использовал.
В Win2k/XP поверх KS был KMixer, а на нем - MME и DirectSound. В Vista ядерный модуль KMixer заменили на пользовательский процесс AudioDG, который реализует WASAPI.
То есть, WASAPI реализован поверх KS, они существуют вместе.
В таком режиме право передать звуковой поток имеет только одна программа в системе и тут полностью исключается микширование и пересчет данных.
Это все зависит исключительно от KS-драйвера. Почти все они - одноклиентные, как и в раннем MME времен Win3x/9x. Но ничто не мешает сделать мультиклиентный драйвер, KS это полностью поддерживает. Такой драйвер может микшировать и преобразовывать форматы сам, или поручить это звуковому адаптеру, если тот умеет. Первые KS-драйверы для "32-", "64-" и "128-голосых" адаптеров были как раз мультиклиентными, и на этом работало аппаратное ускорение DirectSound в Win2k/XP. Потом обнаружилось, что это мало кому нужно, программный KMixer в большинстве случаев справлялся, и дальше пошли уже одноклиентные драйверы.
WASAPI штатными настройками ОС не позволяет управлять задержкой
Здесь точнее будет сказать "система Windows не позволяет управлять задержкой штатными средствами". 
То есть, ASIO - ни разу не панацея. Если Вы напишете ASIO-драйвер и/или ASIO-хост тупо по спецификации, то обнаружите, что задержки там не сильно меньше, чем в WASAPI, и не более предсказуемы. Это потому, что бОльшая часть задержек возникает в самой системе. независимо от звука. Борьба с ними - отдельный вид шаманства, общие принципы которого описаны здесь (это далеко не всё). А если все эти методы применены, то и WASAPI ведет себя гораздо стабильнее, основной проблемой остается лишь переключение процессов (WASAPI обслуживает отдельный процесс AudioDG).
А вот KS работает по тому же пути, что и ASIO - непосредственно через драйвер ядра. Разница лишь в том, что программно ASIO гораздо проще, а KS значительно более сложен, и спецификация на ASIO была открыта с самого начала, а нормальной документации по KS нет до сих пор, поскольку это неподъемная задача, и MS не видит смысла напрягаться с нею. Из-за этого KS долгое время был практически неизвестен широкой публике, а Steinberg активно продвигал ASIO. В итоге в народе прочно сложилось мнение, что ASIO - это "круто", "профессионально", "надежно", хотя так получилось не "благодаря", а "вопреки".
Что происходит, когда задействованы одновременно звуковая система ОС и ASIO? Для звукового драйвера есть два звуковых потока, одни из них приходит из подсистемы ОС, другой из ASIO. Исключительно от того, как был написан драйвер, будет происходить микширование финального потока до ЦАП
Если бы с появлением KS все стали делать ASIO-драйверы исключительно через него, выпуская эффективный мультиклиентный WDM/KS драйвер ядра, и пользовательскую DLL ASIO к нему, то давно настала бы всеобщая благодать. Одним клиентом выступала бы звуковая подсистема, со своим преобразователем форматов, регулятором уровня, эффектами и задержками. Другими клиентами выступали бы ASIO-приложения, сколько их есть. Вдобавок к нему подключались бы KS-приложения. И все это могло бы работать вместе, не мешая друг другу, пока хватает ресурсов у звукового железа (ЦАПов, каналов DMA, ресурсов DSP и прочего). Были бы счастливы все - и обычные пользователи, и аудиофилы, и профессионалы.
Драйвер ASIO4ALL необычайно популярен, но является при этом мостом между выходом ASIO из программы на вход KS/WASAPI в ОС
ASIO4ALL ничего не знает про WASAPI, он работает исключительно через KS. Был еще ASIO2KS, но он не получил такого развития. Через WASAPI работает ASIO2WASAPI.
приходили утверждения со стороны программистов, что например ASIO драйвер внешних карт E-MU (USB версий) сделан аналогично ASIO4ALL в виде моста и именно это является источником низкой стабильности карт
Беда в том, что большинство ядерных драйверов сделано или просто плохо, или ужасно. Многие вообще делаются на WDF - это такой фреймворк от MS для тех, кто очень хочет делать драйверы ядра, но толком не понимает, как там что работает. Я интереса ради ковырял некоторые ASIO DLL и их ядерные драйверы - код там, мягко говоря, странный.
