wav Dateien: Programieren von Wiedergabe und Aufnahme

[HaWe]

ok, jetzt muss ich mir ein Bild von den wav-audio-Daten machen.
in welchem array stehen jetzt die wav-Roh-Daten, die du vom Micro aufgenommen hast, und die jetzt weiterverarbeitet werden sollen?

ist es

in32_t input[SHRT_MAX]

und enthält er noch beide Spuren (li+re) ?

[hirnfrei]

Richtig.

input32_t input[SHRT_MAX];

ist das was vom Mikro kommt. Direkt in diese Variable. Also da wird nicht erst noch was konvertiert oder so.

Und zu besseren Verständnis, wie die audioCapture() funktioniert hier ne kleine Erklärung:

audioCapture(input, SHRT_MAX, "plughw:1,0", 1, 12000, 8);

audoCapture("Variable zum Speichern der Daten", "Aufzeichnungslänge", "Soundkarte", "Kanäle", "Frequenz", "Bit");

Ich jammere rum weil tinyalsa keine gute Dokumentation hat und biete dann für meine Funktion ebenfalls keine Erklärung. Tztztztz.

Wie du siehst, ich nehme nur mit einem Kanal auf.

Okay, habe versucht eine CSV hoch zu laden, hat natürlich nicht geklappt . Versuch es mal hier http://www.kipperei.de/test.csv

[HaWe]

ok, hab ich mir angeschaut.
Es sind jetzt alles Zahlen in Byte-Größe.

Betrachten wir jetzt mal diesen Array input, N == SHRTR_MAX Zellen mit jeweils 4 Bytes:

|----,----,----,----,----,----,----,----,----,----,---- .... ----,----,----,----,----,----,----,----,----,----,----|
  0     1    2    3    4    5    6    7    8    9   10  ....                                                   N=SHRT-MAX-1

wie ist jetzt jede 4er-Bytes-Gruppe aufgebaut?

[hirnfrei]

Wie meinst du das?

Normalerweise 3 Zeichen und ein Terminationszeichen.

[HaWe]

was für zeichen an welcher Array-Stelle?
Wir brauchen lowByte und HighByte des Ton-Peaks, oder etwas, was wir dazu umwandeln können

oder hast du in 8 bit gesampelt?

dann brauchen wir die byte-Nr-Stelle, wo dieses 8bit-Tonsignal steht.
Immer im LowByte des int32-Zellenwertes?

[hirnfrei]

Siehe meine Erklärung. Ja ich habe in 8-Bit gesampelt.

dann brauchen wir die byte-Nr-Stelle, wo dieses 8bit-Tonsignal steht.
Immer im LowByte des int32-Zellenwertes?

Was das angeht, da stehe ich gerade wie ein Esel und warte auf Heu

[HaWe]

du meintest doch:
3 Zeichen und ein Trennzeichen.

ich verstehe das als
3 Bytes und 1 Trennzeichen, immer bezogen auf jede int32-Array-Zelle.

Meintest du das so?

dann enthält ja nur 1 Byte wirklich den Tonpeak, der Rest ist für uns nicht zu gebrauchen.

in welcher Reihenfolge steht jetzt also was drin:

1.Byte=
2.Byte=
3.Byte=
4.Byte=Trennzeichen

oder beziehen sich deine "3 Zeichen" auf was anderes?

[hirnfrei]

Es mag sein das ich mich irre, aber ich denke zum Beispeil der Mittelwert wäre

Byte 0 = 1
Byte 1 = 2
Byte 2 = 8
Byte 3 = \n

[HaWe]

wie ? die Dezimalstellen in einzelne Bytes gepackt?
Das kann ich nicht gauben.
Zahlen von 0-255 passen doch in 1 Byte, da müssen doch keine ASCII Ziffern mit #10 oder #13 als Trennzeichen einzeln abgespeichert weden...?


das fällt mir schwer zu glauben.

ich würde eher so etwas erwarten (es sind ja unsigned char (0...255) , und die Null ist ja als ein echter Messwert möglich:

Byte 0 = linker Kanal 0...254
Byte 1 = rechter Kanal 0...254
Byte 2 = ??? was könnte das sein ???
Byte 3 = 255 als Trennzeichen

aber das muss man jetzt wirklich 100%ig wissen, bevor man weitermacht.

[hirnfrei]

Ich habe stark den Verdacht, bei uns hat sich ein Kommunikationsproblem eingeschlichen.

Die Datei wo ich dir geschickt habe enthält exakt das was ich vom Mikro bekomme. Entsprechend kann ich es auch genau auf diese Art auch wieder aus gebe. Was da jetzt wie wo wann welcher Kanal ist kann ich dir so gar nicht sagen

- - - Aktualisiert - - -

Die Alsa Funktion sieht so aus:

snd_pcm_sframes_t snd_pcm_readi 	( 	snd_pcm_t *  	pcm,
		void *  	buffer,
		snd_pcm_uframes_t  	size 
	) 		

Read interleaved frames from a PCM.

Parameters:
    pcm	PCM handle
    buffer	frames containing buffer
    size	frames to be read

Returns:
    a positive number of frames actually read otherwise a negative error code 

Return values:
    -EBADFD	PCM is not in the right state (SND_PCM_STATE_PREPARED or SND_PCM_STATE_RUNNING)
    -EPIPE	an overrun occurred
    -ESTRPIPE	a suspend event occurred (stream is suspended and waiting for an application recovery)

If the blocking behaviour was selected and it is running, then routine waits until all requested frames are filled. The returned number of frames can be less only if a signal or underrun occurred.

If the non-blocking behaviour is selected, then routine doesn't wait at all.

Vielleicht sagt dir das mehr.