Nem biztos, hogy megértetted ;)
Az ALSA HAL (Hardware Abstraction Layer) maga a kernel driver, minden ezt használja, a libasound (ez az ALSA userspace része), a PipeWire és a PulseAudio is. Nincs másik kernel driver, csak ez.
Nekem nagyon úgy tűnik, hogy emiatt amikor valaki sound API-ra hivatkozik, akkor a kernel driver-t nem értik ide ;)
Mind a PulseAudio, mind a PipeWire tudják azt csinálni, hogy a libasound számára nyújtanak olyan eszközt, amit saját magukon keresztül route-olnak, azaz ha pl. egy Ubuntu 24.04-est felraksz, akkor a libasound-ot használó alkalmazások a PipeWire-en keresztül fognak a kernel driverrel beszélni, azaz ALSA(userspace)->PipeWire->ALSA(HAL)->hardver lesz az út. Így oldják meg a visszafelé kompatibilitást, és így lehetséges az, hogy pl egy RSTP-n keresztül küldje ét a hangot egy másik gépre egy libasound-ot használó alkalmazás, aminek amúgy fogalma sincs a hálózati streaming protokollokról. Másrészt nem hiszem, hogy ennek lenne extra latency a natív API-hoz képest, fogadni mernék rá, hogy a libasound "emuláció" nem igényel extra buffer-copy-t.
Az ALSA (libasound) latency-je pedig azért rosszabb, mint a másik kettőé mert az API-ja sokkal butább/egyszerűbb: nem lehet részlegesen feltöltött buffert használni, azaz ha már inicializáltad, akkor akkora lesz a latency, amekkora a buffer méret és kész. A másik kettő API-val (sőt, vegyük ide harmadikként a JACK-et is, ami szintén az ALSA kernel drivereket használja) lehet részleges buffert swappelni, így akármikor lehet a következő hangmintát játszani. Persze libasound-al is lehet kisebb latency-t csinálni kidebb bufferrel, de egyrészt macera, másrészt minimum méret korlátok is vannak a hardveres driver miatt, ráadásul ha kisebbre veszed a buffert, akkor sokkal több CPU időd megy a bufferkezelésre folyamatosan.