ALSA auf externen DAC anpassen /Bit Perfect

  • Schönen guten Tag Freunde,

    seit einiger Zeit versuche ich mich in das Thema einzulesen. Da ich jedoch absoluter Neuling auf dem Gebiet bin, hoffe ich auf Eure Hilfe.

    Fang ich erstmal von vorne an:
    Ich nutze meinen Raspberry 2 neuerdings mit LibreELEC, was mir soweit auch super gefällt. Normalerweise hängt dieser nur am Netzwerk und natürlich per HDMI am TV.
    Sound über HDMI funktioniert problemlos. Nur da der Raspi meine Laptop direkt am TV ersetzt hat, würde ich meinen externen DAC (Naim DAC V.1) auch gern jetzt vernünftig ansteuern.

    Das ganze bewerkstellige ich derzeit über USB (asynchron), verstehe nur nicht, wie das im Pi von statten geht.
    So werden mir in den Sound Optionen vom Pi zwei Möglichketen für den DAC angeboten:
    1. ALSA: Naim DAC-V1.Audiophilleo.com, Analog
    2. ALSA: Naim DAC-V1.Audiophilleo.com, S/PDIF

    Beide machen für mich recht wenig Sinn. Der zweite sorgt auch nur für eine ~60% Auslastung des Buffer, produziert dabei jedoch nur extrem lautes geknister.
    Der erste hingegen funktioniert prinzipiell, nur Sorgt auch dies beim Buffer für eine ~50% Auslastung -wolgemerkt auch, wenn nichts abgespielt wird- und der Sound ist 'verbesserungswürdig'. Tatsächlich hat meine Analyse ergeben, dass das Audio Signal nicht ansatzweise Bit Perfect ist, sondern eine nahezu 100%ige Fehlerquote besitzt.
    Wundern tut mich das überhaupt nicht. Für den Anfang wäre es jedoch ein guter Anfang zu verstehen, woher diese beiden Bezeichnungen kommen, wenn ich doch lediglich ein simples digitales Signal durchschleifen will.

    Erwähnen sollte ich evtl noch, dass die Bezeichnung 'Naim DAC-V1.Audiophilleo.com' auch unter Windows und im Treiber erwähnt wird.
    Außerdem habe ich leider auch nicht die Möglichkeit das HDMI Signal zu nutzen, da ich keinen AV Receiver nutze und der TV keinen digitalen Audioausgang besitzt. Zudem gibt es nichts pflegeleichteres, als den asynchronen USB Modus, mit dem ich nicht nur die Bit Perfect Analyse machen kann, sondern auch das Audio Signal überwachen kann.

    Ist es nun möglich die ALSA Treiber anzupassen (kenne mich leider nur etwas mit Windows aus) oder das Audio Signal ganz simpel durchzuschleifen?

    Vielen Dank für jede Hilfe!

    NuTSkuL

    Einmal editiert, zuletzt von NuTSkuL (17. Juli 2016 um 13:55)

  • Mein lieber Scholli, auf der Webseite von NAIM quillt der Bullshit ja nur so aus den Ritzen. Das ganze asynchronous USB-Ding ist ja der Knaller. Komplett irrelevanter Aspekt der digitalen Verarbeitungskette herausgegriffen & aufpoliert zum definierenden Feature. Whao. Respekt fuer das gelungene Marketing.

    Gut gegen solchen Kram ist ja immer Monty von xiph.org - https://wiki.xiph.org/Videos/Digital_Show_and_Tell. Kann ich wirklich nur jedem audiophilen empfehlen. Schont Nerven und Portemonaie.

    Aber mal zu deinem Problem: so wie ich das verstehe beinhaltet der NAIM einfach nur einen Audiophileo USB->S/DIF-Wandler. Yip yip. Der NAIM hat aber auch eigene S/DIF Eingaenge. Wenn es also mit dem USB nix wird, kannst du zB auch einfach das Pi-eigene I2S-Signal, welches auch zB fuer den Hifi-Berry genutzt wird, zu S/DIF wandeln. Da finden sich Wandler fuer ~15 Euro. Und fuer die aengstlichen sei angemerkt: da geht kein Bit verloren bei.

    Das wuerde ich aber auch erst als zweites probieren. Zuerst einmal kann man versuchen deinem ALSA den audiophileo beizubringen. Zu dem findet sich so einiges bei google, zB das hier:

    https://www.kernel.org/doc/Documentat…iophile-Usb.txt

    Du kannst auch mal hiermit spielen, die behaupten den NAIM mit 192KHz zu unterstuetzen: https://sites.google.com/site/picorepla…ist-of-USB-DACs. Da kannst du dir dann ggf einfach eine ALSA-Konfiguration draus ableiten.

    Was du mit den Prozentangaben fuer deine Buffer meinst verstehe ich nicht. Kannst du das mal etwas ausfuehren?

  • Wow, vielen Dank. Mit soeiner konkreten ANtwort hatte ich garnicht gerechnet :thumbs1:
    Ich werde mich geich mal dort einlesen. Darf ich fragen, wie du darauf gestoßen bist? Ich habe diverse Sachen mit ALSA, Naim, edit etc probiert, habe aber nichts vergleichbares gefunden.

    Und man mag von dem Naim Marketing halten was man mag, ich habe recht lange gesucht, bis ich das gute Stück gefunden habe, was alles bieten, was ich damals gesucht hatte und dabei auch noch nen super Sound auswirft. War dmaals einer der ersten Kaufer von dem Teil. Und im nachhinein haben auch diverse Test und Auszeichnungen mein Empfinden bestätigt :D

    Auf was das mit dem Buffer hinaus läuft, kann ich dir leider nicht sagen. Dafür jedoch, dass unter Windows mit dem richtigen Treiber, der Buffer auch nur beansprucht wird, wenn ein Audio Signal ankommt. Und selbst bei ner 96kHz FLAC wird dieser nicht ansatzweise so gefüllt, wie vom Pi im Leerlauf.
    Alles in allem ein sehr komisches Verhalten. Müsste aber denk ich n Vergleichsvideo machen, um euch das zu erklären -sollte jedoch irrelevant sein.

    Ansonste finde ich deine Theorie schon recht nett. Nur sollte nach dieser nicht der S/PDIF Output dann die entsprechende Wahl sein? Jedoch macht ja genau der die Probleme...


    edit: hab jetzt mal n Bild von dem USB Screen des Naim gemacht. Is jedoch alles ständig in Bewegung und nen Overflow hatte ich zB vorhin auch schon
    -> okay, anhängen funktioniert anscheinend nicht, deshab mal n dropbox link
    https://www.dropbox.com/s/2p9k9nd6ss2h…135347.jpg?dl=0

    Einmal editiert, zuletzt von NuTSkuL (17. Juli 2016 um 14:44)

  • Das mit dem Buffer/FLAC/etc klingt immer noch seltsam. Das Funktionsprinzip einer gebufferten Audioausgabe ist immer gleich - die audio-Hardware prozessiert einen Buffer, waehrend sie den naechsten anfragt. Der wird *immer* zu 100% befuellt - selbst komplette Stille sind halt 100% Nullbytes. Das was viel interessanter ist, ist die CPU-Auslastung. Schafft die es, den Buffer in der gegebenen Zeit wirklich zu fuellen. MP3, FLAC, WAV ist das alles pillepalle, aber wenn man Softwareinstrumente & Effekte rechnet, dann kann es zu drop-outs kommen, weil halt ein Null-Buffer eingeschoben werden muss, wo keiner hingehoert.

    Und gerade bei dem so beworbenen asynchronen Betrieb, bei dem das USB-Device fragt "hattu buffa?" kann es ja gar nicht wissen, ob du da gerade Audio produzierst oder nicht... Alles sehr seltsam, aber sei's drum.

    Ob der S/PDIF der richtige ist, haengt davon ab, wie das intern verkabelt ist. Mein Bauch sagt "ja, sollte so sein", aber wenn der DAC im NAIM einfach der DAC des Audiophileo ist, dann halt nicht - sondern dann ist der Rest vom NAIM halt "nur" noch ein Verstaerker. Ist jetzt nicht weiter wild, irgendwo muss der DAC ja stecken.

    Insofern kann auch gut sein, dass es der analoge ist, und was zB ein knistern und auch dein Bit-Perfect-100%-Fehler erklaeren wuerde: ein vertauschen der Endianess. Das hab' ich irgendwo gelesen, dass der audiophileo little endian ist. Sollte er aber big endian bestueckt werden, gibt's chaos.

    Und gesucht hab' ich einfach nur nach audiophileo & alsa.

  • So hab mich jetzt mal versucht n bisschen einzulesen. 'Puh' triffts wol am besten...

    Es hört sich abslut nach dem an, was ich benötige. Nur scheint es sich dabei nicht um AddOns, Plugins oder sonstiges zu handeln, sonder komplett eigenständige Distributionen (?).

    Mit dem piCorePlayer sollte es denk ich keine Prbleme weiter geben. Würde im Umkehrschluss allerdings auch bedeuten, dass ich mein LibreELEC nicht weiter benutzen könnte und somit sicherlich auch mein Ambilight/ Hyperion Probleme macht.
    Und die ALSA Config daraus ableiten hört sich schonal ganz gut an. Muss nur gestehen, dass ich mich schon schwer tue überhaupt das ALSA Plugin zu finden oder vielmehr zu konfigurieren.
    Oder bin ich da bei packages/virtual/alsa schon richtig?
    Einfach die entsprechende .mk Datei raussuchen und kopieren?

    Zurück zu deinem letzten Post:
    die CPU Auslastung liegt selbst beim Abspielen einer Datei noch immer bei etwa 35%. Oder anders gesagt, es ändert sich nichts. Deshab ja meine annahme, dass intern im Pi schon irgendetwas gewaltig schief läuft. Wenn er slebst im Leerlauf bei 35% und halb gefüllten Buffer is, bedeutet das für mich, dass der Pi irgendwelche Datein rüber schiebt. Das können die von dir erwähnten 0en sein. Macht sogar am meisten Sinn, da er dann ja schließlich genauso viel Arbeiten müsste. Denk ich...
    Aber wie gesagt: unter Windows verhält er sich komplett anders. Im Leerlauf Buffer 0 und alles schick. Oder kommt der Untersschied evtl daher, dass der Pi nur im synchronen Modus läuft?

    Nja, egal. Wäre halt interessant, wie ich mir ne eigene Config basteln kann oder ob ich mir evtl n Plugin baue. Die fertigen De-/Encoder sollten doch von Prinzip her dafür taugen.

    (Sorry, aber mehr als gefährliches Halbwissne hab ich momentan leider nicht...)

  • Na, zuerstmal geht es darum mit der anderen Distribution dein System zum laufen zu bekommen um zu sehen, dass eben der Audio-Player wie gewuenscht funktioniert.

    Und dann kann man sich halt anschauen, wie die das machen. Wie die alsa.conf aussieht, welche Module geladen sind usw.

    Danach dann das gleiche nachbauen im LibreOLEC. Oder dort gleich im Forum nachfragen.

  • So, da bin ich wieder.
    Hab mir jetzt den PiCorePlayer installiert und mittlerweile kann ich zumindest auf Ihn zugreifen.
    Allerdings merke ich mal wieder, dass ich bisher null mit der Materie zu tun hatte und scheitere bereits daran, Musik abzuspielen.
    Wolgemerkt habe ich auch keine Ahnung wie das funktionieren sollte. Der gute hängt zwar im Netzwerk, nur wie soll die Musik zu Ihm kommen? In den SOund settings von Windows taucht er zumindest nicht auf

  • Für den PiCorePlayer brauchst du einen Squeezeboxserver, der die Musikdatenbank und den oder die Player verwaltet.
    Als Server kannst du einen Raspberry nehmen, der dann gleichzeitig auch noch als Player fungiert. Ich habe das vor einiger Zeit mal nach dieser Anleitung eingerichtet: http://www.gerrelt.nl/RaspberryPi/wo…player-for-bbq/ (Da wird der Server vollkommen autark als Accesspoint eingerichtet. Aber darauf kann man ja auch verzichten)

    Von Synology gibt es aber z.B. auch ein Paket für den Server, so dass man das direkt auf dem NAS installieren kann und dann nur noch die Player einrichten muss.

  • Da muss ich mich erstmal in Ruhe rein lesen.
    dem logitech Media server hab ich mittlerweile auf dem raspi installiert gehabt - was ja der sqeezebox entsprechen sollte.

    ab da an konnte ich in der Toaster cast app auf meinem Android auch die squeezebox sehen und sogar Streamen, jedoch kam kein Ton heraus (zumal ich dieses ganze gestreame extrem umständlich gemacht finde).

    darauf gestoßen bin ich zufällig, als ich in den beta Optionen im picoreplayer rumgespielt hatte und es dort diese Option gab.
    Das sollte es doch prinzipiell gewesen sein, oder? Muss ich es nurnoch schaffen meinen dac anzusteuern und vor allem die bit perfect files abzuspielen. Gerade an letzteren könnte es scheitern, wenn ich nicht zufällig direkt über USB abspielen kann. upnp bzw dlna sollte denk ich keine 24/96 übertragen können

  • Es geht ja auch nicht darum, sondern darum, dann bei einem funktionierenden Setup die ALSA-Konfiguration abzugreifen.

    Auf einem eigens aufgesetzten System darfst du dann auch gerne 24/96 Inhalte abspielen und dich in dem Glauben wiegen, das wuerde einen Unterschied machen :) Beziehungsweise besser sein - waehrend es in Wirklichkeit schlechter ist, da jedes Rauschen im Band > 20KHz wieder runterreflektiert wird in den hoerbaren Bereich. Wie nachzulesen in http://people.xiph.org/~xiphmont/demo/neil-young.html in der Sektion "192kHz considered harmful".

  • Hehe, deine Kritik verstehe ich schon ;) vielmehr ging es bei der Aussage jedoch darum, dass der picoreplayer meinen dac bis 24/96 unterstützt. Und dementsprechend wollte ich auch gerne den pit perfect test mit den entsprechenden settings machen.
    sollte es jedoch immernoch eine so extrem hohe Fehlerquote geben, kann ich auch bei den jetzigen alsa settings bleiben, dann abspielen tut er die Musik problemlos (bei libreelec, siehe die ersten posts)

    Einmal editiert, zuletzt von NuTSkuL (21. Juli 2016 um 18:26)

  • Wie gesagt - der picore-player war von mir nur vorgeschlagen um die ALSA-Settings abzugreifen.

    Wenn du aber eh schon gut genug hoerst - dann wuerde ich mir das ja eh sparen. Es klang so, als ob da erhebliche hoerbare Probleme waeren. Wenn dem aber nicht so ist, sondern nur zB resampling-Artefakte das Problem darstellen (die nicht hoerbar sein sollten, aber natuerilch nicht Bitperfect sind) - dann wuerde ich mir den Aufriss gar nicht geben.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!