# Ardour auf einem Pulsaudio System crashed x-session

## Erdie

Wie schon erwähnt versuche ich herauszufinden, ob man mit Ardour auf einem Pulseaudio System leben kann.

Ich habe USE=jack ergänzt, ein workupate gemacht und Ardour installiert. Dannach limits.conf eingerichtet und beim Start von Ardour passiert merkwürdies. Erst kommt der Startdialog von Ardour, wo man das Soundsystem und weitere Parameter definieren kann. Ich habe es mit Jack und pulseaudio versucht. Bei jack wäre die Erwartung, dass pulse solange heruntergefahren wird, bis jack gestoppt ist. 

In beiden Fällen crashed Ardour und die gesamte X Sesson wird gekillt. Im syslog steht dann:

```

May 10 12:55:37 tuxedo pulseaudio[3296]: [pulseaudio] x11wrap.c: X11 I/O error handler called

May 10 12:55:37 tuxedo pulseaudio[3296]: [pulseaudio] x11wrap.c: X11 I/O error exit handler called, preparing to tear down X11 modules

May 10 12:55:37 tuxedo kernel: ArdourGUI[3845]: segfault at 0 ip 00007fe1e84e48ec sp 00007ffd3f233b30 error 4 in libwidgets.so.0.0.0[7fe1e84db000+4b000]

```

Soll das heißen, dass Pulseaudio meinen X-server abgeschossen hat? Das ist, wie ich finde, schon der Hammer. Was bildet sich Pulseaudio überhaupt ein? 

Grundsätzlich habe ich gelesen, dass es möglich ist Ardour und jack temporär hochzufahren und dass pulse dann in den Hintergrund tritt oder man kann Ardour mit Pulseaudio betrieben aber  das führt, wie oben erwähnt, zu einem Absturz der x session.

----------

## Christian99

 *Erdie wrote:*   

> Wie schon erwähnt versuche ich herauszufinden, ob man mit Ardour auf einem Pulseaudio System leben kann.
> 
> Ich habe USE=jack ergänzt, ein workupate gemacht und Ardour installiert. Dannach limits.conf eingerichtet und beim Start von Ardour passiert merkwürdies. Erst kommt der Startdialog von Ardour, wo man das Soundsystem und weitere Parameter definieren kann. Ich habe es mit Jack und pulseaudio versucht. Bei jack wäre die Erwartung, dass pulse solange heruntergefahren wird, bis jack gestoppt ist. 
> 
> In beiden Fällen crashed Ardour und die gesamte X Sesson wird gekillt. Im syslog steht dann:
> ...

 

hm, der fehler scheint eher in ardour zu liegen, das sieht man ja an dem angebenen segfault. Und das ist ja sicherlich auch nicht absichtlich das abschießen.

Darüber hinaus sollte ein abstürzendes client programm nicht den ganzen xserver mitreißen. Da wäre mal das Xorg.log interessant, evtl sieht man da noch was.

----------

## Erdie

Also, ähm, jetzt wollte ich das Problem nachstellen um die xorg.log zu analysieren und jetzt funktioniert es auf einmal. Irgendwas hat das falsch gehangen. Mich wundert das nur denn soweit ich mich erinnern kann hatte ich nach dem USE change und worldupdate auch gebootet. Nun ja, jetzt fahr ich die Kiste erneut hoch und es geht. Ich kann leider nicht sagen was genau.

FYI: Es funktioniert sowohl mit pulse als auch mit jack. Wenn ich jack im Startdialog auswähle, ist pulse in der Soundeinstellungen solange tot und erwacht wieder wenn Ardour geschlossen und jack gestoppt wurde. Man kann damit wie es momentan aussieht ganz gut leben.

Ich sags ja immer: Gentoo hat Selbstheilungskräfte!

----------

## firefly

 *Erdie wrote:*   

> Also, ähm, jetzt wollte ich das Problem nachstellen um die xorg.log zu analysieren und jetzt funktioniert es auf einmal. Irgendwas hat das falsch gehangen. Mich wundert das nur denn soweit ich mich erinnern kann hatte ich nach dem USE change und worldupdate auch gebootet. Nun ja, jetzt fahr ich die Kiste erneut hoch und es geht. Ich kann leider nicht sagen was genau.
> 
> FYI: Es funktioniert sowohl mit pulse als auch mit jack. Wenn ich jack im Startdialog auswähle, ist pulse in der Soundeinstellungen solange tot und erwacht wieder wenn Ardour geschlossen und jack gestoppt wurde. Man kann damit wie es momentan aussieht ganz gut leben.
> 
> Ich sags ja immer: Gentoo hat Selbstheilungskräfte!

 

Wie schon in dem anderen Thread geschrieben wäre pipewire wohl die bessere wahl da es mit jack besser zusammenarbeiten kann.

