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.
Antworten
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

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: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

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: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

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: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

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.

Code: Alles auswählen

#!/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
Pittiplatsch
Aktiver Hörer
Beiträge: 489
Registriert: 26.02.2012, 10:48

Beitrag von Pittiplatsch »

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
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

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.

Code: Alles auswählen

#!/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
Jake52
Aktiver Hörer
Beiträge: 439
Registriert: 06.09.2012, 09:38
Wohnort: 74635

Beitrag von Jake52 »

Hallo Andree,

ich habe meine Hörplatzmessungen mal so behandelt, wie Du das auf Seite 6 beschrieben hast.
Hat gut funktioniert, allerdings sind alle meine Versuche nach Macro 5 minimalphasig.
Habe ich irgendwas überlesen?

Schöne Grüße
Jakob
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo Jakob,
Jake52 hat geschrieben:... allerdings sind alle meine Versuche nach Macro 5 minimalphasig.
Deine Rückfrage erinnert mich daran, dass ich in meiner Beschreibung nur nebenbei erwähnt habe, dass es ausschließlich um die Berechnng der mp-Dateien geht.
Buschel hat geschrieben:Die Lösung für mich war eine Änderung des Ablaufs, aus dem die "mp"-Dateien berechnet werden.
Für die Berechnung der Filter ist wichtig, dass für die Exzessphasenkorrektur ein einziger Satz Pulse-Dateien aus einer Einzelmessung im Acourate-Ordner verfügbar bleibt, z.B. der am eigentlichen idealen Hörplatz gemessene.
Also: Ein Satz Pulse48.dbl bleibt unverändert im Ordner, der Satz Pulse48mp.dbl wird durch den manuell erzeugten ausgetauscht. Dann die Makros für Inversion und Filterberechnung ausführen.

Ich hoffe jetzt klappt´s. ;)

Grüße,
Andree
Bild
Jake52
Aktiver Hörer
Beiträge: 439
Registriert: 06.09.2012, 09:38
Wohnort: 74635

Beitrag von Jake52 »

Ja danke,

funktioniert. Man sollte eben immer richtig über das nachdenken, was man gelesen hat!
Schönen Abend noch
Gruß Jakob
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hi Jakob,

gut, dass es jetzt funktioniert. Habe gerade nochmal nachgedacht. Es sollte auch klappen, wenn man die aufaddierten Pulse48.dbl als Input für die Exzessphasenkorrektur im Ordner hat. Die Pulse48mp.dbl-Dateien müssen natürlich immer noch per Hand erzeugt werden.

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

Beitrag von Buschel »

RESTEK MAMS+ Software Update

Vor wenigen Tagen habe ich meinen MAMS+ von RESTEK mit einen Software Update zurück bekommen. Motivation für das Update war vor allem die wegen eines Fehlers nicht abschaltbare blaue Status-LED im Inneren des Gehäuses. Im verdunkelten Raum war das Blinken der recht hellen LED doch durchaus irritierend -- z.B. beim Schauen von Filmen mit Lautsprecherbetrieb für den richtigen Kick. Von Herrn Elschot wurden im Vorfeld "sehr viele Bugfixes und einige Features" angekündigt.

Nach dem Wiederanschließen hat das beigelegte Infoblatt dann Neugier bei mir ausgelöst: Offenbar wurde die Wiedergabemöglichkeit über AirPlay implementiert. Außerdem gibt es einige neue Settings, um Performance und IP-Konfiguration des verbauten BubbleUPnPServers zu beeinflussen, sowie die Möglichkeit zur Konfiguration des BubbleUPnPServers über einen Webclient.

