A buffer underrun akkor is bekövetkezhet, ha megpróbálod jól kezelni. Azzal nem tudsz mit kezdeni, ha egy csomó ideig nem kapja meg a vezérlést a kliens, a szerver meg közben éhen hal adat nélkül. :) A baj azzal van, ami ezt követően jön: lezárja a kapcsolatot, pedig nem kellene. Persze mással is baj van, mert ugyanaz az ütemező, ugyanaz a kernel fut a pipewire esetében is, aztán az meg képes szépen szólni.
Tegyük hozzá - s ebben hajbazernek igaza van -, Lennart Poettering egy szélsőségesen idealista, elméleti szakember. Amikor egyes alsa driverekben nem volt implementálva valami, amit addig szinte senki sem használt, de a PA-nak kellett - talán a hardware pointer visszaolvasása az adott pillanatban -, akkor ahelyett, hogy workaroundot írt volna a PA-ba, kicsapta a hisztit, hogy ez alsa bug, ennek elfedése nem az ő dolga, az OSI-modellben nem ahhoz a réteghez tartozik, amelyet a PA megvalósít, javítsa meg az alsa fejlesztői csapata.
Az eredmény az lett, hogy a hang sokáig használhatatlan volt Linuxon, s közben ezt Lennart simán meg tudta volna oldani. Ilyenkor érzem azt, hogy legszívesebben felrúgtam volna az égig, illetve nagyon semmi keresnivalója a Red Hat egyik vezető fejlesztői pozíciójában ezzel a szemlélettel.
Wim Taymans nem ilyen beképzelt, sokkal gyakorlatiasabb. Ő a feladatot látja. A Commodore 64 időktől kezdve foglalkozik audio driver-ekkel, ezzel a témakörrel, s működő dolgot akar csinálni, nem pedig olyat, ami ugyan nem működik, de meg tudja magyarázni, hogy valaki más miatt nem működik. Láttam is a PW commitok között workaround-ot, ami Lennartnak egészen biztos derogált volna.