----------

## Erdie

 *firefly wrote:*   

>  *Erdie wrote:*   Also, ähm, jetzt wollte ich das Problem nachstellen um die xorg.log zu analysieren und jetzt funktioniert es auf einmal. Irgendwas hat das falsch gehangen. Mich wundert das nur denn soweit ich mich erinnern kann hatte ich nach dem USE change und worldupdate auch gebootet. Nun ja, jetzt fahr ich die Kiste erneut hoch und es geht. Ich kann leider nicht sagen was genau.
> 
> FYI: Es funktioniert sowohl mit pulse als auch mit jack. Wenn ich jack im Startdialog auswähle, ist pulse in der Soundeinstellungen solange tot und erwacht wieder wenn Ardour geschlossen und jack gestoppt wurde. Man kann damit wie es momentan aussieht ganz gut leben.
> 
> Ich sags ja immer: Gentoo hat Selbstheilungskräfte! 
> ...

 

Das habe ich schon verstanden, ich wollte nur testen inwieweit es mit pulse eben geht. Bei pipewire bin ich mit nicht so sicher, da das noch experimentell ist. Auf meinem Laptop bleibt sowieso pulse, da es funktiont und jack und co da ohnehin nicht so wichtig sind. Von daher habe ich es dort einfach mal ausprobiert, da schon vorhanden.  Aber trotzdem danke für alle Tipps, ich werde auch pipewire im Auge behalten. Vorerst werde ich den Desktop wohl noch so lassen wir er ist.

----------

## Erdie

Interessant, ich habe jetzt herausgefunden, dass Ardour den xserver zum Einfrieren bringt, wenn das Netzkabel eingesteckt ist. Im Batteriebetrieb läuft die Software meistens einwandfrei bzw. stürzt wenn dann weniger heftig ab, was heißt, der xserver wird gestoppt und man kommt auf den login screen zurück. Mit Netzkabel dagegen frriert die Kiste so ein, dass man nur noch über ssh drankommt. Im xorg log ist dann ein segfault zu sehen. Ich kann das jetzt nicht posten weil ich eben eigentlich was anderes vorhatte und mir das zurfällig passiert ist. Ich werde den Fehler nochmal provozieren und dann den xorg.log herausziehen und hier posten.

Das hat jetzt definitiv nichts mit pulse oder also zu tun sondern mit Ardour selbst.

EDIT: Anbei der xor-log