Die Wiedergabe via AirPlay muss man per Menu aktivieren, wobei man sich zwischen AirPlay und UPnP entscheiden muss. Wenn AirPlay aktiv ist, erscheint der MAMS+ unter dem Namen "RestekMAMS" in der Auswahlliste der AirPlay-Geräte meines iPhones. Das Streamen von Musik über die amazon music app klappt wunderbar, es werden auch Titel/Artist/Gerne angezeigt. Allerdings gibt es dabei einen Fehler: Titel/Artist/Gerne werden nur einmal übernommen, und die Wiedergabezeit und -status bleiben bei "0:00" und Pause stehen. D.h. es erfolgt kein Update der Daten. Daran wird RESTEK noch etwas arbeiten müssen. Die Audiowiedergabe selbst lief aber ohne Probleme.

Für mich viel interessanter ist aber ein anderes nicht erwartetes Detail. Die neu aufgespielte Software für den MAMS+ setzt eine sehr neue Version vom BubbleUPnPServer (0.9-update29 vom 18.02.2018) ein. Diese erlaubt nach einfacher Web-Konfiguration auch das Abspielen von Audioformaten, die der von RESTEK eingesetzte Renderer eigentlich nicht unterstützt. In diesem Fall dekodiert das offenbar ebenfalls installierte ffmpeg diese Titel und gibt sie als WAV oder LPCM an den Renderer weiter. Ich höre hier gerade einige meiner alten musepack-Dateien ohne Probleme und mit Anzeige von Artist/Titel/Gerne auf dem MAMS+. Respekt, der Renderer wird damit zum Schweizer Taschenmesser für Audioformate. 8)

Für die notwendige Einstellung ruft man den Web-Client des BubbleUPnP Servers (IP und Port können über das Menu ausgelesen werden) auf und setzt im Bereich "Media Renderers" für den "Restek MAMS+" die Einstellung "Decode audio to PCM for: All audio formats + constraints below". Ich gehe davon aus, dass damit so ziemlich alles abgespielt werden kann, was ffmpeg dekodieren kann. Das wiederum dürfte so ziemlich jedes Audioformat sein (Supported Codecs).

Viele Grüße,
Andree

PS: Ach ja, die blinkende LED kann ich jetzt auch abschalten. 8)
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Mobiles Setup und CIEM

Seit über einem Jahr höre ich vermehrt mit Kopfhörern, meistens über mein stationäres Setup zu Hause, aber auch mobil auf Dienstreisen und zu Hause auf dem Sofa. Beim mobilen Setup verwende ich seit Jahren in-ears, deren Dämpfung von Außengeräuschen ich sehr schätze. Das ist vor allem bei Reisen (z.B. im Flieger) ein Vorteil, entkoppelt mich aber auch bestens, wenn ich mal einfach Ruhe haben möchte.

Die letzten 10 Jahre
Die letzten etwa zehn Jahre habe ich als mobilen Zuspieler einen iPod nano (sehr klein, sehr lange Laufzeit, schneller Prozessor, aber mittelmäßiger Klang) und einen iPod Video (mittlere Akkulaufzeit, mehr Speicherplatz, besserer Klang) betrieben. Die iPods habe ich gekauft, weil ich die open source Firmware rockbox darauf spielen konnte. Zum einen konnte ich mit rockbox meine musepack Audiodateien abspielen, die für mobile Zwecke über lange Zeit die beste Wahl waren, weil sie hohe Qualität bei moderater Kompression erzielen und im Vergleich zu mp3/aac mit deutlich weniger Prozessorleistung dekodiert werden können, was die Laufzeit der Player dramatisch erhöht. Zum anderen konnte ich mich bei rockbox auch selbst einbringen, was ich dann über mehrere Jahre auch mit viel Freude im Bereich Audiocodecs/iPod/Treiber gemacht habe.
Mittlerweile sind die iPods aber in die Jahren gekommen und zeigen deutliche Alterserscheinungen wie z.B. nicht mehr passende Spaltmaße, abgenudelte Multifunktionsknöpfe und reduzierte Akkulaufzeit. Dazu kommt, dass Flashspeicher mittlerweile so günstig geworden ist, dass ich musepack und eine reduzierte Titelauswahl nicht mehr brauche -- alle meine Titel passen mit entsprechender Erweiterung per SD-Karte als flac auf einen einzigen Player.

Bild
Das langjährige Setup

