Tobias (ME Geithain RL 940 + BK XLS200, Neumann KH 120, Nubert AW-411)

audiophile Biografien unserer Mitglieder
Forumsregeln
Bei Vorstellungen steht die persönliche, subjektive Erfahrungswelt des Verfassers im Vordergrund. Insbesondere soll die Vorstellung als "Visitenkarte" des Mitglieds gewürdigt bzw. respektiert werden. Dialoge sollten hier vorrangig mit dem Verfasser und nicht mit Dritten geführt werden. Siehe auch die Forumsregeln.
Antworten
Pittiplatsch
Aktiver Hörer
Beiträge: 489
Registriert: 26.02.2012, 10:48

Beitrag von Pittiplatsch »

Hallo Andree,

ich bin gerade mit meinem Test im Heimkino fertig. Gestern habe ich noch schnell die passenden Adapterkabel geloetet (doch gut wenn man alles aufhebt :) ).
Ich habe als Filter nur einen auf die schnelle erstellten Filter der eigentlich nur zum Test der automatisierten 5.1 Messung diente genommen (10s sweep pro Kanal). Nachdem das ganze lief habe ich doch mal damit getestet. Das Ergebnis war trotz aller Einschraenkungen so ein Schritt nach vorne das ich nicht mehr zurueck moechte :).

Meine brutefir 5.1 config habe ich gleich mit auf github abgelegt:

https://github.com/TheBigW/DRC/blob/mas ... r_config51

Die settings (e.g S16_LE sample format) sind der internen soundkarte geschuldet. Die 48000Hz sample frequenz vermutlcih weil Pulse noch mitlaeuft auf meiner Ubunt Kiste und soweit ich weiss systemweit 48k erzwingt.

Mit der Last hast du recht. Beim Abspielen eines FullHD Films sind die 90% Last-Peaks von mplayer. BruteFIR laeuft auf beiden Cores mit bescheidenen 4%!!!!

Naechster Schritt: Zielhardware:

