Andree (Backes & Müller BM Prime 8)

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.

Beitragvon Buschel » 12.02.2017, 16:13

Hallo zusammen,

heute sind mir nach einem Softwareupdate meines NUCs einige Übersteuerungen in brutefir aufgefallen. Das habe ich zum Anlass genommen, die Bitgenauigkeit der neuesten Version von kodi (17.0) bei Dekodierung von flac zu überprüfen. Fazit: Alles gut. Das Delta zu meiner per flac-Dekoder entpackten Datei ist exakt Null. 8)

Bei genauerem Hinsehen treten die Übersteuerung nur bei einigen Titeln mit komprimierter Dynamik und hohen Pegeln bei gleichzeitiger Anwendung von Filtern auf. Bei reinem Durchreichen der Titel -- wie bei Wiedergabe über KH von mir verwendet -- gibt es keine Übersteuerungen. Ich werde also wohl die Pegel der Filter um 1-2 dB absenken, um mehr Spielraum zu bekommen.

Aus Neugier habe ich dann eine schnelle Überprüfung des Dekoderergebnisses meines MAMS gemacht (Ausgabe per USB in den PC, dort die Maximalpegel beobachtet). Interessanterweise waren die Ergebnisse dort nicht reproduzierbar, d.h. bei jedem Durchlauf kam es zu leicht unterschiedlichen Maximalpegeln. Offenbar ist das ein Effekt des ASRC, der zwischen dem Dekoder als Quelle und dem USB-Port als Senke liegt.

Viele Grüße,
Andree
Bild
Buschel
Aktiver Hörer
 
Beiträge: 504
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitragvon Buschel » 12.03.2017, 01:28

Hallo zusammen,

von der Diskussion zu inter-sample overs und DAC-clipping hier im Forum angeregt habe ich mir noch einmal den Signalfluss in meinem Setup genauer angeschaut. Die SPDIF-Quellen werden unabhängig von ihrer Samplingfrequenz durch ASRC1 auf 44,1 kHz umgewandelt und per USB an meinen HTPC weitergegeben. Im HTPC kann kodi als Quelle bitgenau PCM-Signale ausgeben. Brutefir sammelt beide Signale (SPDIF-Quelle und kodi) ein, führt die Faltung mit fester Samplingrate von 44,1 kHz aus und gibt das Signal wieder per USB in den MAMS. Hier wandelt ASRC2 die Samplingrate auf 96 kHz (gemäß Datenblatt der SRC und DAC Bausteine ist dies der sweet spot) und füttert damit den DAC. Dieser wiederum führt ein 8-faches Oversampling aus und wandelt dann in ein analoges Signal um.

Bild
Digitales Flussdiagramm

Prinzipiell kann es in jeder der SRC-Stufen (ASRC1, ASRC2 und DAC-8fs) zu inter-sample overs kommen. Bisher hatte ich dazu im WM8741 das "Clipping"-Flag gesetzt, das das Signal vor der Oversamplingstufe um 2 dB absenkt. Damit wird clipping aber nur innerhalb des WM8741 vermieden. Um eine Lösung für den ASRC2 und den WM8741 zu bekommen, habe ich jetzt in brutefir eine feste Absenkung um 2 dB konfiguriert. Nun hat die gesamte Kette von kodi -- meiner hauptsächlichen Quelle -- über den ASRC2 bis zum WM8741 hinreichend headroom. Die anderen externen SPDIF-Quellen können allerdings im ASRC1 noch inter-sample overs provozieren.

Viele Grüße,
Andree
Bild
Buschel
Aktiver Hörer
 
Beiträge: 504
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitragvon Buschel » 02.04.2017, 13:03

Hallo zusammen,

