>Микроядро : Само работает, двайвер постоянно валяется либо перезапускается. Итого звука >нет.

Куда более вероятный сценарий: звук работает бОльшую часть времени, в какой-то момент драйвер вываливается и тут же перезапускается, причем пользователь может этого даже не заметить.

>
>Монолит : В самом кривом случае кернел-паник (что не смертельно, ибо всё
>останется живым после рестарта) итог 1 - звука нет.

Если Вы считаете kernel panic "несмертельным", то наш разговор продолжать бессмысленно, ибо основная цель микроядра - избежать этого сценария. Кроме того, отчего Вы так уверены, что все "останется живым после рестарта" ? А если в драйвере файловой системы будет ошибка, которая приведет к непоправимой порче?
Впрочем, это уже лирика. Если рассматривать kernel panic как допустимый вариант, то микроядро нафиг не нужно.

>Производительность будем сравнивать? Давайте хотя бы приблизительно:
>
>1. Микроядро. Драйвер не имеет прямого доступа к обороудованию, обращается за этим
>к микроядру. Переключение контекста 1. Латентность самого микроядра 2.

Во первых, драйвер, хоть и не имеет прямого доступа к оборудованию, зато имеет к физической памяти, если устройство работает через DMA.
Во вторых, современные техники оптимизации производительности предусматривают применение прямого переключения контекста от отправителя к получателю сообщения, например, от драйвера блочного устройства к процессу драйвера дискового контроллера. Это верно в тех случаях, когда в свободные регистры сообщение помещается полностью. Таким образом, передача сообщения происходит без двойного копирования из разных адресных пространств и минуя вызов планировщика. Все это увеличивает производительность IPC на порядок.

>2. Монолит. Тут что драйвер захотел то и сделал, максимально разгрузив CPU,
>если оборудование девайса позволяет.

Вот именно, захотел пропилить чужую память - пропилил. Захотел разыменовать ноль - разыменовал. Более того, если Вы считаете, что в монолитной модели все так уж прямо и хорошо, то Вы ошибаетесь. Посмотрите, например, сколько сложностей возникает при разработке драйвера высокоскоростной сетевой платы: всякие потоки для прерываний, их синхронизация с рабочими потоками и с остальным ядром, привязки этих потоков к одним процессорам с целью избежать перезагрузок кэша, поллинг, контроль за частотой прерываний и включением/выключением поллинга, и прочие прелести.

>Интересно будет посмотреть на производительность когда USB корень задолбит микроядро >запросами от мыши и клавиатуры.

Если Вы думаете, что проблем с этим нет у монолита, то Вы ошибаетесь. Любое немаскированное прерывание влечет за собой как минимум два переключения контекста - на поток, обрабатывающий прерывание, и обратно. Поэтому проблемы тоже есть, и решаются они точно так же, как и в случае микроядра.