[Geschlossen] Aroio 4.x Beta (Pre-Release-Phase)

[((( atom )))]

Aroio beta 4.74

- Lastverteilung optimiert

So, ich habe einiges heraus gefunden und umgesetzt..

Der Tip mit den Prioritäten war schon mal die richtige Richtung. Leider ist die Geschichte mit den Prioritäten unter Linux sehr undurchsichtig. Es beginnt damit, dass die Programme einen Hauptthread starten und man mit ps oder top erst mal nur diesen sieht. Die eigentlich interessanten Threads sind aber die Kindprozesse, die mit den höheren Prioritäten gestartet werden. Gut, htop gibt da einiges her, aber so 100%ig schlau wird aus der Prio-Anzeige von htop auch keiner, habe das schon mit einigen Leuten diskutiert. Unklar ist auch, warum brutefir mit der festen RT-Prio von 7 oder was startet, jackd aber unter 10 erst mal gar nicht in den sched-fifo Modus geht (woraufhin brutefir den Dienst verweigert). Nun ja, ist eben so, also die 10.

squeezelite läuft jetzt mit Prio 88 (also leicht unterhalb der IRQs, die müssen Vorrang haben) und jack mit 10.

Das alleine reicht aber noch nicht. Ab und an scheint die Lastverteilung auf die Kerne so unglücklich auszufallen, dass einer der kerne laufend am Anschlag hängt. Daher habe ich den Ressourcenfresser squeezelite an die CPU-Kerne 3 und 4 genagelt, jack und brutefir fix an die 1 und 2. Nach meiner Beobachtung liegt die Haupt-Systemlast (deren Verteilung ich kaum beeinflussen kann) auf den Kernen 1 und 2, ist aber eh recht gering. Da brutefir und jack auch bei 192 kHz sehr überschaubar im Verbrauch bleiben, klappt das soweit sehr gut.

jackd läuft jetzt bei 192 kHz mit der 4096 Puffergröße als Voreinstellung.

Das Ganze läuft sowohl auf dem 3B+ als auch auf dem 3B! Ich habe auch heraus gefunden, warum es bei mir so wechselhaft lief: Der Pi wird irgendwann warm und dann geht nix mehr! Ich habe ein kleines script eingebaut, dass man einfach mit temp aufrufen kann, welches einem die System-Temperatur ausgibt. Ab 80° (!) gibt's dann Ärger.

Der Aroio läuft pauschal auf "Turbo". Wir hatten damit nie Ärger, haben ihn ja aber ursprünglich ausschließlich auf 96 kHz betrieben, was er dauerhaft kann. Man müsste mal probieren, wie er sich jetzt ohne Turo verhält, nachdem die Lastverteilung optimiert ist.

Über Testergebnisse zum squeezelite-Betrieb, aber natürlich auch zu allen anderen Modi, wäre ich wie üblich sehr dankbar, bei mir macht es jetzt einen Dauerhaft stabilen Eindruck. Ich habe allerdings nahezu ausschließlich 192 kHz getestet, das schwerste zuerst..

Wenn squeezelite dann im Kasten ist, knöpfe ich mir die restlichen Player vor..

[((( atom )))]

Freudiges Update meinerseits:

Der 3B ist die ganze Nacht auf 192 kHz mit squeezelite, Resampling und Convolution durchgelaufen, ohne heute morgen zu knattern!
Temperatur: Stolze 79°/80°! - Die CPU ist übrigens vom Hersteller bis 85° spezifiziert, wird aber im Pi ab 80° gedrosselt. Mit obigem Setup fliegt er haarscharf unter'm Radar!

Dann habe ich mich mal an den ShairPort gesetzt. Den musste ich natürlich auch erst mal an zwei Kerne hängen. Hier gibt es dann das Problem, dass z.B. squeezelite, sofern parallel dazu aktiviert, die ganze Zeit resampelt, auch wenn es auf Pause steht. Da nun beide Player sich die gleichen beiden Kerne teilen, geht das dann nicht mehr mit 192 kHz, darunter scheint es aber zu funktionieren. Ich muss da noch ein wenig testen und werde dann demnächst auch damit eine Version machen.

[Explosiv]

Bei mir funktioniert es nicht mehr mit dem Upsampling auf 192kHz. Testumgebung wie zuvor (3B+ Pifi Digi) Weder die Einstellungen, die bei Aroio beim Start eingestellt sind funzen und nicht die, die zuvor funktionierten. Als ich dachte stabile Werte gefunden zu haben, war nach ca. 10 Minuten Schluss, die Musik wurde von Rauschen und Knistern überlagert was zunehmend schlimmer wurde.... Temperatur lag bei 60°C, die Prozessorauslastung nicht >70%, in den Logs keine Auffälligkeiten.
Allerdings ist 192 kHz für mich vollkommen uninteressant, ich benötige nur 44.1.