meine Suche nach einem Linearnetzteil für meinen HTPC ist erfolgreich beendet. Ein Forumsmitglied hat seine HDPlex PSU angeboten, und wir sind uns einig geworden. Das Netzteil ist jetzt etwa 2 Wochen hier in Betrieb und bedient meinen HTPC. Das Netzeilgehäuse trifft absolut meinen Geschmack, es wirkt durch die dominanten Kühlrippen irgendwie martialisch und vermittelt durch das Gewicht hohe Wertigkeit. Die kleine blaue Front-LED ist im Betrieb allerdings derart hell, dass ich den Klebestreifen vom Vorbesitzer gleich wieder appliziert habe. Mit dem Netzteil betreibe ich jetzt den HTCP mit 19 V anstatt der bisherigen 12 V. Als Mitnahmeeffekt wird mit der jetzt höheren Versorgungsspannung das durch die Spannungswandler bedingte Restgeräusch aus dem lüfterlosen HTPC reduziert. Ansonsten sind mir klangliche Änderungen nicht aufgefallen -- ich habe aber auch keine intensive Vergleichssession gegen das mitgelieferte Schaltnetzteil gemacht.

Bild
HDPlex 100W LPSU

Übrigens ist das Gehäuse vom HDPlex offensichtlich von derselben Art (nur eine Nummer kleiner) wie das Gehäuse meines KHV von Mjölnir. Außerdem fand es ich beim Stöbern im Netz interessant, dass der Hersteller meines i3-NUC HTPC mittlerweile nur noch an OEMs verkauft, AMI-HiFi scheint einer davon zu sein. Der AMI-HiFi Purist Micro entspricht dem Nachfolger meines Modells -- allerdings für einen deutlich höheren Preis. Selbstkonfiguration lohnt sich hier auf jeden Fall.

Viele Grüße,
Andree
Bild
Buschel
Aktiver Hörer
 
Beiträge: 504
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitragvon Buschel » 21.05.2017, 16:19

Die Lösung eines Rätsels

Hallo zusammen,

seit geraumer Zeit habe ich ja nach dem Grund dafür gesucht, dass ich in meinem HTPC Setup sporadisch Aussetzer hatte. Vor zwei Wochen ist es mir dann wie Schuppen von den Augen gefallen. Seit gestern habe ich einen Lösungsansatz gefunden, und seit heute habe ich die Lösung in Form eines bash skripts. :mrgreen:

Noch einmal zum Problem: In meinem Setup verwende ich brutefir als Convolver und snd-aloop (eine virtuelle Soundkarte), um das Audiosignal von kodi in brutefir zu bekommen. kodi schreibt dabei in das playback device der snd-aloop, brutefir holt sich die Audiodaten vom capture device der snd-loop, wendet die Filter an und schreibt das Ergebnis wieder in das playback device des USB DACs. Im Fehlerfall kommt es zum buffer underrun, d.h. es liegen keine Daten zum Abholen an der snd-aloop an. Ich war fälschlicherweise immer davon ausgegangen, dass es sich hier um Prioritätenkonflikte handelt und kodi die Audiodaten zu langsam liefert.

Kurz und knapp: Es handelt sich aber im Kern um auseinander laufende Clocks. Das USB-device wird letztlich durch die genaue Clock im USB-DAC getaktet, die virtuelle Soundkarte besitzt eine eigene, ungenaue und zum USB-DAC asynchrone, Clock. Im Falle von underruns werden zu wenig (zu langsam) Audiodaten für brutefir zur Verfügung gestellt. Im Falle von overruns werden zu viel (zu schnell) Audiodaten für brutefir bereitgestellt -- nicht abgeholte Daten werden überschrieben. Es gibt zwei Lösungsansätze für dieses Problem.

1. Asynchrone Sampling Rate Conversion.
Dies kann über das Linux-Tool "jack" und die alsa-jack-bridge "alsa_in" umgesetzt werden. Letztlich wird aber das ungenau getaktete Signal nur neu abgetastet. Mein Gewissen unterstützt das nicht, also habe ich Umsetzung wieder verworfen.