Angetrieben durch verstärkte Reisetätigkeit und dadurch intensivere mobile Nutzung kam der Wunsch nach einem Update des Kopfhörers auf. Ich habe dann kurzentschlossen und rückblickend nach zu wenig Probehören meinen Sennheiser CX-300 II durch einen Shure SE425 ersetzt. Der SE425 war zwar ein deutlicher Fortschritt gegenüber dem CX-300 II, aber machte auch die Probleme der iPods sehr deutlich hörbar: Grundgeräusche, Verzerrungen. Dazu kam, dass mir vor allem wegen des SE425 bei vielen Titel der Tiefbass und die Brillianz fehlten, die ich nur durch gezielten Einsatz von parametrischem EQ kompensieren konnte. Insgesamt unzufrieden habe ich mich dann zunächst auf die Suche nach einem Player gemacht, der meine Anforderungen erfüllt. Anschließend wollte ich mich mit diesem Player als Grundlage nach neuen IEMs umschauen.

Das DAP Update
Meine nicht verhandelbaren Anforderungen an den Player waren eine lange Akkulaufzeit (>20 h), Wiedergabe von flac, vernünftige Bedienung (Suche über Album Künstler/Album/Genre, Anzeige aller embedded cover arts, korrekte Zusammenfassung von Alben mit mehreren CDs), gapless Playback, Aufspielen von Titeln ohne Spezialsoftware (kein iTunes oder andere Hersteller spezifische Software Programme), großes Touchdisplay, manueller EQ und nicht zuletzt eine mich ansprechende Optik und Haptik. Leider gibt es offenbar kaum Möglichkeiten sich höherwertige DAPs in Ladengeschäften anzuschauen und anzuhören. Ich habe die üblichen Kandidaten von FiiO, Astell&Kern und Sony per Internetrecherche und Rückfragen bei Besitzern verglichen, mich dann entschieden und zugeschlagen.

Im Ergebnis höre ich hier seit Januar mobil über einen Sony WM1A mit einer zusätzlichen SD-Karte zur Erweiterung auf 256 GB. Die im Netz diskutierten Probleme mit zu geringer Lautstärke habe ich nicht und habe deswegen auch von der möglichen Umkodierung des Sonys abgesehen. Meine in-ears sind so empfindlich, dass ich üblicherweise weit unterhalb der maximalen Lautstärke höre. Der Player erfüllt alle meine Anforderungen und ist wertig verarbeitet. Einziges kleineres Ärgernis war, dass ich alle embedded progressive jpgs in normale jpgs wandeln musste, weil der Sony keine progressive jpgs anzeigt. Als nicht klangveränderndes Zubehör kam noch eine praktische Kunststoffhülle und eine Panzerglasfolie für das Display dazu.

Bild Bild
WM1A in der Totalen und in Nahaufnahme

Der Weg zum CIEM
Nachdem der Player vorhanden war ging die Suche nach einem in-ear weiter. Mit dem SE425 als Basis wusste ich schon an welchen Stellen ich Veränderung wollte: mehr Tiefbass, mehr Hochton aber langzeittauglich. Auch war ich interessiert an custom in-ears, weil ich mir davon eine bessere Ausblendung von Umgebungsgeräuschen und einen besseren Tragekomfort versprochen habe. Ich habe dann viel im Internet nach Herstellern, Tests und vergleichbaren Messungen gesucht, um mir einen Überblick der Hersteller und Typen zu verschaffen. Klar war für mich, dass ich für den Fall von Problemen mit dem neuen in-ear keinen Import aus den USA oder China riskieren wollte. Zur Eingrenzung auf zu hörende Kandidaten hat mir vor allem die Seite headflux.de sehr geholfen. Dort gibt es vergleichbare Messungen vieler für mich interessanter in-ear Modelle. Einer der Mitbetreiber veröffentlicht auch Messungen zum Impedanzverhalten und dessen Auswirkung auf den Frequenzgang bei Betrieb an unterschiedlichen Ausgangimpedanzen (wobei der Sony mit etwa 0,9 Ohm eher unkritisch ist).