nachdem mit einer multi-channel soundkarte so schon klappt wuerde ich genau diesen Weg gehen. Ein extra USB Interface wuerde ich gerne vermeiden. Die NUCs habne ja alle leider nur digital-out per HDMI :(. Bei den bescheidenen Performanceanforderungen koennte ich mir das auch auf dem PI vorstellen, aber leider ist mir fuer den PI kein richtiger Multi-channel DAC HAT bekannt ....

Viele Gruesse,
Tobias
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo Tobias,

na also, dann dürftest du mit installierter und aktivierter HW-Beschleunigung deutlich geringere Last bei Videowiedergabe erleben. Ob das bei deinem jetzigen Rechner möglich ist, weiß ich allerdings nicht. Ist aber ja nicht so wichtig, der proof-of-concept hatte ja vor allem das offenbar erfolgreichen Mehrkanal Setup im Fokus.

Ich habe mir deine config mal angeschaut.

Code: Alles auswählen

float_bits: 32;             # internal floating point precision
sampling_rate: 48000;       # sampling rate in Hz of audio interfaces
filter_length: 4096;     # length of filters
Dass die Last durch brutefir so gering ausfällt, ist natürlich der 32-Bit-Genauigkeit, den ziemlich kurzen Filtern (4096) und der nicht angewendeten Partitionierung (zur Verkürzung des delays) zu verdanken. Die Filterlänge ohne Partitionierung erzeugt ja schon 2x4096 / 48000 s = 170 ms delay. Ich weiß natürlich nicht welches delay dein TV/Beamer einbringt, 170 ms kommt mir aber mächtig viel vor (ich habe auf etwa 23 ms justiert).

Um den delay bei gleicher Filterlänge zu verringern, kannst du z.B.

Code: Alles auswählen

filter_length: 1024,4;
benutzen. Der erste Wert bestimmt die Partitionsgröße, mit dem zweiten Wert multipliziert ergibt sich die Filterlänge. Im Beispiel wird das delay auf 2x1024 / 48000 s = 43 ms verkürzt. Die CPU-Last steigt aber deutlich an. There's no free lunch.

Falls du bei 16 oder 24 Bit Ausgangsauflösung bleibst, würde ich dither aktivieren. Bei 32 Bit kannst du das weglassen, brutefir erlaubt dann aber auch keinen dither mehr -- auch wenn es in der config aktiviert würde.
Pittiplatsch hat geschrieben:Die 48000Hz sample frequenz vermutlcih weil Pulse noch mitlaeuft auf meiner Ubunt Kiste und soweit ich weiss systemweit 48k erzwingt.
Die 48 kHz passen doch für Filme ganz gut. Dann wird auch nicht resampelt.
Pittiplatsch hat geschrieben:Die NUCs habne ja alle leider nur digital-out per HDMI :(.
Stimmt. Irgendwie dachte ich, dass ein NUC über den KH-Ausgang auch SPDIF optisch anbietet. :roll:
Hast du keinen AVR, der HDMI annehmen kann?

Viele Grüße,
Andree
Bild
Pittiplatsch
Aktiver Hörer
Beiträge: 489
Registriert: 26.02.2012, 10:48

Beitrag von Pittiplatsch »

Hallo Andree,

mit meiner derzeitigen Probeloesung ist mir der delay beim Lipsync nur minimal aufgefallen wenn ich darauf geachtet habe, aber final werde ich da wohl auch noch etwas optimieren.
Hast du keinen AVR, der HDMI annehmen kann?
Leider nicht... Wuerde denn das ganze auch ueber den digitalen Weg funktionieren? - Sprich das Audio signal zum 5.1 loopback schicken --> brutefir --> ausgabe an Intel HDA --> HDMI zum receiver.
Dann waere ich doch sicher auch wieder bei der AC3 problematic, weil auch ueber HDMI das Mehrkanalsignal wieder als AC3 kodiertes signal zum receiver muss....

Im Moment gehen meine Ueberlegungen eher dahin mir erstmal ein billigeres Mehrkanalinterface ala Asus Xonar U7 zu holen und zu versuchen damit am PI was hinzukriegen. Ich habe mal gemessen und der PI hat derzeit maximal 30% CPU Last bei der FullHD-Wiedergabe mit Audio Pass-Through. Eventuell ist da noch genug Luft :).
Einzig meine Sound-aussetzer die ich z.B mit dem RME am Raspi nie in den Griff gekriegt habe entmutigen mich da ...

Rein rechenseitig sollte das passen auch wenn sich alle Daten beim Filmestreaming ueber die USB2 Shcnittstelle des RASPI quetschen ...

Viele Gruesse,
Tobias
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo Tobias,
Pittiplatsch hat geschrieben:Dann waere ich doch sicher auch wieder bei der AC3 problematic, weil auch ueber HDMI das Mehrkanalsignal wieder als AC3 kodiertes signal zum receiver muss....
Stimmt, da war doch was... :roll:
Dann kommt die Kodierung auf AC3 wieder ins Spiel. Wieviel CPU frisst denn der AC3-Enkoder?
Pittiplatsch hat geschrieben:Einzig meine Sound-aussetzer die ich z.B mit dem RME am Raspi nie in den Griff gekriegt habe entmutigen mich da ...
Da würde zuerst einmal zwei Dinge umsetzen und schauen, ob die das Problem schon beheben:
  • Starten von brutefir mit root-Rechten, z.B. "sudo brutefir <params>".
    Dadurch werden die brutefir-Prozesse mit hoher Priorität gestartet.
  • Wechsel auf einen lowlatency-Kernel ("sudo apt-get install linux-image-<version>-lowlatency").
    Verringert Umschaltzeiten und damit die Anfälligkeit für Aussetzer.
Beide Maßnahmen haben dazu geführt, dass ich brutefir jetzt gleichzeitig mit anderen Applikationen ohne Aussetzer und mit recht geringer Latenz laufen lassen kann.

Viele Grüße,
Andree
Bild
Pittiplatsch
Aktiver Hörer
Beiträge: 489
Registriert: 26.02.2012, 10:48

Beitrag von Pittiplatsch »

Dann kommt die Kodierung auf AC3 wieder ins Spiel. Wieviel CPU frisst denn der AC3-Enkoder?
Da fehlen mir noch komplett die Ideen wie ich das umsetzen koennte... Ich muesste ja dann das Signal vom brutefir Ausgang irgendwie in den encoder kippen ....

Deine Brutefir - config lotet ja die limits Deines Systems schon ganz schoen aus. Als root laeuft es bei mir schon beim startup. Ich habe den brutefir start direkt in rc.local eingehaengt.
Ich habe seit einiger Zeit auch ab und an Aussetzer gehabt. Da es bei mir kein headless-system ist finde ich das nicht weiter tragisch. Ich hatte es vorher wochenlang am Laufen ohne auch nur einen Abbruch. Lastabhaengig scheint das auch nicht zu sein die last war teilweise bei laecherlichen 5%. Angefangen hat es bei mir seit ich mit -nodefault starte ...

Viele Gruesse,
Tobias
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo Tobias,

sporadische Aussetzer habe ich auch (gerade heute wieder)-- mit der Last hat das auch nix zu tun. Entweder treten sie gleich von Anfang an auf oder gar nicht. Im Falle von Aussetzern hilft nur einige Minuten Warten oder ein Neustart des Systems. Ich habe immer noch nicht verstanden woher das wirklich kommt. Es tritt aber nur auf, wenn ich aloop als virtuelle Soundkarte für meinen Player benutze.
Pittiplatsch hat geschrieben:Als root laeuft es bei mir schon beim startup.
Laufen die Filtere-Prozess auch mit entsprechend hoher Prio?
Pittiplatsch hat geschrieben:Da fehlen mir noch komplett die Ideen wie ich das umsetzen koennte... Ich muesste ja dann das Signal vom brutefir Ausgang irgendwie in den encoder kippen ....
Bei dem Encoder dachte ich an eine Anbindung über pipes. Es sollte ja in brutefir über

Code: Alles auswählen

device: "file" { path: "/dev/stdout"; };
eine Ausgabe auf stdout möglich sein. Kann man damit den Datenstrom nicht an den Encoder (aften) übergeben, und der gibt seinen output per pipe wieder an aplay, das letztlich auf alsa ausgibt? So in der Art

Code: Alles auswählen

brutefir <params> | aften <params> | aplay <params>
Ich habe das aber auch nie wirklich auf diese Art probiert... :roll:

Grüße,
Andree
Bild
Pittiplatsch
Aktiver Hörer
Beiträge: 489
Registriert: 26.02.2012, 10:48

Beitrag von Pittiplatsch »

Hallo Andree,

die brutefir Aussetzer sind bei mir (noch) Nebenkriegsschauplatz :). Die Aussetzer und Knackser die ich am FF UCX am PI hatte traten wirklich lastabhaengig auf wenn ich das UCX als USB / Device angeschlossen hatte. Seit ich es nur als DAC nutze und das Signal ueber hifiberry Digi zuliefere laeuft diese Strecke Knacksfrei. Eventuell habe ich Glueck und das wurde gefixt. Der PI hatte wohl generell Probleme mit mehrkanal USB interfaces,

