On-the-Fly-Digitalisierung von Audio von der analogen Audiobuchse

Wenn ich richtig liege, glaube ich, dass alle normalen Audiobuchsen (wie die, die Sie zu Ihrem PC haben und zu Ihren Lautsprechern reisen) analog sind.

Gibt es eine Möglichkeit (vielleicht mit einem Hochgeschwindigkeits-ADC), es im Handumdrehen in digital umzuwandeln? Ich erwäge (vielleicht) ein Projekt mit Arduino, bei dem Sie Audio in digitaler Form erfassen und auf einer SD-Karte speichern.

Dann ist dies natürlich nur eine Folge von Bits. Muss mein Projekt also an der großen Datenmenge scheitern? Oder macht die Information vielleicht gar keinen Sinn, weil sie mit keinem Audioformat äquivalent ist? Oder wird es im Wesentlichen eine WAV-Datei (ohne Header) sein?

Gibt es schließlich so etwas wie einen analog zu digital codierten (MP3 oder was auch immer) Hardware-Encoder?

Audio ist keine so schnelle Anwendung.
Warum ist diese Frage mit "Arduino" gekennzeichnet?
Vorhandenes Projekt dazu mit ein paar Sekunden Googeln gefunden: adafruit.com/blog/2009/07/07/…
.. und MP3-Encoder-IC: vlsi.fi/fi/products/vs1063.html
@VladimirCravero - weil das Poster erwähnt, dass sie erwägen, ein Arduino als Plattform zu verwenden, und das ist eine wichtige Sache zu erwähnen, weil es uns darauf hinweisen lässt, dass ein (Standard-ATmega-basiertes) Arduino eine schlechte Wahl für diese Anwendung ist - sein Onboard-ADC ist nur in der Lage, Audio in niedriger Qualität zu liefern, hat begrenzten RAM zum Puffern und wird ziemlich beschäftigt sein, Daten von einem externen ADC zu warten.

Antworten (1)

Audio hat keine so hohe Bandbreite und liegt daher im Bereich dessen, was ein Mikrocontroller verarbeiten kann.

Die gewünschte Qualitätsstufe macht einen großen Unterschied in der Datenmenge, die Sie verarbeiten müssen. Wenn Sie nur Sprache speichern und später wiedergeben müssen, sind 8-Bit-Samples bei 8 kHz gut genug. Wenn die 8-Bit-Werte nicht auf Linearität beschränkt sind, können Sie mit der gleichen Datenmenge ein besseres Signal-Rausch-Verhältnis erzielen. Das macht die Telefongesellschaft.

Am anderen Ende befindet sich "Hi-Fi"-Audio, das von 20 Hz bis 20 kHz reicht, normalerweise mindestens 16 Bit pro Abtastung (über 90 dB Signal-Rausch-Verhältnis). Um solche Audiodaten zu digitalisieren, sampeln Sie viel schneller als die Nyquist-Grenze, wenden dann eine digitale Filterung und dann eine Dessimierung an. Der Grund, warum Sie eine digitale Filterung benötigen, ist, dass die analoge Filterung nicht so genau sein kann, um den sehr scharfen Abfall nach 20 kHz zu haben, den Sie benötigen, um nur etwas schneller als 40 kHz abzutasten.

Nehmen wir an, Sie machen den schlimmsten Fall und erhalten am Ende 16-Bit-Samples bei einer Rate von 44 kHz. Das sind nur 88 kB/s oder 5,3 MB/Minute. Jede SD-Karte kann diese Datenrate verarbeiten. 1 GB bietet Ihnen über 3 Stunden dieses Hi-Fi-Audios.

Wenn Sie nur Audio in Sprachqualität wünschen, sind die Dinge natürlich viel einfacher, die Datenraten niedriger und die Speicheranforderungen geringer. Bei 8 kB/s reicht gerade mal 1 MB für über 2 Minuten. 1 GB würde fast 1 1/2 Tage Audio aufnehmen.

Eine SD-Karte kann die Datenrate im Durchschnitt bewältigen; Ich bin mir jedoch nicht sicher, ob dies reibungslos und ohne Verzögerungen möglich ist, und da ein Standard-Arduino nur 2 KB RAM hat, reagiert es sehr empfindlich auf Schreibverzögerungen. Mag sein, dass es in der Praxis funktioniert.
@Chris: Meine Antwort bezog sich auf die allgemeine Theorie und den Hintergrund zu digitalisiertem Audio. Der Versuch, dies mit einem Arduino zu tun, ist wahrscheinlich unangemessen, aber das OP sollte in der Lage sein, dies selbst zu sagen, sobald er entscheidet, welche Art von Audio er möchte, und dann die Bandbreitenanforderungen aus meiner Antwort erhält. Für hohe Datenraten benötigen Sie etwas, das einen ganzen Schreibblock puffern kann, wie groß dieser auch sein mag. Ein kleines Mikro sollte in der Lage sein, die geringe Datenrate von Sprachaudio zu bewältigen. Auch hier müssen wir wissen, welche Art von Audio das OP im Sinn hat.
Ja, Sie haben einen Großteil des Problems gut abgedeckt. Was ich hinzugefügt habe, war die spezifische Unterscheidung zwischen durchschnittlicher Datenrate und momentaner Rate und der daraus resultierenden Pufferanforderung. Es ist einer dieser Fallstricke, die neuere Designer wie das Poster leicht übersehen können.