Zum finalen Hörvergleich habe ich dann einen abendlichen Termin bei einem kleinen aber feinen Unternehmen in der Pfalz gemacht. Dort konnte ich über meinen DAP und vorausgewählte Titel mehrere Stunden Modelle der Hersteller InEar, Ultimate Ears und Vision Ears hören, wobei sich recht schnell herauskristallisierte wohin die Reise geht. Viele der Modelle hatten einen für mich unangenehmen und anstrengenden Mittel-/Hochton oder zu starken Bass. Der erste für mich spontan passend klingende Hörer war ein InEar SD4, richtig lang hängen geblieben bin ich beim InEar PP8, UltimateEars UE-11 und Vision Ears VE6. Ein (noch) höherpreisiger UltimateEars UE-18 konnte mich gar nicht überzeugen. Letztlich entschieden habe ich mich für den Vision Ears VE6 X2. Am gleichen Abend wurden die Ohrabdrücke gemacht und nach etwa 3 1/2 Wochen kam der Hörer an. Das Einsetzen und Herausnehmen braucht noch etwas Übung, aber eingesetzt sitzen die Teile wie angegossen. Sie dichten hervorragend ab, auch bei Kieferbewegung, und hören sich so an wie ich das in Erinnerung und gewollt habe: schön tiefer trockener Bass, wenn er vorhanden ist, Brillianz im Hochton und langzeittauglich, wobei schlechte Aufnahmen auch schon mal unangenehm scharf klingen. Der VE6 ist kein Schönfärber, das bin ich von meinem Heim-Setup aber auch so gewöhnt.
Einziger Nachteil ist die extrem hohe Empfindlichkeit -- ich höre tatsächlich wieder das vorher nicht wahrnehmbare weiche Grundrauschen meines Sony. Aber das lässt sich über einen passenden Adapter wieder in den Griff bekommen und ist nicht akut.

Bild Bild Bild
VE6 X2

Damit bin ich insgesamt jetzt hier gelandet und denke, dass ich das mit diesem Setup die nächsten Jahre sehr gut aushalten werde:

Bild
Setup für die nächsten 10 Jahre?

Ist zwar ein sehr langer Beitrag geworden, war aber auch insgesamt eine jahrelange Reise. 8)

Viele Grüße,
Andree
Bild
Hironimus_23
Aktiver Hörer
Beiträge: 792
Registriert: 29.12.2012, 21:49
Wohnort: Norddeutschland

Beitrag von Hironimus_23 »

Hallo Andree,

sehr interessanter Beitrag, da bei mit akuter Handlungsbedarf beim Hören auf Geschäftsfahrten (Bahn) besteht und viele deiner Anforderungen sich mit meinen decken. Vielen Dank dafür.

An den Player fordere ich für mich noch einen weiteren wichtigen Aspekt, der Lesbarkeit der Textanzeigen auf dem Display. Mein jetziger FiiO X3 II hat eine so kleine Schrift, dass ich diese ohne Lesebrille nicht mehr erkennen kann, was mir teilweise den Spaß verdirbt, weil es immer recht umständlich ist - Brille auf - Brille ab .... .

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

Beitrag von Buschel »

Hallo Hironimus,

schön, dass mein Beitrag dich als interessierten Leser gefunden hat. Dieses Forum ist ja nicht gerade ein Tummelplatz für Kopfhörer-Freunde. :mrgreen:

Zu dem Schriftgrößenproblem mit deinem FiiO-Player gibt es evtl. eine Verbesserung über eine neue Firmware: head-fi.org und fiio.me. Die Anzeige scheint laut den Forumbeiträgen damit besser lesbar zu werden.

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

Beitrag von Buschel »

Hallo zusammen,

wie ich gerade erkenne, hat mein letzter Beitrag in diesem Thread ja schon Geburtstag gehabt. :cheers:

