Beiträge von SHF

    Also zum einen solltet Ihr schon korrekterweise vdr-plugin-xineliboutput schreiben, weil vdr-plugin-xine ist ein ganz anderes Plugin von rnissl, seit Jahren nicht mehr weiterentwickelt.

    Wo es ums (VDR-)Plugin ging, steht immer Xineliboutput-Plugin.

    Bei der Fragestellung ist das Plugin aber unerheblich, da das auf die Hardwareunterstützung der Xinelib keinen Einfluss hat.


    Meine Frage bezog sich auf Xine, also xinelib und die darauf basierenden Player xine, gxine, fbxine, vdr-sxfe, vdr-sxfe... , in wieweit die den Hardware-Decoder vom RPI unterstützen.

    Zum anderen gibt es m.E. zwei Ausgabefrontends bei xineliboutput, sxfe für die X11 Ausgabe und fbfe für die Ausgabe ohne X11 ... ?

    Der zur Xinelib gehörende Player /usr/bin/xine(Debian-Paket: "xine-ui") geht auch, wenn man die MRL wie folgt aufruft: xine xvdr://VDR_IP:37890#nonache

    Die Unterstützung kommt bei Debian aus dem Paket "libxine2-xvdr" (Quellpaket: "vdr-plugin-xineliboutput").

    Prinzipiell sollte da jeder auf der Xinelib basierende Player wie fbxine gehen.
    Wenn man auf das OSD verzichten kann gehen alle Player, die einen entsprechenden rtp oder http Stream wiedergeben können.


    Dann gibt es noch das Paket "libxine2-vdr" das stammt aus den Quellen der Xinelib und ist für das alte vdr-plugin-xine.

    In wie weit die beiden kompatibel sind hab ich noch nicht probiert.


    Das vdr-plugin-xvdr ist, hat trotz Namensgleicheit mit dem Protokoll, nichts mit Xine zu tun.

    Es war der Vorläufer des vdr-plugin-vnsiserver zur Anbindung an XBMC (jetzt Kodi). Aktuell noch verwendet bei "robotv" für Android.

    Ob das Protokoll identisch ist oder nicht, konnte ich nicht in Erfahrung bringen.

    Denkbar dass das letztere für mmal nutzbar ist?

    Es ist nutzbar, siehe Post #3.

    Nochmal danke an Seahawk für's probieren!


    Inzwischen habe ich gelesen, dass auch ffmpeg die mmal-Decoder unterstützen soll.

    Da Xine auch ffmpeg als Decoder verwenden kann, könnte es auch über den Umweg gehen.


    PS.: Oder einfach LibreELEC auf dem RPi nutzen und mit dem VDR per vdr-plugin-vnsiserver verbinden ...

    Über Kodi hab ich aber doch kein OSD vom VDR?

    Abgesehen von einer selbst gebauten libxine-1.2, die das mmal-Ausgabeplugin behinhaltet, xorg usw. ...

    Auf meinem "normalen" Computern ging es mit Debian "out of the box". (normale Desktop-Installation + Xine)


    Das das mmal-Ausgabeplugin auf dem RPI nicht aktiviert ist, würde ich als Bug einstufen, weil es noch recht neu ist.


    Wie gut das mit einem laufenden X-Server harmoniert, habe ich nicht ausprobiert.

    I've never tried mmal with X11, it probably doesn't even work with X11. X11 drivers for RPi are too slow for any video playback.

    Anscheinend arbeitet man am RPI nicht wie üblich mit X.

    Da muss ich mich dann wohl erst mal einlesen, wie die grafische Oberfläche realisieren.


    Wird aber irgendwie zu machen sein.

    Notfalls mit Lirc und einem Script, mit dem man zwischen den Anwendungen umschaltet.

    Ist doch im Grunde genommen dann auch fast das selbe oder?

    Nein.

    Das eine ist eine ist ein eigener VDR als Client und das "nur" eine Ausgabemöglichkeit über das Netzwerk.

    Ich suche halt letzteres, da ich so Zugriff auf das OSD habe, als ob ich direkt am VDR sitze.


    Ausserdem ist es super simpel, da man auf dem Ausgaberechner nichts installieren oder konfigurieren muss, wenn man Xine direkt verwendet.

    Code
    1. xine xvdr://VDR_IP:37890#nonache



    @seahawk1986:

    Danke fürs testen und die Aufklärung!
    Das Fazit klingt ja recht ermutigend.


    Der Mediaplayer ist mir nicht so wichtig.

    Ich hatte sowieso überlegt, das direkt auf dem Client über Xine (oder notfalls einen anderen Player) zu erledigen.


    Die Hardwarebeschleunigung sollte auch unter X laufen, oder setzt das die Ausgabe über MMAL auf der Konsole vorraus?


    (wie man Ton vom Hardware-Decoder über HDMI oder den eingebauten analogen Anschluss bekommen kann, habe ich noch nicht herausgefunden, vermutlich wurde das nicht implementiert)

    Einen Alsa-Treiber für den HDMI-Ausgang gibt es und da du Ton über die Soundkarte bekommst, sollte es eigentlich irgendwie gehen.


    Der PI scheint aber wählerisch zu sein, was die EDID des Monitors angeht.

    Wenn man nach kein Ton am HDMI-Ausgang sucht findet man einiges:

    Audio configuration

    Unterstützt Xine den Hardware-Decoder vom Raspberry Pi?


    Ich habe jetzt zwei gegensätzliche Aussagen gefunden:

    xine/xineliboutput does not support the Raspberry Pi's hardware-decoder

    Das erste Zitat interpretiere ich als "ja" und das Zweite als "nein". Beide Quellen sind von diesem Jahr, also recht aktuell.

    Nun bin ich etwas verwirrt und hoffe, mich kann jemand aufklären.


    Meine Idee war, auf RPI-Basis, einen "dummen" Wiedergabe-Client für meinen VDR zu bauen.

    Also nur Xine auf dem RPI, als Frontend für das Xineliboutput-Plugin auf dem VDR.
    Ohne Decoder-Support kann man das Vorhaben aber wohl vergessen, denke ich.

    Damit auch andere was von dem Thema haben, noch meine inzwischen gesammelten Erkenntnisse :


    Zum Thema OLED und Einbrennen bin ich auf einen netten Test gestossen:

    https://www.rtings.com/tv/lear…etention-burn-in-lcd-oled

    Da sind auch gruselige Bilder dabei.

    OLED ist bei mir also raus ;D.


    Die RGB-SCART-Adapter die man bei Amazon billig bekommt, sollte man meiden, die können kein RGB:

    https://www.retrogamingcables.…-HDMI-CONVERTERS-TO-AVOID


    Conrad Electronik bietet aber zwei Adapter an, die RGB können sollen.

    Zu den Adaptern von der Conrad-Eigenmarke findet man natürlich nichts, aber zu augenscheinlich identischen mit anderem Label.

    Laut einiger Tests und Videos im Netz scheinen die auch brauchbar zu laufen. Sogar der Lag soll noch zumutbar sein.

    Preis wäre mit ~50€ für den kleineren auch noch akzeptabel.

    Sollte ich mir so ein Teil zulegen werde ich jedenfalls berichten.

    Das Teil diesseits des Atlantik anzuschliessen wird eine Herausforderung.


    Laut Anleitung S.18 muss man den Pool mit 60A aber absichern. Alternativ 40A, dann kann man Pumpe und Heizung aber nicht gleichzeitig betreiben, was nicht wirklich ideal ist.
    Die in Privathäusern üblichen Unterverteilungen sind mit 32A abgesichert, und die Hauptsicherung in einem Einfamilienhaus hat etwa 65A.
    Das Ding in der Schaltung anzuschliessen zu wollen kann man also vergessen. Die Installation entsprechend aufzurüsten kann man IMHO keine Option, allein was die Kosten angeht.


    Wirklich sinnvoll lässt sich hierzulande die benötigte Leistung eigentlich nur durch 2 oder 3 Phasen a 16A bereitstellen.
    Man wird den Pool also auf europäische Spezifikation umbauen müssen.


    Auf dem zweiten Bild sieht man "5,5kW Heater". Die Heizung allein zieht schon knapp 25A. Die muss man wohl gegen die 3kW-Variante austauschen müssen.

    Dazu evtl. Pumpe und Steuerung.

    Beim Kleinkram könnt ihr Glück haben, das läuft aus Sicherheitsgründen meist mit 12V aus der Steuerung.

    Da wird nichts anderes übrig bleiben, als sich an Importeur wenden.

    Ehe man an jeder Abhängigkeit hängt ...

    Code
    1. apt-get build-dep ffmpeg

    Ist doch ein Debian oder Ubuntu System?


    Den eigentlichen Fehler sehe ich nicht, aber es steht unten was mit "Qt4".

    Das lässt mich vermuten, dass es bei den grafischen Tools wie ffplay hängt.

    Das Bauen müsste man eigentlich irgendwie abschalten können und brauchen tust du sie für deinen Zwecke eh nicht.

    [...] bevor ich mich in die DDR4-Welt und deren gerade (?) hohes Preisniveau begebe[...]

    Schau dir mal das Preisniveau bei den DDR3-Ram an, das ist derzeit ähnlich.

    Die Preise haben sich in ca. 1,5Jahren etwa verdoppelt!

    Verkauf ist also durchaus auch eine Alternative.


    Und gibt es wirklich keine Boards im 50 Euro Bereich, bei denen ich alle vier Speicherriegel nützen könnte?

    Eher nicht, zumindest bei Intel, das ist deren Geschäftspolitik.

    Die günstigen Chipsätze sind begrenzt, was die Schnittstellen angeht.

    Wer mehr Features wie SATA-Ports, PCIe-Lanes oder Ram-Bänke will, soll dafür auch mehr zahlen.


    Letztere Kombi wird mir wohl kaum Vorteile gegenüber dem MSI Board mit Celeron 847 bringen.

    Von der Kombi würde ich Abstand nehmen.


    Ich würde mal bei den Mainboards mit Intel Onboad-CPU schauen.

    Bei den neueren kann die IGP AFAIK h265.

    Die liegen zwar 5€ über dem Preisrahmen, sind dafür aber deutlich schneller als der Celeron 847 und dazu sparsamer.

    USB hat Latenzen, die wieder stören, damit hat dippes ganz andere Probleme. Wer Quali möchte , meidet USB

    Interessant, bei einem hochwertigeren Gerät hätte ich einen ausreichenden internen Puffer erwartet. Mit etwas Zeitversatz könnte man ja leben.


    hier geht es generell um Linear Regler, wo sollten die denn ein Problem mit der Versorgungsspannung haben

    Nein, hier geht es die ganze Zeit um einen Audiodac (in dem typischer Weise ein Konstantstromregler verbaut ist), der laut Themenstarter ein Problem mit der Versorgungsspannung hat.

    Aber egal, da weiter zu diskutieren führt zu nichts.


    Denon oder Onkyo [...] und den dann über S/PDIF vom Hifiberry Digi+

    S/PDIF und das am besten optisch, auf ein gescheites HIFI-Gerät.

    Der Tip ist gut! Manchmal übersieht man einfach das naheliegenste.

    IMHO die beste Lösung, wenn nicht basteln will und es einfach funktionieren soll.

    Kannst du einen empfehlen?

    Wenn ich es richtig verstehe, braucht es beim RPI auch noch diesen Taktgenerator, damit es über I2S sauber läuft.


    Aber wäre eine gute USB-Sondkarte evtl. eine Möglichkeit? (sofern es die gibt, ich kenne mich da überhaupt nicht aus)

    Da hätte man das Taktproblem umgangen und man kauft was Erprobtes, was eigentlich keine Überraschungen bringen sollte.




    na klar, hier -->Expansion Board für Raspberry

    ist das genau so umgesetzt.

    Das ist aber definitiv nicht die genannte Preisklasse.

    Das nette Türmchen allein kommt auf 135$ und das Netzteil nochmal auf 85$, alles Aliexpress-Preise, also +Steuer. Dann noch der RPI und das Gehäuse.

    Wenn das Gerät dann fertig ist, liegt Ende liegt man da also eher bei knapp 300€.


    Mit einem käuflichen Webradio, dass man für ~100€ Bestpreis online bekommt, oder für etwas mehr im lokalen Elektrofachmarkt, hat das nicht mehr viel zu tun.



    Der 78xx war nur als Beispiel für einen simplen Analog-Regler gedacht. Es sollte illustrieren, dass diese sinusförmige Störungen niedriger Frequenz ganz gut ausgleichen können, während dies Sprunghaften Änderungen der Versorgungsspannung Probleme bereiten.

    auffällig ist, das du da zwei Timer (0+2) am laufen hast und einer (0) VPS benutzt.

    Timer 2 wird zugunsten von Timer 0 deaktiviert.

    Diese "Timer 0" kann man hier wohl ignorieren.

    EPGsearch löst die unbeabsichtig beim Vergleich aus.



    So wie ich es sehe ändert EPGsearch den Timer und der VDR deaktiviert ihn daraufhin.

    Dass EPGsearch den Timer auch während der Aufzeichnung aktualisiert, ist beabsichtigt. Bei aufzeichnenden Timern wird, wie in diesem Fall, aber nur die Endzeit geändert (23:10->23:15).


    Auf die Reaktion vom VDR kann ich mir momentan keinen Reim machen, eigentlich sollte das so nicht passieren.


    Man müsste mal probieren, was passiert, wenn man per Hand einen aufzeichnenden Timer über svdrp ändert.


    Mit höherem Loglevel bekäme man heraus, ob das, was EPGsearch an den VDR sendet in Ordnung ist:

    Sieh hier. Unter Debian wird das in /etc/vdr/plugins/plugin.epgsearch.conf eingestellt.

    Es ist in der Tat ein positiver Unterschied zu hören.Die Höhen sind viel sauberer.

    Erfreulich!

    Im Umkehrschluss bedeutet das auch, dass (wie von mir erwartet) noch einiges an Störungen vom RPI selber kommt.


    Du machst bei Deiner Simu-Schaltung auch einen entscheidenden Fehler. Du lässt die ganzen parasitären Komponenten untern Tisch fallen. Das funktioniert leider praktisch nicht so. Für die Spule (hier weniger) , aber für die Kondensatoren musst Du ins Sheet neben der Kapazität noch den ESR und auch die Induktivitäten einzeichnen. Dann berechnen, schon siehst Du ein anderes Bild

    Die ESR aus dem Datenblatt habe ich natürlich berücksichtigt.

    Ob das verwendete ELKO-Modell was taugt, kann man aber immer schwer abschätzen.


    2 x die Hälfte sollte auf jeden Fall besser sein als ein Ganzes. Zum einen ist der ESR besser, der ist zwar bei den kleineren Einzelkondensatoren etwas größer, durch die Parallelschaltung in Summe aber niedriger. Auch ist die Induktivität bei kleinen Kondensatoren niedriger

    Da hast du mich missverstanden. Ich meinte 2x1000µF statt der 2x2200µF. (also die ELKO-Kapazität quasi halbiert)

    Das war als Alternative gedacht, falls man die Grösseren nicht unterbringt.


    mein obiges Beispiel bei Pollin kostet nur 4€ , hat exzellente Werte und kommt ohne Löten und Platine basteln aus.

    Das mag sicher auch gehen, das bezweifele ich nicht. Allerdings steht dann wieder eine extra Kiste rum.

    Und so ganz ohne Basteln geht es auch nicht. Man braucht immer noch ein Kabel und auch das Platinchen muss auch irgendwie isoliert befestigt werden.


    Mein Filterchen würde ich selber übrigens ohne extra Platine aufbauen.

    Der Ausgangselko wird gelegt (also die Anschussbeinchen um 90° gebogen, so dass der ELKO parallel zur Platine liegt) und zusammen mit dem Keramik-Kondensator in den Löchern für das Analog-Netzteil verlötet.

    Die Eingangs Kondensatoren kommen genau so an die Stiftleiste, die zum PI geht. (Belegung sollte sich problemlos finden lassen.)

    Die Spule kann man entweder an die Pads von dem Widerstand löten, oder man nimmt die beiden "+" Leitungen der Elkos. Was sich halt besser löten lässt.

    Die vorgeschlagenen Lötstellen an der Platine sind alle von bedrahteten Bauteilen und sollten sich auch von wenig geübten löten lassen. Das einzige, wo man aufpassen muss ist die Polung vom Elko (sonst knallt's).


    bist du darauf stolz? Das wären doch gerade mal 14db Dämpfung

    Stolz? Nein, aber für den Zweck reicht es.


    Wichtiger als die Dämpfung ist, dass die sprunghaften Änderungen der Versorgungsspannung, die typisch für Computerschaltungen sind, nicht bis zum DAC durch kommen.


    Grün: Eingangsspannung Rechteck Umax 5V Umin 4,5V, das ist so ziemlich der Worstcase. In der Praxis wird es maximal eher bei der Hälfte liegen.

    Rot: Ausgangsspannung zum DAC. Man beachte neben der kleineren Amplitude auch den sehr langsamen Anstieg der Spannung!


    Die in den DACs typischer weise verbauten Konstantstomquellen können sprunghafte Änderungen in der Versorgungsspannung eher schlecht ausregeln.

    Es besteht sogar die Möglichkeit, dass kurz ins schwingen geraten, was auch hörbar sein kann.


    Mit einer Sinusförmigen Störung von etwa 100Hz kommen die Regler aber recht gut zurecht.

    Ein simpler 78xx Spannungsregler kommt da auf etwa 50dB (das Datenblatt hatte ich gerade zur Hand) und ein Regler in einem AudioIC sollte da eher besser sein.


    Auch die Lösung mit dem Trafo ist nur graue Theorie. Ich gebe dir zwar Recht, dass ein längsgeregeltes Netzteil eine saubere Lösung wäre. Was du mit der Low-cost Lösung Trafo/ Zweiwege-Gleichrichtung/ Siebelko aber eliminierst ist der zusätzliche Störnebel durch die Schaltfrequenz des PWM, nicht aber:


    [...]

    Jupp, genau auf die Punkte 1 & 2 hatte ich schon letztens mit dem "extra Kraftwerk" angespielt. ;)

    Btw.: Wir haben einige Betriebe um die Ecke, ich hab da Erfahrungen, was das angeht.


    Also am besten die Kirche im Dorf lassen - wenn du wirklich optimales Analogsignal möchtest solltest du sonst auch selbst an den Anti-Aliasing-Filtern des DAC bei deinem HiFi-Berry DAC(+) optimieren - oder gleich einen richtig guten und sauber arbeitenden/ gefilterten DAC über den SPI ansprechen...

    Das sehe ich genau so.

    Ich würde HiFi-Berry Platinchen in den Consumer-HIFI-Bereich einordnen. So im Bereich 100-150€ Webradio etwa.

    In der Preisklasse wird kein Hersteller ein extra Netzteil für den Audio-DAC einbauen.

    Zumal es bei der räumlichen Nähe zu den ganzen Digital-ICs, gegenüber einer sinnvoll aus der Versorgungsspannung erzeugten Hilfsspannung, nicht viel mehr an Audioqualität bringen wird.

    Obwohl ich bei mir so einen störenden Eintrag in die epg.data reingemischt habe, kann ich das Verhalten (zumindest mit 2.3.9) nicht reproduzieren.

    Der komische Event allein ist nicht das Problem, da muss noch irgendwas anders dazu kommen.

    Der Timer existiert ja eine ganze Weile trotz des Events und wird irgendwann plötzlich gelöscht.


    Meine Vermutung ist, dass das "echte"EPG kurz aussetzt oder Arte die EventIDs einmal täglich wechselt.

    Zur Analyse bräuchte ich eine mit -v3 erstellte epgsearch.log

    Mit oder ohne EPG?

    Ohne EPG habe ich die relevanten Teile hier schon gepostet.

    Mit EPG müsste ich noch machen, das schaffe ich aber wohl erst nächste Woche.


    timersdone.conf, epgsearchdone.data (die letzteren am besten vor und nach dem Löschen)

    In der timersdone.conf erscheint der Timer beim Erstellen und irgendwann verschwindet er daraus auch wieder.

    Ich kann aber leider nicht sagen wann, da die Timer zu den unmöglichsten Urzeiten gelöscht werden (typischer weise zwischen 5 und 6 Uhr Morgens).


    In der epgsearchdone.data tauchen sie nicht auf, da ich "Wiederholungen vermeiden" bei dem Testimer nicht verwende um das als Ursache auszuschliessen

    Die Konstanten sollten da sein wenn man als Board "Arduino Leonardo" wählt.

    Auch mit der Textsuche konnte ich die im gesamten Arduino-Verzeichnis nicht finden.

    Ich muss wohl mal updaten :gap.


    Wir würde das mit den Interrupts gehen?

    Mit dem Zähler, wie ich es gemacht hatte s.o..

    Der zählt genau diese Interrupts.


    Für den Test müsste man die Lib halt temporär mal patchen.

    Wobei es sinnvoller wäre die Zählervariable im dazugehörigen Header zu definieren, dann wären andere Programme mit der Lib weiterhin lauffähig.

    Nebenbei, ich habe hier auch ein Ausgangsfilter für ein 1000 Watt NT (50 V/20A) gebaut und im Einsatz.

    Das ist ein ganz anderes Kaliber als das Filterchen für den Audiodac hier. Nebenbei bemerkt, es handelt sich etwa um den Faktor 1000!

    Und klar, bei solchen Strömen ist es längst nicht so einfach, das hatte ich als Einschränkung schon geschrieben.


    Bei kleinen Strömen kann man, vom Wert her, grosse Spulen verwenden, was die Filterwirkung deutlich verbessert.

    Daher habe ich einfach die grösst mögliche Drossel gewählt, die von Wiederstand, Strombelastbarkeit und Bauform passt.

    Vorraussetzung dafür ist aber, dass die Schaltung einen einigermassen konstanten Stromverbrauch hat, wie das Analog-ICs typischer Weise der Fall ist.

    Für digitale Verbraucher, bei denen die Leistungsaufnahme stark variiert, ist das Vorgehen eher nicht so ideal, da er von der Reglung des Netzteils entkoppelt wird.


    Mein Vorschlag sieht wie folgt aus:


    Diesmal mit Keramik und Elektrolyt Kondensatoren an Eingang und Ausgang, um ganz sicher zu gehen.

    Und ein gescheiter Pufferkondensator auch auf der Digitalseite kann nicht schaden.



    1x L-11P 3,3M

    2x RAD FR 2.200/10

    2x KEM X5R0805 1,0U

    Alternativ, wenn man es lieber bedrahtet will:

    Z5U-5 1,0µ

    Zusammen kommen die Teile auf etwa 2€


    Die Simulierte Kennlinie:

    (Man könnte jetzt zwar über das ELKO-Modell streiten, aber so grob sollte es passen.)

    Die blaue Kurve ist der o.g. Filter. Man sieht, dass schon knapp oberhalb von 100Hz schon nicht mehr viel durch geht.

    Schuld daran sind die grossen Elkos. Die grüne Kurve ist zum Vergleich mit 2x 1000µF, was aber eigentlich auch reichen sollte.

    Sofern Platz ist würde ich aber einfach die 2200er drauf packen, die kosten nur 20¢ mehr und haben einen niedrigeren ESR.

    Die Keramikkondensatoren machen sich bei der Simulation erst oberhalb von ~1MHz geringfügig bemerkbar.

    Benötigt werden sie in der Praxis aber trotzdem, da man die nadelförmigen Impulse der schaltenden Transistoren mit den Elkos allein nicht weg bekommt.

    Bei der grossen Spule sollten die standardmässig an allen Digital-ICs verbauten 100nF aber auch locker reichen.



    Die rote Kurve ist zum Vergleich der Filter von Argus.

    Auch dieser Verlauf ist praktisch ausschliesslich von den Elkos abhängig.


    sicher kann man die Störungen weg filtern, aber da müssen alle mitspielen, sprich, es müssen die Bedingungen von Netzteilhersteller, Raspberry, USB Kabel Hersteller usw. bekannt sein. Doch, wie schon oben angedeutet, wird Dippes das ohne Messmittel oder ohne viel Gebastel und probieren nicht lösen können.

    Was bitte muss da noch mit spielen, wenn man alles oberhalb von 500Hz praktisch komplett weg filtert?


    Und um den Filter zu beurteilen braucht man in diesem Fall keine Messmittel. Wenn mit gut klingt und die Störungen verschwunden sind, ist er in Ordnung.

    Wenn man nicht zufrieden ist, muss man sich halt was anderes überlegen. Der mögliche Verlust von 2€ ist aber verschmerzbar, finde ich.

    Da die Bauteile schon mehr als grosszügig bemessen waren, kann man sich weiteres rum probieren nämlich eigentlich gleich sparen.

    Die Variablen "WAKEUPE" "SUSPE" gab es bei mir noch nicht. Oder hast du da was selber gebaut?



    Komischerweise auch: Grüne LED an wenn mit USB-Netzteil versorgt.

    Könnte mit den Pullup / Pulldown-Widerständen an den Datenleitungen zusammen hängen.

    Da gibt es so komische "Standards", wie die die mögliche Ladeleistung an Handys übermitteln. Google weiss da mehr.


    Beim Mainboard könnte es das Gleiche sein, oder der USB-Controller wird nicht abgeschaltet. Eventuell bringt der Blick ins BIOS da was.



    Ich weiss jetzt nicht, wo die Variablen "WAKEUPE" "SUSPE" her kommen.

    Die Interrupts, die der USB-Teil im AVR auslöst, werden AFAIK aber immer nach dem Empfang eines bestimmten Pakets vom USB-Host.

    Man sollte also eigentlich sicher sein, dass USB-Host aktiv ist. Da wäre es jetzt interessant zu wissen, ob es einen Unterschied macht, wenn man Interrupt auswertet.


    Leider habe ich momentan kein freies Board da, mit dem ich das probieren könnte.

    Das kann man auch gut per LED machen, einfach den Takt entsprechend teilen, dann sollte die LED blinken.



    Habe heute das Netzteil bekommen und erstmal ohne Trennung von Raspberry und Dac angeschlossen.Der Unterschied ist wirklich enorm.


    Der Sound ist räumlicher und die sharfen Höhen sind deutlich zurückgegangen.

    Das man was (bzw. weniger Störungen) hört, wundert mich nicht.


    Inzwischen verzichten die Hersteller bei den kleinen Schaltnetzteilen Ausgangsseits leider oft auf jegliche Filterung.

    Bei den Verkaufspreisen bleibt denen wohl aber nichts anderes übrig.


    Da ich zwei von den Rasp+Dac habe werde ich den anderen mit getrennten Netzteilen versorgen und auf den klanglichen Unterschied achten.

    Eigentlich erwarte ich da auch noch einen Unterschied.

    Auf dem RPI sind neben (mindestens) zwei Schaltreglern auch noch diverse andere Komponenten die Störungen verursachen.


    Wenn man noch weitere Versuche anstellen will, wäre auch der Vergleich zwischen extra Netzteil und einem passiven Filter interessant.

    Dann wüssten wir endlich eindeutig, ob ein eigenes Netzteil für den Analogteil nötig ist, oder ob der Hersteller da Problem für 2€ hätte lösen können.


    Ich habe den Rasp und den Dac in ein Stahlgehäuse verbaut.

    Wenn beides in einem geschlossenen Blechgehäuse verbaut ist, sollte man dafür sorgen, dass Bluetooth und WLAN deaktiviert sind.

    Die Funkmodule können, weil sie gepulst senden, auch Störungen im hörbaren Bereich verursachen und funktionieren tut beides durch ein Blechgehäuse eh nicht.