Der pipe Ansatz hoert sich gut an - da habe ich aber auch null Erfahrungen. Soweit ich gesehen habe sollte alsa den AC3 pass-through ganz simple unterstuetzen:

http://alsa.opensrc.org/DigitalOut#Digi ... assthrough

wenn das wirklich geht koennte ich das Lastthema auch anders angehen: ein reiner Faltungs-PI der per digital in jegliches signal schluckt und gefiltert wieder digital im Ursprungsfomat ausgiebt ... das waere schon was :).

Das muss ich jetzt erstmal verdauen - also ich erwarte heute noch keine Umsetzung :).

Viele Gruesse,
Tobias
Bild
Pittiplatsch
Aktiver Hörer
Beiträge: 489
Registriert: 26.02.2012, 10:48

Beitrag von Pittiplatsch »

da muss der Mensch drauf kommen... ALSA hat wie es scheint einen einen AC3 encoder an board mit dem A52 plugin. Theoretisch sollte ich das einfach direkt einbinden koennen. Alle anderen Versuche ein mehrkanal-wave and meinen receiver zu schicken sind gescheitert und ich kriege dann nur Stereo - output. Vermutlich weil mein receiver das nicht kann.

Ich bin gespannt ob das jemals am PI funktioniert, aber eine elegante Loesung waere das schon :).
Bild
Pittiplatsch
Aktiver Hörer
Beiträge: 489
Registriert: 26.02.2012, 10:48

