Zu Fuß von der Soundkarte sampeln

[zeckensack]

Ich könnte mir vorstellen dass man da prinzipiell so anfängt:

cp /dev/irgendwas_mit_snd datei

Bzw geht's eigentlich erstmal um's Lesen, und das ginge ja dann fast noch einfacher, weil man innerhalb des lesenden Codes selbst sagen kann: nach 1000000 Samples höre ich mal auf. Der User muss nicht mit CTRL+C abbrechen wenn's reicht, oder so.

Wie heißt das Gerät (das primäre/vom User bevorzugte, falls mehrere Soundkarten da sind)? Gibt es unterschiedliche Gerätenamen zu berücksichtigen, für ALSA vs Open Sound System vs was es sonst noch geben mag?

Funzt das überhaupt so? Ist das Soundsystem von vornherein aufnahmebereit (in irgendeinem Default-Format, aber das wäre erstmal egal)? Oder muss man dem Soundsystem erst eine Anfrage senden um überhaupt Samples empfangen zu können?

[klutob]

IMHO geht das nicht so einfach über die "Low-Level Alsa-API", da man den PCM-Kanal nicht gleichzeitig für Wiedergabe und Aufzeichnung einspannen kann.

Hier ist ein Programmsample für eine Alsa-capture-Anwendung (http://equalarea.com/paul/alsa-audio.html#captureex), die Seite sollte noch weitere nützliche Links für dich bieten (als Profi-Coder).

Mit OSS würde ich mich heutzutage nicht mehr befassen, da 1. Alsatreiber für fast jede HW vorhanden sind und 2. Alsa eh eine OSS-Emulation anbietet (falls deine Anwendung schon auf OSS zugeschnitten ist).

Wenn du es komfortabel magst, dann schaue dir mal den extrem mächtigen "jack-Soundserver" an, bzw. "jackrecord". Eine Aufnahme sieht dann ungefähr so aus:

jackrec -f filename [ -d second ] [ -b bitdepth ] [ -B bufsize ] port1 [ port2 ... ]

[zeckensack]

Hmmm ... interessant, interessant. Danke.

Wie einige vielleicht schon länger ahnen schreibe ich an einem Audio-Codec. Und ich überlege mir schon eine ganze Weile was ich alles machen muss damit Echtzeit-Encoding direkt vom A/D-Wandler der Soundkarte runter funktioniert, und habe mehr oder weniger penibel darauf geachtet da keinen Scheiß zu machen; wie auf der "Datei" seek-Operationen durchzuführen und versuchen die "Dateigröße" zu ermitteln zB, was alles keinen Sinn ergäbe wenn es sich bei der Datei in Wahrheit um ein Capture-Device handelt.

Also wenn der User sich nicht mit Dateien befasst, etwa so:
xxx -c lärm.aif -o lärm.xxx
... sondern ein Device angibt:
xxx -c /dev/snd0/rec0 -o lärm.xxx

Ich wollte jetzt quasi nur noch den Deckel drauf machen und die passenden Worte zum Echtzeit-Encoding in der Dokumentation anbringen. Aber wenn das alles gar nicht geht, kann ich mir das auch an die Backe schmieren.

*schulterzuck*

[Coda]

Wieso verwendest du nicht gleich OpenAL, dann läufts auch unter Windows?

[zeckensack]

Wieso verwendest du nicht gleich OpenAL, dann läufts auch unter Windows?Das Programm arbeitet mit Dateien. Es muss gar nicht aufnehmen können.

Unter einem ~Unix, dank fließender Übergänge zwischen Geräten und Dateien, hätte man dann die Möglichkeit gehabt, das Programm dahingehend zu verarschen. Auf Windows geht sowas natürlich nie, deswegen ist Windows auch so behindert (und so ein lukrativer Markt für "Tools" für allen möglichen Kleinscheiß, aber ich schweife ab).

Das wäre nett gewesen. Aber nur weil's das nicht gibt binde ich mir garantiert nicht OpenAL an die Backe.
Btw habe ich erhebliche Zweifel ob man mit OpenAL-Unterstützung Linux-Usern einen Gefallen tut, oder ob das nicht im Grunde nur Creative auf Windows stärkt.

[Coda]

Ok in dem Fall würde ich das natürlich auch lassen...