```

    7.892] (II) AMDGPU(0): Modeline "1920x1080"x0.0  152.57  1920 1968 2000 2192  1080 1083 1089 1160 +hsync -vsync (69.6 kHz eP)

[    20.267] (II) event8  - UNIW0001:00 093A:0255 Touchpad: device removed

[    58.009] (EE)

[    58.009] (EE) Backtrace:

[    58.011] (EE) 0: /usr/bin/X (xorg_backtrace+0x5b) [0x55a0744fac4b]

[    58.011] (EE) 1: /usr/bin/X (0x55a0743bc000+0x142a15) [0x55a0744fea15]

[    58.011] (EE) 2: /lib64/libc.so.6 (0x7f4ea07dc000+0x3daa0) [0x7f4ea0819aa0]

[    58.011] (EE) 3: /usr/lib64/dri/radeonsi_dri.so (0x7f4e9f05e000+0x4e5d61) [0x7f4e9f543d61]

[    58.011] (EE) 4: /usr/lib64/dri/radeonsi_dri.so (0x7f4e9f05e000+0x47e9c4) [0x7f4e9f4dc9c4]

[    58.011] (EE) 5: /usr/lib64/dri/radeonsi_dri.so (0x7f4e9f05e000+0x6d33a9) [0x7f4e9f7313a9]

[    58.011] (EE) 6: /usr/lib64/dri/radeonsi_dri.so (0x7f4e9f05e000+0x6c3fa2) [0x7f4e9f721fa2]

[    58.011] (EE) 7: /usr/lib64/dri/radeonsi_dri.so (0x7f4e9f05e000+0x6db154) [0x7f4e9f739154]

[    58.011] (EE) 8: /usr/lib64/dri/radeonsi_dri.so (0x7f4e9f05e000+0x6db29e) [0x7f4e9f73929e]

[    58.011] (EE) 9: /usr/lib64/dri/radeonsi_dri.so (0x7f4e9f05e000+0x5c1d02) [0x7f4e9f61fd02]

[    58.011] (EE) 10: /usr/lib64/dri/radeonsi_dri.so (0x7f4e9f05e000+0x5bc622) [0x7f4e9f61a622]

[    58.011] (EE) 11: /usr/lib64/dri/radeonsi_dri.so (0x7f4e9f05e000+0x5bcfc3) [0x7f4e9f61afc3]

[    58.011] (EE) 12: /usr/lib64/dri/radeonsi_dri.so (0x7f4e9f05e000+0x5c2acf) [0x7f4e9f620acf]

[    58.011] (EE) 13: /usr/lib64/dri/radeonsi_dri.so (0x7f4e9f05e000+0x138ba5) [0x7f4e9f196ba5]

[    58.011] (EE) 14: /usr/lib64/dri/radeonsi_dri.so (0x7f4e9f05e000+0x139602) [0x7f4e9f197602]

[    58.011] (EE) 15: /usr/lib64/dri/radeonsi_dri.so (0x7f4e9f05e000+0xff07e) [0x7f4e9f15d07e]

[    58.011] (EE) 16: /usr/lib64/dri/radeonsi_dri.so (0x7f4e9f05e000+0x10161e) [0x7f4e9f15f61e]

[    58.011] (EE) 17: /usr/lib64/xorg/modules/libglamoregl.so (0x7f4e9411a000+0x21e8e) [0x7f4e9413be8e]

[    58.011] (EE) 18: /usr/lib64/xorg/modules/libglamoregl.so (0x7f4e9411a000+0x133b4) [0x7f4e9412d3b4]

[    58.011] (EE) 19: /usr/lib64/xorg/modules/libglamoregl.so (0x7f4e9411a000+0x14c43) [0x7f4e9412ec43]

[    58.011] (EE) 20: /usr/lib64/xorg/modules/libglamoregl.so (0x7f4e9411a000+0x167a2) [0x7f4e941307a2]

[    58.011] (EE) 21: /usr/bin/X (0x55a0743bc000+0xc053f) [0x55a07447c53f]

[    58.011] (EE) 22: /usr/lib64/xorg/modules/libglamoregl.so (0x7f4e9411a000+0x1d3ff) [0x7f4e941373ff]

[    58.011] (EE) 23: /usr/bin/X (0x55a0743bc000+0xcf908) [0x55a07448b908]

[    58.011] (EE) 24: /usr/bin/X (0x55a0743bc000+0x74064) [0x55a074430064]

[    58.011] (EE) 25: /usr/bin/X (0x55a0743bc000+0x77f63) [0x55a074433f63]

[    58.011] (EE) 26: /lib64/libc.so.6 (0x7f4ea07dc000+0x2931a) [0x7f4ea080531a]

[    58.011] (EE) 27: /lib64/libc.so.6 (__libc_start_main+0x7c) [0x7f4ea08053cc]

[    58.011] (EE) 28: /usr/bin/X (_start+0x21) [0x55a0743f8051]

[    58.011] (EE)

[    58.011] (EE) Segmentation fault at address 0x55a52f81cfd9

[    58.011] (EE)

Fatal server error:

[    58.011] (EE) Caught signal 11 (Segmentation fault). Server aborting

[    58.011] (EE)

[    58.011] (EE)

Please consult the The X.Org Foundation support

         at http://wiki.x.org

```

Ich kann weiterhin bestätigen, dass im Batteriebetrieb es entweder gar nicht crashed oder ich komme auf den Displaymanager zurück und im Netzbetrieb es zu einem Einfrieren kommt, bei dem ich nur mit ssh oder den sys-kernel magic keys rauskomme.

Wenn keiner eine Idee hat werde ich hierzu einen bug aufmachen. Ich habe im Bugzilla nix gefunden.

----------

## Erdie

push (da ich vorher mehrmals editiert hatte und das evtl keiner gesehen hat)

----------

## Christian99

hm, damit kann man leider nicht viel anfangen, weil keine Debugsymbole enthalten sind.

ich kann nicht mal sagen wo genau der segfault jetzt ist, entweder in /usr/binX, oder was auch möglich ist, in /usr/lib64/dri/radeonsi_dri.so. Und die nachfolgenden stackframes von glibc bzw X sind nur ein segfault handler der noch aufgerufen wird.

Um debug symbole zu bekommen, siehe hier:

https://wiki.gentoo.org/wiki/Debugging

da der backtrace nicht von gdb kommt, sondern von Xorg selbst, weiß ich allerdings nicht, ob Xorg in der lage ist die debug symbole in separaten dateien zu finden. Evtl solltest du dann nicht FEATURE=splitdebug verwenden sondern FEATURE=nostrip verwenden. Am besten mal ausprobieren.

Wenn du dann einen backtrace mit debugsymbolen hast, solltest du dich aber lieber an den upstream (Xorg oder mesa) wenden. Das geht ein bisschen über das hinaus was sonst hier im Forum gemacht wird  :Smile: 

----------

## Erdie

