Hallo Leute, ich habe in der Vergangenheit immer mal wieder Projekte auf Audio-DSPs gemacht, kenne mich daher mit digital-audio, I²S, APLL's etc. ganz gut aus. Jetzt habe ich mir mal einen Raspberry geholt, um mal ein bisschen Audio auf embedded Linux Plattformen zu studieren. Ich wollte mal fragen, ob mir jemand auf die schnelle mal "grob" erklären kann, was da drinnen abgeht. Leider findet man beim Raspberry nur high-level Tutorials. Der Kopfhörerausgang beim RPI ist ja PWM basiert (nutzt die interne generische PWM Generierung). Es scheint auch keine richtige Audio-PLL zu geben. Der PWM Takt ist über einen fraktionalen Divider von der System-Clock abgeleitet. Außerdem scheint laut einigen Infos der Audio-Treiber einen Noiseshaper zu beinhalten. Ich habe mal Musik über den Kopfhörer-Ausgang abgespielt und man hört definitiv, dass der Sound "nicht ganz sauber" ist und leichte Verzerrungen hat wenn man genau hinhört. Für mich klingt das ein bisschen nach einem "linearen interpolierenden Resampler" ;) Wenn ich z.B. einen Webradio-Stream im VLC abspiele, wie genau wird da der "asynchrone Clock-Übergang" zwischen Audio-Clock vom Stream vs. RPI Kopfhörer PWM Hardware gemacht. Mit Sicherheit ist da ein resampler im Spiel. Wo kann man die Source-files einsehen, wo das Audio per DMA wirklich durch einen Noise-Shaper und in die PWM Hardware geht? Danke für die Infos.
Der Sound auf dem Raspi klingt nicht gut. Lohnt sich nicht, was zu verbessern. 2 Möglichkeiten, wenn man Musik hören möchte: - der Sound liegt digital auf dem Video-Signal. Manche Monitoren können dann den mit klingen lassen. - für 10 Euro gibt es USB-Soundadapter. Ich habe mir so ein USB-Teil gekauft.
Ich verwende am Raspi den HifiBerry DAC, weil das Audio-Signal direkt aus dem Raspi nur mäßig ist. Gruß Tom
Switch schrieb: > Wo kann man die Source-files einsehen Den Source zum RPi Linux kannst du doch im Netz finden. Ist doch alles offen zugänglich.
900ss D. schrieb: > Den Source zum RPi Linux kannst du doch im Netz finden. > Ist doch alles offen zugänglich. Fremden Code zu elsen und daraus Infos zur Hardware abzuleiten ist ja auch sooooo einfach. Im Vergleich dazu ist eine kurze Frage zu stellen die reinste Zeitverschwendung. Hast du dir das so gedacht? Anfänger!
Stefan ⛄ F. schrieb: > Anfänger! ??? Die Frage war: Switch schrieb: > Wo kann man die Source-files einsehen, wo das Audio per DMA wirklich > durch einen Noise-Shaper und in die PWM Hardware geht? Das hab ich beantwortet. Von "einfach" war nirgends die Rede. Läufst nicht rund heute?
900ss D. schrieb: > Die Frage war ... Das hab ich beantwortet Ja hast du. > Läufst nicht rund heute? Sorry, ich habe den Sachverhalt missverstanden.
1. Kernel.org 2. Audio läuft über ALSA 3. ALSA würde ich dann aus C/C++ anquatschen - es gibt da nen callback den man registrieren kann und dann wird der von ALSA regelmäßig aufgerufen
Die Frage hatte ich mir auch mal gestellt: Die 48kHz von Internet-Radio stream sind ja nicht phasenstarr mit den lokalen 48kHz des DACs gekoppelt. Wenn man naiv also samples aus dem Stream in den Audio-FIFO füllt, der mit 48kHz ausgelesen wird, platzt der früher oder später. Eine Variante wäre natürlich asynchrone sample rate conversion, aber so wird das scheinbar nicht gemacht. Auf der Suche nach einer Antwort hab ich im IRC-Channel von xiph.org gefragt. Dort hat man mir gesagt, dass man das effektiv wie packet loss behandeln und die eh schon vorhandenen Mechanismen zu dessen Kaschierung verwenden kann. Im einfachsten fall also wohl samples verdoppeln/weglassen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.