Beitrag von Pittiplatsch »

wenn man ein bisschen sucht findet man recht schnell das man dafuer fuer AC3 und das A52 ein bisschen die ~/.asoundrc anpassen muss:

Code: Alles auswählen

pcm.a52encode {
	type rate
	slave {
		pcm {
		type a52
		bitrate 448
		channels 6
		card 1	
		}
	rate 48000
	}
}
leider schlaegt damit speakertest unter osmc fehl :(. In raspbian sieht es besser aus, also werde ich morgen mal die raspbian micro-SD ins Heimkino tragen und probieren ob:
speaker-test -D pcm.a52encode -c 6
schoen alle 6 Kanaele durchtickert :). Wenn das geht sollte ich dieses Device eigentlich einfach bei brutefir als Ausgang angeben koennen. Wenn ich einen Receiver mit HDMI haette koennte ich dann vermutlich auf den hifiberry digi verzichten.
Auf dem SPDIF meines PC's mit Intel HDA funktioniert es wunderbar - Irgendwie geht bei mir immer alles in dem Setup wo ich es nicht gebrauchen kann :).

Viele Gruesse,
Tobias
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo Tobias,

Respekt, da hast du ja eine noch elegantere Lösung gefunden.

Ich bin gespannt wie es weitergeht. :cheers:

Viele Grüße,
Andree
Bild
Pittiplatsch
Aktiver Hörer
Beiträge: 489
Registriert: 26.02.2012, 10:48

Beitrag von Pittiplatsch »

Ich bin gespannt wie es weitergeht.
...vermutlich mit einem neuen HTPC ... Der RASPI hat scheinbar ein Problem mit dem A52 plugin:

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

das aergerliche ist das ich denke das es performanceseitig sogar klappen muesste. Ich kaempfe noch mit mir ob ich versuche mich tiefer mit dem Problem zu beschaeftigen um eventuell zu helfen das zu fixen... Es ist jedenfalls kein prinzipielles RASPI - Problem.
Nebenbei schau ich schon mal wie ich einen HTPC mit SPDIF und/oder mehrkanal analog Ausgang zusammengebastelt bekomme und ob das per RASPI mit USB 5.1 interface nicht doch gehen kann.

An Optionen mangelt es also nicht :).

Viele Gruesse,
Tobias
Bild
Pittiplatsch
Aktiver Hörer
Beiträge: 489
Registriert: 26.02.2012, 10:48

Beitrag von Pittiplatsch »

nachdem in SW bekanntlich alles geht lasse ich solche Ausreden nicht gelten:).

Ich will das A52 plugin zum Laufen kriegen habe es aber auf 3 Rechnern mit drei Distributionen nicht geschafft. Ich werde mich aber dahinter klemmen. Final soll es auf dem RASPI laufen. Da mir das aber recht viel Aufwand fuer einen recht unbestimmten Ausgang ist habe ich mir zunaechst eine Asus Xonar U7 besorgt.

