wav Dateien: Programieren von Wiedergabe und Aufnahme

[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.

[HaWe]

nein, da muss ich passen, ich verstehe von diesem low level Kram nichts

was wir brauchen ist eine Serie von Sounddaten für nur 1 Micro-Kanal, ohne Header und ohne Trennzeichen.

das muss in einen
int32_t wavbuffer[SHRT_MAX]
rein

Da alles bei 8bit nur 1 Datenbyte ist, passt alles ins lowbyte des wavbuffers, also (angenommen Mono==links)
( alle 4 Bytes einer jeden int32 Arrayzelle einzeln betrachtet) :

0 0 0 128, 0 0 0 129, 0 0 0 129, 0 0 0 128, 0 0 0 127, 0 0 0 132, 0 0 0 134, .... (Phantasiewerte)
(betrachtet in Big Endian Schreibweise)

usw. bis alle echten einzelnen Microwerte in diesem Array drin sind, ohne Steuerdaten.

Kriegst du das hin?