Himbeer-Pi-Null für verlustfreie Musik?

562
FatalSleep

Ich habe viele DIY-Projekte und Open-Source-Anwendungen für Hi-Res-Musikplayer gesehen, die auf dem Raspberry Pi basieren.

Aber ist der Himbeer-Pi Zero tatsächlich mächtig genug, um verlustfreie Musikwiedergabe zu ermöglichen?

HINWEIS: Ich streame nicht - wird wahrscheinlich Mopidy als Backend-Musikplayer verwenden und dann den Player mit einer MPD-App von meinem Telefon aus steuern.

0
Ja, es ist stark genug. Eric F vor 6 Jahren 1
@EricF Wenn ja, könnten Sie eine Antwort übermitteln, warum dies so ist? FatalSleep vor 6 Jahren 0

1 Antwort auf die Frage

2
Yorik

Was genau abgespielt werden kann, hängt von der Player-Software und der tatsächlichen Samplerate usw. des Audios ab. Als Referenz jedoch komprimiert FLAC verlustfrei PCM-Audio.

Redbook-Audio (CD-Standard) ist ein unkomprimiertes lineares 16-Bit-PCM bei etwa 44 kHz. Damals, als interne CD-Laufwerke neu waren, verfügten sie oft über Kopfhöreranschlüsse und Wiedergabesteuerelemente, und sie konnten problemlos CD-Audio abspielen, ohne an einen Computer angeschlossen zu sein (man könnte ein leeres Netzteil und die Stromversorgung über Molex ohne angeschlossenen Computer überbrücken).

Dies ist sicherlich eine sehr grobe Annäherung, aber wir sprechen hier von einer Technologieanweisung aus c. 1988. Sehr wenige Audiodaten müssen jenseits von 44 oder 48 kHz liegen, da der menschliche Hörbereich ungefähr 22 kHz umfasst. FLAC unterstützt bis zu 24 Bit, aber 24-Bit-Authoring wird nicht immer aus älteren Gründen durchgeführt (eingebettete Systeme unterstützen es manchmal nicht). Daher ist 16 Bit eine Art "Least Common Denominator".

Nach der Dekomprimierung ist FLAC PCM (möglicherweise linear oder LPCM), wahrscheinlich 16 bis 24 Bit und wahrscheinlich 44 bis 48 kHz. Sehr ähnlich zu Redbook Standard durch die Zahlen, wenn nicht die genaue Darstellung.

Die Hardwareleistung ist also nicht wirklich ein Problem für die Wiedergabe, sondern eher für die Dekomprimierung.

Ich sehe, dass der Rasberry Pi Zero einen etwas schnelleren Prozessor als der Raspberry Pi 3 hat, und Wikipedia sagt, dass das RP3 H.265 in Software unter Verwendung der CPU decodieren kann (es fehlt dedizierte H.265-Decodierungshardware). Ich vermute also, dass die CPU die Aufgabe hat, die 2-Kanal-Audio-Dekomprimierung durchzuführen.

Um dies in die richtige Perspektive zu bringen: Die H.265-Videodekomprimierung erfordert erheblich mehr CPU-Leistung als das komplizierteste Audiokomprimierungsschema, das man sich vorstellen kann. dirkt vor 5 Jahren 0