2. Pufferstandkontrolle der virtuellen Soundkarte.
snd-aloop unterstützt das Anpassen der Clock im Bereich +/-20%. Außerdem kann man den Füllstand des Audiosignalpuffers abfragen. Das unten stehende bash skript nutzt dies aus. Es fragt den für brutefir am capture device anliegenden Füllstand ab und justiert die Geschwindigkeit, mit der die Puffer gefüllt werden, leicht nach. Damit erreiche ich jetzt einen Füllstand, der im eingeschwungenen Zustand im Bereich 70-80% pendelt. Die Audiodaten bleiben intakt (bitgenau) und werden im sauberen Takt der USB-Clock abgeholt.

#!/bin/bash

# define and initialize variables
loopc_bufsize=$(cat /proc/asound/card3/pcm1c/sub0/hw_params | grep "buffer_size: " | grep -o '[[:digit:]]*')
loopc_buf_avail=0
buf_ratio=0
seconds=0

# set default clock to 100% (= uncorrected)
amixer -c 3 cset numid=7 100000 > /dev/null

# keep filled capture buf size in the range of 70% to 80% of defined buffer size
while [ true ]
do
   # read amount of available data from loop capture device
   loopc_buf_avail=$(cat /proc/asound/card3/pcm1c/sub0/status | grep "avail       : " | grep -o '[[:digit:]]*')

   # fill rate in percent
   buf_ratio=$(($loopc_buf_avail*100/$loopc_bufsize))

   # create uptime string in %06d format
   up=$(printf "%06d" $seconds)

   # below target (<70% of overall buffer size)
   if [ $buf_ratio -lt 70 ]
      then
         echo "uptime: "$up"s bufsize: "$loopc_bufsize" filled: "$buf_ratio"% (<70%, speed up by 1%)"
         amixer -c 3 cset numid=7 99000 > /dev/null
   # above target (>80% of overall buffer size)
   elif [ $buf_ratio -gt 80 ]
      then
         echo "uptime: "$up"s bufsize: "$loopc_bufsize" filled: "$buf_ratio"% (>80%, slow down by 1%)"
         amixer -c 3 cset numid=7 101000 > /dev/null
   # normal condition (only show with 30s heartbeat)
   elif [ $((seconds%30)) -eq 0 ]
      then
         echo "uptime: "$up"s bufsize: "$loopc_bufsize" filled: "$buf_ratio"% (alles gut)"

   fi

    seconds=$(($seconds+1))

   sleep 1
done
echo "Ended\n"


Vielen Dank auch an Tobias, mit dem ich per PN in regem Austausch stand und stehe! Mit deinem patch für brutefir kann ich jetzt endlich auch sehen, in welchem device die xruns auftreten. :cheers:

Viele Grüße,
Andree
Bild
Buschel
Aktiver Hörer
 
Beiträge: 504
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitragvon Pittiplatsch » 22.05.2017, 22:28

Hallo Andree,

es ist wirklich erstaunlich was du hier geleistet hast! Ich habe bei meinen HTPC Bemuehungen ja einige Autoren von internet-Artikeln durch die sich am Thema HTPC mit brutefir versucht haben. Letzten Endes haben alle das Thema ad acta gelegt eben wegen diesem Problem was du mal eben in ein paar Zeilen Script geloest hast.
Ich werde mal versuchen wie per PN angekuendigt es allgemeingueltig in brutefir reinzuhacken - bin schon sehr gespannt :).

Mein Fazit: FIR + Stereo - DRC fuer Musik ist leicht, Fuer Stereo+Film schon schwerer und fuer Mehkanal die Koenigsklasse :).

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

Beitragvon Buschel » 11.06.2017, 12:40

Hallo zusammen,

das Skript habe ich ein wenig optimiert, so dass jetzt die Taktanpassung abgeschaltet wird, wenn der Zielbereich von 70-80% Pufferfüllung erreicht ist. Außerdem gibt das Skript nur noch Änderungen der Taktrate aus und die Regelung wird ordentlich (d.h. mit Deaktivierung der Taktanpassung) verlassen, wenn das snd-aloop device nicht mehr aktiv ist.