Ich vermute die Ursache im Grafiktreiber, da das der wirklich entscheidende Unterschied ist. Ardour läuift bei mir problemlos auf uralter Intel Hardware und auf meinem Ryzen Desktop. Das besondere an diesem Gerät ist nur die Vega 7 Grafik und die ist auch relativ neu. Ardour scheint teilweise recht optimiert worden zu sein z. B. haben die VU Anzeigen Assembler Code um performanter zu sein. Das ist reine Spekulation und bringt nicht viel aber nur mal so als Anmerkung.

----------

## Erdie

Update: Ich habe nichts zur Fehlerbehebung unternommen. Trotzdem habe ich gestern einfach nochmal einen Test gemacht und es hat mehrere Mal hintereinander funktioniert, als wenn gar nichts wäre. Ich werde weiter testen.

----------

## Christian99

Solche Fehler sind nicht immer deterministisch, sondern oft sporadisch/zufällig. Da solltest du dich jetzt nicht wundern.

----------

## Erdie

 *Christian99 wrote:*   

> Solche Fehler sind nicht immer deterministisch, sondern oft sporadisch/zufällig. Da solltest du dich jetzt nicht wundern.

 

Du hast Recht, denn dannach ist es wieder passiert. Allerdings jetzt, nachdem ich auf ABI_X86=32 64 umgestellt habe, ist es kein einziges Mal mehr schiefgegangen, allerdings erstmal ohne Netzkabel. Das Symptom war nachvollziebar anders wenn das Kabel eingesteckt war. Ich habe sowohl gestern, als auch heute morgen Ardour ein paar Mal gestartet (wenn, dann passiert es nur beim Start, wenns erstmal läuft, dann läuft´s) und alles lief gut. Mal sehen wie es weitergeht.

----------

## firefly

eventuell ein Hardware defekt?

Könntest du mal übernacht nen memtest laufen lassen nicht das ein RAM Modul defekt ist.

Oder das Netzteil beginnt zu schwächeln und in gewissen situationen bricht etwas die spannung ein wodurch dann z.b. der RAM nicht mehr sauber arbeiten kann und zu abstürzen führt.

----------

## Erdie

 *firefly wrote:*   

> eventuell ein Hardware defekt?
> 
> Könntest du mal übernacht nen memtest laufen lassen nicht das ein RAM Modul defekt ist.
> 
> Oder das Netzteil beginnt zu schwächeln und in gewissen situationen bricht etwas die spannung ein wodurch dann z.b. der RAM nicht mehr sauber arbeiten kann und zu abstürzen führt.

 

Das will ich nicht hoffe, denn das Gerät ist praktisch nagelneu   :Wink:  Aber klar, das sagt erstmal nix aus. 

Das mit dem Netzteil wäre in dem von Dir beschriebenen Kontext sehr ungewöhnlich, da der Fehler ja häufiger passiert wenn es eingesteckt ist und das Notebook wird ja dann nicht mit dem Netzteil betrieben, sondern das Netzteil puffert ja nur den Akku und der bestimmt dann letztlich die Betriebsspannung. Und es stürzt immer gezielt der Xserver ab, sonst läuft der Rest tadelos. Bei defektem RAM würde ich etwas mehr chaotisches Verhalten erwarten, dass z. B. sonst auch mal an anderen Stellen was schiefgeht. Aber nichtsdestotrotz, wenn das so weitergeht, mache ich mal den RAM-Test. Der kostet ja nichts.

Und bei zu stark sinkender Akkuspannung schalten Notebooks einfach ab um den Akku vor Tiefentladung zu schützen. Ich würde erwarten, dass das passiert bei Spannungsproblemen. Jetzt mach ich erstmal eine Testserie mit eingestecktem Kabel.

----------

## Erdie

Jetzt habe ich 10 Tests gemacht mit Netzkabel. Ergebnis:

- der 2. Versuch ging schief

- die Starts 3-10 funktionierten

Es könnte etwas mit Timing zu tun haben, denn im Batteriebetrieb, wird die CPU Leistung gedrosselt. Das merke ich beim Kompilieren, Im Akkubetrieb ist dann die Temperatur 5-10°C geringer.

----------

## Erdie

Info: Seit dem Update auf kernel 5.15.41 hat es keinen fehlgeschlagenen Versuch mehr gegeben. Aber die Anzahl der Starts ist noch zu gering um eine sichere statistische Aussage zu machen. Ich werde weiter testen.

----------

## Erdie

Update:

Es ging nach meinem letzten Post ab und zu nochmal schief. Ich mache immer wieder Stichproben und jetzt habe ich den Eindruck, dass sich das Problem tatsächlich von selbst gelöst hat. Ich starte immer wieder mal Ardour und die Abstürze kommen einfach nicht mehr vor. 

Umso besser, auch wenn es etwas blöd ist wenn man nicht weiß woran es lag. Aber so ist das eben manchmal.

----------

