DRC - suche Lösung für mein Setup

Autor

Beitrag

magnetonic
Schaut ab und zu mal vorbei

#1 erstellt: 21. Apr 2019, 09:26

Hallo zusammen,

nachdem ich seit Jahren meinen Raum mit herkömmlichen Mitteln (REW) optimiere und schrittweise an ein ansprechendes Ergebnis gelangt bin, möchte ich die verbleibenden Schwächen mit Digital Room Correction optimieren.

Jedoch finde ich keine Lösung, die in mein System passt:
Logitech Media Server Windows 7.9.2 -> Ethernet -> SqueezeBox Touch -> TOSLINK ->

Mutec MC-3 USB Reclocker -> AES -> Classé CP-800 Mk II -> XLR -> Classé CM600 -> Kimble 12TC -> B&W 800D

In Zukunft möchte ich den Classé durch einen Power-DAC ersetzen. Vermutlich einen

Okto Audio, Benchmark DAC3 HSG oder einen TotalDAC.

Ca. 35,000 Musikdateien (3TB), gößtenteils FLAC, aber auch MP3, einige DSD.

1. Wunschszenario
Am liebsten wäre mir, die DRC vor dem mutec einzuschleifen, also ein DRC mit Digi auf Digi.
Alternative 1 wäre ein Plug-In für den Media Server.
Alternative 2 wäre Ersatz der Squeezebox durch einen Media-PC/Streamer mit DRC.

Da ich mehrere SqueezeBoxes im Haus habe, würde ich gerne bei LMS bleiben.

2. Hardware
- miniDSP Digi /

OpenDRC-DI: fast perfekt, leider auf 6144 Taps