Die letzten Wochen habe ich während ein paar freien Tagen wieder vermehrt an meinem Setup gebastelt -- abweichend von den üblichen laufenden Diskussionen ohne Turmalin, Ferrit, Solymer, Löten oder Fidelizern. Ich versuche mich eher an der Verbesserung der Bedienbarkeit über Optimieren meines Linux-System, der Player-Software und brutefir-Konfigurationen.

brutefir Konfiguration per IR, Loudness und Latenzen
Endlich funktioniert jetzt auch der Wechsel verschiedener Raumkorrektfilter, sowie das Hinzuschalten von Loudness per IR-Fernbedienung im laufenden Betrieb. Für den NUC musste ich dafür ein BIOS-Update ausführen, die Annahme der IR-Befehle ließ sich dann per lirc recht einfach umsetzen. In meiner brutefir config hatte ich bereits mehrere Filter geladen und konnte diese per script wechseln, so dass das Umschalten per script-Aufruf über irexec schnell gemacht war.
In letzter Zeit höre ich leise und auch zugegebenermaßen oft nebenbei. Leise hört sich Musik schnell blutarm an, weshalb ich mir zwei Loudnesskorrekturfilter auf Basis ISO 226-2003 (klick mich) erstellt habe, diese in brutefir lade und sie ebenfalls per IR-Fernbedienung hinzu- oder abschalten kann. Als Referenz habe ich 60 Phon genommen, und dann Loudnesskorrekturfilter für -10 Phon und -20 Phon relativ dazu erstellt. Damit hört sich die Musik bei geringer Lautstärke "runder" an. Sobald ich aber auf die eigentlich richtigeren Pegel umsteige (bei mir in Spitzen etwa bei 80 dBA), bleibt die Loudness natürlich ausgeschaltet.
Heute habe ich dann noch die Latenzen in brutefir an meinen TV angepasst. Damit passt die Lippensynchronität bei Filmen deutlich besser als vorher -- die lag satte 80-90 ms daneben. Oops.
Als netten Nebeneffekt erzeugt brutefir nach der Latenzanpassung noch weniger CPU-Last. Der kleine i3 langweilt sich regelrecht.

kodi
Mehrere Tage habe ich zum Leidwesen meiner Familie mit der Fehlersuche bei der Wiedergabe von musepack Dateien in kodi verbracht. Letztlich ist der Fehler aber gefunden und behoben, und ich kann zum ersten Mal seit Jahren musepack korrekt wiedergeben. Das bringt mir einige alte Schätze zurück, die ich bisher nicht mehr fehlerfrei anhören konnte -- z.B. eigene Aufnahmen vom Rockpalast aus den 90ern, die ich nur in diesem Format vorliegen habe.
Mit kodi schieße ich eigentlich mit Kanonen auf Spatzen, ich benutze kodi ja nur für Audioplayback. Aber die Bedienbarkeit über die iOS-App ist hervorragend, und nach meinen Tests ist kodi "bit perfect". Bis ich eine brauchbare Alternative finde, bleibe ich wohl dabei. Und die Suche nach für mich passenden Alternativen (siehe auch den nächsten Abschnitt) ist bisher erfolglos geblieben.

Volumio
Ach ja, heute habe dann noch kurz Volumio auf meinen NUC ausprobiert. Aus meiner Sicht ein Desaster. Die Erkennung der WLAN-Netze war ein Drama, die Software braucht recht lange zum Start/Shutdown, Plugins für DRC oder SRC waren nicht auffindbar. Für mich unbenutzbar, da habe ich Daphile in besserer aber auch nicht wirklich guter Erinnerung.

Ein HTPC macht zwar leider mehr Arbeit, aber die von mir gewünschte Flexibilität habe ich bei schlüsselfertigen Programmen oder Distributionen bisher nicht erlebt. Dazu kommt noch, dass das gesamte Setup nach 20-25 Sekunden Audio spielt und korrigiert. Mal schauen, ob ich mich bei Gelegenheit nochmal an resampling über sox heranwage. Bisher bin ich daran noch gescheitert.

Grüße,
Andree
Bild
Antworten