#!/bin/bash

# define and initialize variables
#loopc_bufsize=$(cat /proc/asound/card3/pcm1c/sub0/hw_params | grep "buffer_size: " | grep -o '[[:digit:]]*')
loopc_bufsize=8192
loopc_buf_avail=0
clkrate=0
lastclk=0
buf_ratio=0
seconds=0

# set default clock to 100% (= uncorrected)
amixer -c 3 cset numid=7 100000 > /dev/null

# keep filled capture buf size in the range of 70% to 80% of defined buffer size
#while [ true ]
while [ "$(cat /proc/asound/card3/pcm1c/sub0/status)" != "closed" ]
do
   # read amount of available data from loop capture device
   loopc_buf_avail=$(cat /proc/asound/card3/pcm1c/sub0/status | grep "avail       : " | grep -o '[[:digit:]]*')

   # fill rate in percent
   buf_ratio=$(($loopc_buf_avail*100/$loopc_bufsize))

   # create uptime string in %06d format
   up=$(printf "%06d" $seconds)

   # below target (<70% of overall buffer size), speed up
   if [ $buf_ratio -lt 70 ]
      then
         clkrate=99000
   # above target (>80% of overall buffer size), slow down
   elif [ $buf_ratio -gt 80 ]
      then
         clkrate=101000
   # normal condition, default speed
   else
         clkrate=100000
   fi

   # set clock rate of snd-aloop
   if [ $clkrate -ne $lastclk ]
      then
         amixer -c 3 cset numid=7 $clkrate > /dev/null
         echo "uptime: "$up"s bufsize: "$loopc_bufsize" filled: "$buf_ratio"% clk: "$clkrate
   fi

   lastclk=$clkrate
   
    seconds=$(($seconds+1))

   sleep 1
done

# set default clock to 100% (= uncorrected)
amixer -c 3 cset numid=7 100000 > /dev/null

echo "Capture device closed. Clock rate control disabled (clk: 1000000)."


In den letzten Wochen habe ich die Ausgaben des Skripts mitgeschnitten und mittlerweile eine aus meiner Sicht hinreichende Datenmenge gesammelt. Das Verhältnis der über timer implementierten "soft-clock" von snd-aloop zur clock des DACs hat drei Zustände, von denen zwei nur zeitlich begrenzt auftreten und einer nicht mehr verlassen wird sobald er einmal erreicht ist. In diesem stabilen Zustand läuft die "soft-clock" etwa 50 ppm schneller als die clock des DACs. In meiner Konfiguration der Puffergrößen käme es damit im Schnitt ohne Regelung alle 30 h zu einem overrun, d.h. es würde ein sample verloren.
Interessanter sind die anderen beiden Zustände, die in meinen Beobachtungen auf maximal 1000 Sekunden nach Neustart begrenzt sind. Hier läuft die "soft-clock" entweder 500 ppm schneller oder langsamer als die clock des DACs. Ohne Regelung würde im Falle der langsameren "soft-clock" in meinem Setup etwa alle 20 Sekunden ein underrun auftreten, d.h. hörbare dropouts. Mit der Regelung habe ich keinen einzigen underrun aufgezeichnet.

Bild
"soft-clock" zu DAC-clock in Prozent

Mein Fazit: Die "soft-clock" und der DAC laufen mit 50 ppm Abweichung zueinander für mich überraschend synchron. Die Regelung über Skript verhindert effektiv die bisher sporadisch auftretenden hörbaren underruns und vermeidet theoretisch auftretende overruns.

Viele Grüße,
Andree
Bild
Buschel
Aktiver Hörer
 
Beiträge: 504
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Vorherige

Zurück zu „wie ich zum aktiven Hören kam“

Wer ist online?

Mitglieder in diesem Forum: Google [Bot] und 2 Gäste