Schön wäre es in diesem Zusammenhang, wenn AcourateCV Filter in dieser Geschmacksrichtung bereitstellen würde; sollte doch angeblich zu verwirklichen sein, wie man in den Anfangsseiten diese Threads lesen konnte.....

[((( atom )))]

So, wir waren nicht untätig...

Aroio 4.75 beta

- weitere Optimierungen hinsichtlich Lastverteilung, Prioritäten und Puffern.
- HDMI Ausgang 90° gedreht, mit Option ihn gerade zu drehen.
- ShAirPort-sync Puffer im Webinterface zugänglich.

Hanno und ich haben uns rund getestet und ich denke, wir haben gute Werte rausgefunden.
An sich läuft jetzt alles, mit jeder Taktrate und in jeder Konstellation. Einzige kleine Ausnahme (nach wie vor): squeezelite mit 192 kHz. Das knistert auf dem 3B noch ein wenig, ich vermute mal, dass es auf dem 3B+ funktioniert. Noch nicht getestet.

ShAirPlay läuft jetzt auch mit allen raten absolut sauber.

Bitte testen und berichten! Sollte jemand noch bessere Werte für die ganzen Puffer rausfinden, sind wir natürlich dankbar und bauen die sofort ein!

[Explosiv]

4.75 läuft mit 192kHz tatsächlich besser. Mit nur marginalen Änderungen seit über einer Stunde keine Xruns.
(3B+, Pifi Digi, squeezlite, 44.1 Files)
Die Systemlast steigt immer wieder kurz an, da immer wieder nach dem nicht vorhandenem Wlan gesucht wird, kein Wlan sorgt auch für eine extrem lange Bootphase. Die Temperatur liegt bei 60°C, der Pi ist auf einem Holzbrettchen montiert, den werd ich morgen mal "einhausen".

[((( atom )))]

Ah, das find ich gut. Langzeittest steht übrigens noch aus..

Kein WLan fürt zu verzögertem Booten? Das müsstest Du mir mal näher schildern, denn das erlebe ich hier gar nicht.

[Hanno Sonder]

Guten Abend zusammen,

ich habe einfach mal ein Experiment gestartet und per Squeezelite, ShAirPort und UPnP aus Foobar gleichzeitig Musik auf das Ding gegeben. AroioSU mit 3B drin und AroioDAC. Das Ganze bei 96kHz Systemtaktrate mit den aktuellen Default-Werten:

96kHz stabil.PNG (36.25 KiB) 9311 mal betrachtet

Das läuft jetzt sein über 2 Stunden stabil.
Das gleiche Experiment hatte ich vorhin mit 48kHz gestartet, da war der Raspi nach ca. 2,5 Stunden komplett abgeschmiert, stotterte und war nicht mehr ansprechbar. Hier gibt es offenbar noch was zu optimieren, aber wenn bei anderen Testern mit 96kHz auch alles rund läuft, können wir da wohl schonmal einen Haken dran machen.
Bevor er abstürzte hat er aber auch mit 48kHz alles perfekt gespielt, auch krumme Taktraten wie 176,4kHz.

Gute Nacht
Hanno

[Explosiv]

Mein obiger Test lief 3h ohne Störung, dann habe ich ein Stück mit 48kHz Original Samplingfrequenz angehängt, beim Wechsel kam es zum Xrun; eventuell muss das mit 48kHz nochmal weiter geprüft werden.

Die Meldung beim Start, die die Bootdauer erhöht lautet:

Code: Alles auswählen

A Start job is running for sys-subsystem-netdevices-wlan0.device

dann wird erstmal 90s hochgezählt. Ein Wlan Stick steckt nicht im Pi.

[Hanno Sonder]

Gestern habe ich das Experiment mit 3 verschiedenen Zuspielungen gleichzeitig wiederholt, auch auf 48kHz, es kam über Stunden zu keinen Problemen, außer, dass Airplay aus iTunes auf einem Windows-Rechner heraus mit einem Internetradiosender irgendwann hakelte, aber erst nach Stunden. Dann einmal auf Pause und wieder auf Play und es lief wieder einwandfrei.

Was noch Probleme macht und hakelt ist der UPnP-Renderer mit 192kHz Systemtakt. Vielleicht finden wir hier gemeinsam noch optimierte Werte?

[((( atom )))]

Lesen denn unsere AirPlay User noch mit?