Test am RASPI: Karte dran, brutefir config umgebogen und laeuft out of the box! Performanceseitig auch kein Problem, aber der RASPI hat das bekannte Problem mit Mehrkanal USB Interfaces... Knackser wie zu erwarten :(.
Ich habe zum glueck noch einen Arbeitslosen Laptop mit einer Intel i7 CPU rumliegen. Lubuntu drauf mit kodi und alles funktioniert wie es soll mit der U7. Da ist auch noch genug Rechenpower um die Latenz zu druecken :).

Das langfristige Ziel ist dennoch das ganze auf den PI zu bekommen. Ich werde also demnaechst mal im alsa IRC vorbeischneien um mir ein paar Tips fuer das a52 Plugin zu besorgen :).
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo Tobias,

ja, die liebe Last mit der Software. :mrgreen:

Ich bin auch kurz davor snd-aloop zu patchen und zu kompilieren. Mir scheint, dass die ungünstige Bufferkonfiguration zu meinem sporadischen dropout Problem führt. Und diese lässt sich nicht so einfach einstellen. Einen Durchbruch habe ich aber am Dienstag Abend noch erreicht, nachdem ich herausgefunden wie ich ein alsa-device so definiere, dass es in kodi auswählbar wird (dmix!). Jetzt kann ich zumindest in diesem device die buffer entsprechend groß setzen. Mal schauen, ob das schon genügt...

Als netten Nebeneffekt kann ich damit kodi auch zwingen in S32_LE auszugeben anstatt den default FLOAT_LE zu nutzen. Ich werde bei Gelegenheit nachmessen, ob kodi dabei richtig wandelt. Die internen Codecs geben offenbar float aus.

Grüße,
Andree
Bild
Pittiplatsch
Aktiver Hörer
Beiträge: 489
Registriert: 26.02.2012, 10:48

Beitrag von Pittiplatsch »

Hallo Andree,

das ist das Schoene: an der SW kann man gerade im open source Bereich jederzeit selber Hand anlegen :). Berichte auf alle Faelle mal ueber Deine Aenderungen und Erkenntnisse! Mit Alsa geht schon eine Menge ... wenn man lange genug sucht :).
Mann kann da unendlich viel Zeit versenken und ich bin auch immer ueber jeden schnipsel Dankbar den ich bei google Recherche finde ...

Viele Gruesse,
Tobias
Bild
Pittiplatsch
Aktiver Hörer
Beiträge: 489
Registriert: 26.02.2012, 10:48

Beitrag von Pittiplatsch »

heute Abend war mal Praxistest im Heimkino. Bilanz: so kann es (qualitativ) bleiben. Der FIR delay ist fuer mich nicht wahrnehmbar und soundtechnisch ein deutlicher Schritt nach vorne. Das Asus Xonar U7 macht sich gar nicht schlecht. Selbst im Vergleich zu meinem Oppo BDP 83 ueber die Analog-outs hoere ich keinen Unterschied. Wenn der SNR von 114db stimmt waere das auch eine Erklaerung. Sicher auch eine sehr preiswerte Empfehlung wenn man ein mehrkanal USB interface braucht.
Sobald die Raumkorrektur aktiv ist eruebrigt sich der Vergleich sowieso :). Zum Abschluss nochmal mit Musik angetestet: ganz passabel, aber mehr nicht. Im Heimkino muss man halt Aufstellungkompromisse machen und 4m Stereodreieck sind schon eine Ansage...

mal schauen wann ich das ganze auf dem RASPI zum Laufen kriege - mit Laptop + Kodi ist das ganze doch etwas hakelig (HDMI als zweiter Monitor etc...).

Viele Gruesse,
Tobias
Bild
Antworten