beschränkt
- ABACUS AROIO: Leider sehe ich dort nur Produkte mit Vorverstärker, kein Digital-Out
- Lyngdorf: kein passendes Gerät, Lösung erlaubt keine fremd-hergestellten Filter
- Intel-NUC NUC7PJYH mit SqueezeLite/BruteFIR (

siehe hier bzw. SqueezeLite und AcourateConvolver. Nachteil: Aufgabe der Bedienung über Touch-Display.
- Intel NUC mit Roon und USB auf den mutec (größe Änderung, da Umstieg auf Roon)
- Standalone HTPC mit JRiver (noch größere Änderung, Aufgabe meines MultiRooms)
-

Inguz LMS Plugin: funktioniert nicht mehr mit 7.9.2.
- Offline Convolution auf dem Server auf separater Fetplatte: Nachteil ist, dass ich bei Änderungen alle Dateien rekodieren muss.
- ein NAS mit

Convo.FS. Vorteil: online-convolution.

Gibt es wirklich kein Digital-In/Digital-Out Gerät mit DRC?
Was würdet Ihr empfehlen? Weitere Ideen?

3. DRC Software
- AudioVero Acourate von Uli Brüggemann: wohl kompliziert, dafür mächtig. Sehr guter Support.
- Dirac-Live Vorteil: Messen mehrerer Positionen. Nachteil: fest an Windows/MAC über einen Audio Treiber gebunden, kein Filter-Export
- MathAudio Vorteil: günstig, einfach, Nachteil: kein Filter Export.
- AudioLense (nicht näher angeschaut)
-

DRC Designer. Vorteil: kostenlos, Nachteil: kompliziert, wenig Einstellmöglichkeiten
-

Home Audio Fidelity bieten Filtergenerierung für ca. 110€-240€. Sehr interessante Alternative mit HTRF (head model), leider kostet dann jeder Filter nochmal €40 aufwärts. Sehr guter Support

Meine Wahl wäre Acourate.
Was haltet Ihr von der Crosstalk Optimierung, dem Multi-Positionsmessungen, und dem Kopfmodell von Home Audio Fidelity?

Danke für Eure Antworten
Thomas

[Beitrag von magnetonic am 21. Apr 2019, 11:22 bearbeitet]

magnetonic
Schaut ab und zu mal vorbei

#2 erstellt: 26. Apr 2019, 23:57

Ich habe vermutlich eine Lösung, herzlichen Dank an Abacus.
- Raspberry Pi 3 + HifiBerry Digi Pro
- Aroio OS mit BruteFIR (Filter mit AcourateCV oder Acourate erstellbar)
- intern wird auf 96kHz gesampled

Eine weiter Lösung w#re natürlich der AudioData AudioVolver für >2k€.
Die Einmessung erfolgt aber dann durch eine Service Person.

magnetonic
Schaut ab und zu mal vorbei

#3 erstellt: 23. Aug 2019, 06:41

Ich habe die Lösing mit AroiOS seit einiger Zeit. laufen und bin soweit zufrieden.
Aber: ab und zu kommt es zu Clicks und Sprüngen in der Wiedergabe.

Irgendwelche Ideen?

Sathim
Inventar

#4 erstellt: 23. Aug 2019, 09:57

Ideen zu deinen Problemem habe ich keine - dafür vielleicht lieber direkt im Abacus-Forum fragen...

Aber ein konkreter Erfahrungsbereicht wäre schön, da ich auch schon
über diese Lösung nachgegedacht habe - ich möchte in meinem künftigen
Musikzimmer eigentlich auch vom permanent laufenden PC weg.

Ich besitze Acourate schon, möchte das auch weiterhin für die "über-alles-Entzerrung"
nutzen - meine Aktiv-LS werde ich aber über ein Extra-DSP ansteuern, das ist
in Summe einfacher ... In dieses DSP will ich dann digital rein.

magnetonic
Schaut ab und zu mal vorbei

#5 erstellt: 23. Aug 2019, 18:08

Gerne.

Ich hatte den Raum schon vorbehandelt und ca. 350ms Nachhallzeit ab ca. 300Hz.
Im Bereich unter 100Hz habe ich noch ca. 800ms. Ich habe zwei Moden bei 26Hz und 47Hz. Auch ein Helmholtz Resonator hat nur wenig gebracht.

Ich war und bin mit dem Klang ohne Korrektur zufrieden, wobei man schon eine Basslastigkeit hört.

Die Installation von AroioOS auf dem Raspberry ist sehr leicht, lässt sich auch gut per Webinterface ansteuern. Meine Touch ist synchronisiert, so sehe ich die Album Informationen und habe ein User Interface.
Ich habe mir auf eBay ein 5V lineares Netzteil besorgt. Alles klein und schnuckelig.

Ohne Korrektur klanglich kaum ein Unterschied zur Touch, da ich über Cinch oder Toslink über einen Reclocker in den DAC gehe.

Das Messen mit Acourate und das Erzeugen der Filter fand ich einfach. Die Anleitung im Netz ist einfach.
Man muss die Filter halt händisch per SSH auf den AroioOS Raspberry kopieren.
Zwischen den Filtern lässt sich live per Webinterface umschalten.

Bisher habe ich die Default Werte für FDW und Excess Phase der Acourate Makros übernommen. Bisher mit der psychakkustischen Mittelung, wobei Experten wie Fujak 1/12-Octave Sliding empfehlen. Das steht demnächst an.
Hinsichtlich Frequenzverlauf bin ich der Empfehlung -3dB bei 10kHz gefolgt und habe insgesamt nur um 4dB abgesenkt, habe also hauptsächlich die Peaks abgeschnitten.

Der Unterschied mit/ohne FIR Filter ist dennoch gewaltig.
Der Bass ist super knackig geworden. Bühnenbild war und ist immer noch exzellent, s-Laute etwas klarer.
Aufnahmen mit tiefen Drums (Kodo) und elektronische Aufnahmen wie Yello klingen deutlich klarer und dynamischer.

Kann ich sehr empfehlen.

Kosten: Raspberry+DigiBerry+Black steel Case+Netzteil. 120€
Acourate 340€
Mikro: iSemCon EMX 7150

Das ist eine sehr günstige Alternative zu einem DEQX HDP-4/5 oder Trinnov Amethyst, die das natürlich einfacher und schicker. Nach den Tests bei audiosciencereview.com und anderen Erfahrungen sollte man aber einen externen DAC und keinen Raspberry Aufsatz verwenden.

Die Clicks scheinen ein generelles Raspberry Pi Problem von USB und Gigabiit Ethernet zu sein. Es gibt Vorschläge, z.B. Brutefir auf einen core zu beschränken oder 100MBit umzuschalten.

https://github.com/raspberrypi/linux/issues/2215

[Beitrag von magnetonic am 24. Aug 2019, 08:19 bearbeitet]

magnetonic
Schaut ab und zu mal vorbei

#6 erstellt: 07. Sep 2019, 14:46

Update:
Ich habe einiges probiert. Man kommt ja schlecht an das Dateisystem ran, da Aroio OS ab Version 4.16 ein zImage benutzt.

Die Clicks haben sich durch Zurückgehen auf 4.15.53 deutlich reduziert. Sie treten maximal alle 30 Sekunden auf.

Ich habe mit top die CPU Auslastung des Raspberry beobachtet. Ab und zu kommt es zu Auslastungsspitzen. Squeezlite benötigt auch bis zu 30% in den Peaks.

Interessant ist, dass die Clicks nicht zufällig zu sein scheinen, ich kann einige im selben Stück reproduzieren, Ich glaube daher, dass es CPU Überauslastung ist.

Könnte daher sein, dass die Clicks mit dem schnelleren Raspi 3B+ ganz weg wären.

Buschel
Inventar

#7 erstellt: 07. Sep 2019, 15:23

Wenn du die dropouts immer an derselben Stelle im Titel hast, kann es auch sein, dass es sich um Übersteuerung (clipping) handelt. Das kann sowohl im Prozess der Raumkorrektur als auch der Sampleratenkonversion (du gibst an, dass alles auf 96 kHz gewandelt wird) passieren.

Wie kannst du das testen? Nimm einen FLAC/WAV Titel, bei dem das passier, ändere den Pegel des Titels mit einem WAV-Editor und speichere als neue Datei ab. Dann spiele beide vergleichend ab.

Auch wundere ich mich über die Wandlung zu 96 kHz. Das ist rechenintensiv. Warum machst du das und kannst du das nicht -- auch nur zur Probe -- deaktivieren?

magnetonic
Schaut ab und zu mal vorbei

#8 erstellt: 07. Sep 2019, 19:35

Hi Buschel,

danke für die Tips.
Die Reproduzierbarkeit bezieht sich nicht auf die genaue Musikstelle sondern eher in der gleichen Passage (dort tritt mit einer Wiederholbarkeit von ca. 80% ein Glitch/Knacksen auf). Dementsprechend hat eine Absenkung um 5dB auch nichts geändert.

Die Samplingrate hat etwas gebracht. Ich habe probeweise auf 44k runtergestellt, dann sinkt die Prozessorlast von SqueezeLite von ~30% auf ~11% und Knacksen ist wohl verschwunden.

Leider muss man in der Weboberfläche eine Rate einstellen. Mir wäre die native Rate auch am liebsten, die Option habe ich nicht gefunden. Ich habe die Scripte angeschaut, ist kompliziert/undokumentiert in /usr/bin/controlaudio und /usr/bin/controlbrutefir.

Ideen?

Buschel
Inventar

#9 erstellt: 07. Sep 2019, 22:05

Ok, das hört sich dann definitiv nach Lastproblemen an. Ich habe hier brutefir auf einem NUC laufen und spiele mit Kodi ab. Von daher gibt es bestimmt ein paar Ansätze, aber nicht alle werden für dich passen bzw. anwendbar sein. Ich weiß leider nicht was das aroio image enthält und wie es funktioniert. Wenn du Zugriff per Konsole hast, können wir ein paar Dinge checken.

1. Welche Last verursacht brutefir selbst?
2. Wird ein alsa aloop device benutzt, um den Mediaplayer and brutefir anzuflanschen? Oder läuft das ggf. über pipes?
3. Kannst du prüfen, ob ein low latency Kernel installiert ist? Wenn nein, kannst du den installieren?
4. Hast du Zugriff auf die brutefit config Datei? Und: Wird diese ggf. durch vorinstallierte Skripte automatisch erstellt? Falls Zugriff darauf besteht, kann man -- abhängig davon, was bereits eingestellt ist -- die Last auf Kosten der Latenz weiter reduzieren.
5. Du hast Acourate und kannst auch die Filterlänge reduzieren? Das ist eine weitere Option zur Lastreduktion, geht aber auf Kosten der Filterauflösung im Frequenzbereich. Ob und wie sich das hörbar auswirkt, hängt vom Filter ab, das du erstellt hast.

Gerade mit 3 und 4 habe ich gute Ergebnisse erzielt. Bei Punkt 2 kann man etwas tun, falls ein aloop device benutzt wird. Dazu mehr, falls das relevant sein sollte.

magnetonic
Schaut ab und zu mal vorbei

#10 erstellt: 08. Sep 2019, 14:12

> 1. Welche Last verursacht brutefir selbst?

Sampling Freq 44kHz/FLAC 44kHz:
BruteFir 2 PIDs je 8%, Squeezelite 2% (beobachtete Peakwerte)
Keine Glitches.

Sampling Freq 44kHz/FLAC 96kHz:
BruteFir 2 PIDs je 7.7%, Squeezelite 32%
Einige wenige Skips/Glitches.

Sampling Freq 96kHz/FLAC 44kHz:
BruteFir 2 PIDs je 20% Peaks (13% Average), Squeezelite 34%
Einige wenige Skips/Glitches.

Sampling Freq 96kHz/FLAC 96kHz:
BruteFir 2 PIDs je 20% Peaks (14% Average), Squeezelite 4.6%
Kaum Glitches.

Sampling Freq 192kHz/FLAC 44kHz:
BruteFir 2 PIDs je 31% Peaks (14% Average), Squeezelite 61%
Und in der Tat gibt es hier permanent Skips/Clicks/Glitches! Damit ist das Upsampling als Ursache klar.

2. Bin kein Linux Experte: Laut systemctl/journalctl --boot läuft der Jack Mixer, BlueAlsa und Squeezelite in Aloop.

3. Keine Ahnung leider. Aber ich glaube nicht!? Leider gibt es von Aroio nicht die Sources, daher kann ich nicht neu komplieren. Die Version 4.15.53 nutzt noch ein rootfs.cpio (wobei ich da auch kein Glück hatte, Dateien zu modifizieren), Version 4.16.37 nutzt ein zImage (da konnte ich nicht mal die Files extrahieren).

# uname -a
Linux AroioOS 4.19.34-v7 #3 SMP Thu Apr 25 19:47:05 CEST 2019 armv7l GNU/Linux

4, BruteFir_config wird erzeugt, aber ich hatte händisch einmal float_bits: 64 eingetragen und BruteFir neu gestartet, was das Problem leicht vergrößert.
## GENERAL ##
sampling_rate: 96000;
filter_length: 65536,2;
overflow_warnings: true;
show_progress: false;
max_dither_table_size: 0;
allow_poll_mode: false;
powersave: false;
monitor_rate: false;
lock_memory: true;
sdf_length: -1;

5. Habe ich auch gemacht, wobei das Ergebnis hörbar schlechter wurde.

Man kann bei Aroio Files von der SD Karte mittels /custom_overlay in das OS übertragen, also könnte man schon Skripte einfügen.

Buschel
Inventar

#11 erstellt: 08. Sep 2019, 15:30

Danke für die vielen Details. Ich denke damit ist bekräftigt, dass sowohl die hohe Last dropouts verursacht, als auch die hohe Last durch Resampling verursacht wird. Dropouts dürfen aber auch nicht selten auftreten, sondern gar nicht. Mich hat das auch verrückt gemacht bevor ich die Lösung für aloop gefunden hatte.

Nun ist die Frage: Warum treten die dropouts auf? Sind das buffer-underruns auf dem brutefir-input oder -output? Von meinem Setup kenne ich vor allem underruns auf dem brutefir-input, wenn ich dafür ein aloop-device nutze. Diese stehen aber nicht in Verbindung mit der Last und sind systematisch bedingt: aloop simuliert die gewählt Taktrate (von z.B. 96 kHz). Wenn diese aber leicht zu gering ist, füllt der Player zu wenig Daten und der über USB vom echten Takt bediente Verbraucher rennt in den underrun. Das lässt sich über ein Script (Beispiel für mein Setup:

Klick mich) umgehen, dass die aloop-Taktrate auf Basis des Pufferstands nachregelt. Eventuell ist das auch für dich einen Versuch wert.
Anders sieht es aus, wenn die dropouts aufgrund von buffer-underruns am brutefir-output auftreten, worauf ich wegen der Verbindung zur Last tippe. Dann hilft nur "low latency", geringere Filterlänge (laut brutefir config setzt du 128k Länge ein?) und das Ausführen von brutefir als root (dann laufen die thread mit sehr hoher Priorität). Wegen "low latency" würde ich einfach mal bei abacus nachfragen. Die scheinen ja recht auskunftsfreudig zu sein. Eventuell ist der Kernel bereits entsprechend konfigiriert, oder sie stellen ein entsprechendes image bereit.

Kannst du nochmal die gesamte brutefir config (mit den I/O Konfigurationen) und die alsa config posten?

Edit: Ich wundere warum es zu so deutlichen Einbußen im Klang kommt, wenn du die FIlterlänge reduzierst. Wie bist du dabei vorgangen?

[Beitrag von Buschel am 08. Sep 2019, 15:49 bearbeitet]

magnetonic
Schaut ab und zu mal vorbei

#12 erstellt: 08. Sep 2019, 22:24

DropOuts sind nervig, so schlimm wie die Pops bei Schallplatten. Reißen einen immer aus der Musik raus.

Achtung! Mein Output ist der SPDIF des HifiBerry Digi+, nicht USB. Daher sind die Raspberry USB Timing Probleme unkritischer.

BruteFir Config:
## INPUTS / OUTPUTS ##
input "left", "right" {
device: "jack" { ports: "" , "" ; priority: 50 ; };
sample: "AUTO";
channels: 2;
};

output "left", "right" {
device: "jack" { ports: "jackmixer:in1_left" , "jackmixer:in1_right" ; priority: 50 ; };
sample: "AUTO";
channels: 2;
delay: 0 , 0;
maxdelay: 8000;
};

im BruteFir Log findet sich folgende von Jack:
Jul 12 16:01:17 AroioOS taskset[442]: JACK I/O: Warning: JACK is not running with SCHED_FIFO or SCHED_RR (realtime).
Jul 12 16:01:17 AroioOS taskset[442]: Realtime priorities are min = 49, usermax = 48, mid = 50 and max = 51.
Jul 12 16:01:17 AroioOS taskset[442]: Warning: no support for clock cycle counter on this platform.
Jul 12 16:01:17 AroioOS taskset[442]: Timers for benchmarking may be unreliable.

Beim Abspielen entstehen zahlreiche Peak Messages, z.B.:
Jul 12 16:36:12 AroioOS taskset[442]: peak: 0/26/+0.95 1/9/+0.39
Jul 12 16:36:14 AroioOS taskset[442]: peak: 0/30/+0.95 1/9/+0.39
Jul 12 16:36:17 AroioOS taskset[442]: peak: 0/54/+1.09 1/23/+0.39

Deutet das doch auf Übersteuern?

Dein Script funktioniert nicht bei mir (wahrscheinlich weil doch kein aloop verwendet wird).
Der HifiBerry ist card0, pcm0c ist "closed", daher habe ich den playback genommen: /proc/asound/card0/pcm0p/sub0
Das Skript gibt folgendes aus (amixer mag die Parameter nicht):
amixer: Cannot find the given element from control hw:0
amixer: Cannot find the given element from control hw:0

uptime: 000000s bufsize: 8192 filled: 51% clk: 99000
amixer: Cannot find the given element from control hw:0

uptime: 000001s bufsize: 8192 filled: 85% clk: 101000
amixer: Cannot find the given element from control hw:0

uptime: 000002s bufsize: 8192 filled: 12% clk: 99000

Das Thema mit dem 64k Filter:
ich hatte mit dem LogSweep Recorder mit Target Length 131072 aufgenommen. Der erzeugte Filters zeigte einen sehr schönen Step Impuls und auch der Klang ist frisch. Für die 65536 Filter musste ich nochmal das Mikro nachjustieren (sollte aber an der gleichen Stelle sein). Ansonsten habe ich die Makro-Werte gleich gelassen. Aber: der Klang ist flach/leblos. Auch die Step-Funktion sieht deutlich schlechter aus.
Uli hat mir eine Anleitung für Cut'n'Window geschickt, damit ich den alten Sweep auf 64k modifizieren kann. Schaue ich mir demnächst an.

Buschel
Inventar

#13 erstellt: 09. Sep 2019, 08:59

Ok, mein Skript funktioniert nicht, weil brutefir bei dir über jack und nicht aloop angebunden ist. Macht nix, dann hast du das Problem nicht, das mein Skript lösen würde. Das wiederum würde bei SPDIF genauso auftreten wie bei USB. Es wäre dabei einfach so, dass die Quelle (dein Player) nicht so schnell Daten liefert wie sie vom SPDIF/USB abgerufen werden.

Zu deinem log: Ja, "peak: 0/26/+0.95 1/9/+0.39" deutet auf Übersteuerung hin (in diesem Fall +0,95 dB links, und +0,39 dB rechts). Das sollte zwar vermieden werden, ist aber nicht dein Problem. Du hast ja bereits getestet, dass eine Absenkung des Pegels der Datei das dropout-Verhalten nicht verändert. Diese Übersteuerungen kannst du aber recht einfach loswerden, indem du entweder dein Filter um 1-2 dB absenkst, oder diese Absenkung in der brutefir config machst. Beispiel für eine Absenkung des linken Kanals um 2,0 dB:

from inputs: "left"/2.0;

Im log ist leider nicht erkennbar, ob die Filter Prozesse mit hoher Prio laufen (das geht nur, wenn brutfir als root gestartet wird, z.B. über "sudo"). Bei mir sieht das so aus:

[...]
Realtime priorities are min = 2, usermax = 1, mid = 3 and max = 4.
[...]
Realtime priority 1 set for cli process (pid 1234)
Realtime priority 3 set for input process (pid 2345)
Realtime priority 4 set for filter process (pid 3456)
Realtime priority 4 set for filter process (pid 4567)
Realtime priority 3 set for outout process (pid 5678)
[...]

Wenn es zu dropouts oder Sprüngen kommt sehe ich folgende Meldungen:

ALSA I/O: overflow! (read on audio_input)
ALSA I/O: underflow (write on audio_output)

Siehst du solche Medlungen auch? Wenn nicht, liegt dein Problem doch noch ganz woanders...

Du kannst mir die 128k tap Filter für eine Samplingfrequenz gerne über einen fileshare zur Verfügung stellen. Ich kann dann auf die Schnelle auf 64k und 32k taps reduzieren. Du kannst diese danach kurz gegenchecken bzgl. Last und Klang.

Aus Neugier: Hast du bei abacus wegen "low latency" Kernel nachgefragt?

magnetonic
Schaut ab und zu mal vorbei

#14 erstellt: 09. Sep 2019, 21:48

Nochmals danke für die guten Tips. Langsam lerne ich, wie das funktioniert.

In der Tat funktioniert der /2.0 sehr gut, damit sagt das CLI von brutefir:
# nc 127.0.0.1 3000
> ppk
peak: 0/0/-1.67 1/0/-2.23

Aber die Pops sind erwartungsgemäß noch genauso da.

brutefir läuft unter root, hier die Journal Einträge
Jul 12 16:01:17 AroioOS taskset[451]: Realtime priorities are min = 49, usermax = 48, mid = 50 and max = 51.
Jul 12 16:01:17 AroioOS taskset[451]: Realtime priority 50 set for callback process (pid 451)
Jul 12 16:01:17 AroioOS taskset[451]: Realtime priority 48 set for cli process (pid 506)
Jul 12 16:01:17 AroioOS taskset[451]: Realtime priority 51 set for filter process (pid 505)
Jul 12 16:01:17 AroioOS taskset[451]: Realtime priority 51 set for filter process (pid 504)

Keine Alsa Underrrun messages im journal, aber Folgendes, die Meldungen passen zu den Skips:
Jul 12 16:46:09 AroioOS squeezelite-starter[1521]: [16:46:09.573431] _output_frames:72 skip 441 of 441 frames
Jul 12 16:45:39 AroioOS squeezelite-starter[1521]: [16:45:39.706641] _output_frames:72 skip 441 of 441 frames
Jul 12 16:45:13 AroioOS squeezelite-starter[1521]: [16:45:13.338912] _output_frames:72 skip 441 of 441 frames
Jul 12 16:45:03 AroioOS jack-starter[1310]: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Jul 12 16:45:03 AroioOS jack-starter[1310]: JackEngine::XRun: client = jackmixer was not finished, state = Triggered
Jul 12 16:45:03 AroioOS jack-starter[1310]: JackEngine::XRun: client = brutefir was not finished, state = Running
Jul 12 16:44:48 AroioOS squeezelite-starter[1521]: [16:44:48.165213] _output_frames:72 skip 441 of 441 frames

Bin mir sicher, dass das damit zusammenhängt. Bisher noch keine Antwort von Abacus.

magnetonic
Schaut ab und zu mal vorbei

#15 erstellt: 09. Sep 2019, 22:56

So: nachdem ich das Journal endlich verstanden habe, habe ich den Output Buffer von SqueezeLite hoch gesetzt und BruteFir auf 4 Partitionen laufen.

Ergebnis: läuft jetzt bereits 30 Minuten ohne Skip!!!

Und auch keine peak Messages mehr.

Danke Dir

, ohne Deine Hinweise hätte ich es nicht gefunden.

Problem solved (for now).

[Beitrag von magnetonic am 09. Sep 2019, 22:57 bearbeitet]

Buschel
Inventar

#16 erstellt: 10. Sep 2019, 05:07

Na also, das sind doch gute Neuigkeiten.

Bzgl. Aroio habe ich auf der abacus-Seite nachgeschaut. Das vorletzte image (also das von dir benutzte) soll einen realtime Kernel benutzen. Von daher sollte das ok sein.

Gerade gestern habe ich wieder mit meinem Setup hier herumgespielt -- basiert auf einem i3 der 4-ten Generation. Die Last ist dort wesentlich geringer, vor allem bei FIR und SRC. Ich schätze dein Setup ist für deinen Anwendungsfall grenzwertig performant. Es macht wohl Sinn über ein Upgrade nachzudenken, um mehr headroom zu haben.

Mein Angebot zur Verkürzung der Filter steht noch. Heute ist mein letzter Urlaubstag.