WaveInReset() und Unterschiede zwischen Soundkarten
-
hi!
Mein Programm nimmt mit 2 Buffern wavedaten auf. Jedesmal wenn die MM_WIM_DATA Nachricht ankommt wird der volle Buffer weggeschrieben und gleich wieder leer mit WaveInAddBuffer angehängt. Soweit funktioniert das alles.
Wenn jetzt aber jemand mittendrin stop drückt passiert folgendes:
Die Stopnachricht ruft eine funktion auf die WaveInReset() ausführt (das wavedevice ist noch offen). Damit sollte ja (nach MSDN) der gerade beschriebene Buffer mit MM_WIM_DATA zurückgegeben werden um dann die reste in dem buffer auch noch zu speichern.
Auf einem Rechner (PIII 500, Win 2000 Prof., Creative AudioPCI ES1371/ES1373) passiert das auch genauso. Auf einem anderem Rechner (Gericom Laptop PIII 1000, Win2000 Prof, SiS 7018) kommt der Buffer zwar an, ist aber leer.Kann einer den Unterschied erklären?
Die wichtigen Teile habe ich hier mal reinkopiert:
LRESULT CALLBACK FCallback(HWND WinH, UINT message, WPARAM wParam, LPARAM lParam) { switch(message) { ... case WM_SD_AUDIO_STOP: { Programmstatus = SD_AUDIO_AUFNAHMESTOP; Aufnahme->AufnahmeStoppen(); return(0); ... case MM_WIM_DATA: { switch(Programmstatus) { ... case SD_AUDIO_AUFNAHMESTOP: { Aufnahme->AufnahmeSpeichern((WAVEHDR*)lParam) } break; ... default: break; } return(0); } ... }void AufnahmeKlasse::AufnahmeStoppen() { waveInReset(WaveHandle); }
-
Ich habs jetzt nochmal auf diversen anderen Rechnern ausprobiert und es scheint überall zu laufen.... Nur auf dem Laptop eben nicht.
halt gericom
-
Versuchs mal mit mehr als 2 Puffern. Zwischen einer separaten Soundkarte und Soundchip-On-Board gibt es große Unterschiede bei der (Hardware-)Zwischenspeicherung der Soundpuffer. Soundchip-On-Board-Lösungen arbeiten in der Regel mit nur 2 Hardwarepuffern (abhängig von der Größe). Es kann also sein, daß der letzte Puffer noch nicht vom Audio-Chip benutzt worden ist, da die Zeitverzögerung zwischen Aufruf und Ausführung für WaveInAddBuffer, WaveInReset usw. bei Soundchip-On-Board-Konfigurationen nur ca. 1/10 der Soundkarten-Konfigurationen beträgt.
Blackbird
-
da ist aber wer früh auf
Wenn die Verzögerung zu gross ist und der Buffer noch garnicht bei der soundkarte angekommen kann er auch nicht beschrieben werden. Aber die ganze Aufnahmereihe funktioniert ja vorher perfekt... nur beim letzen BUffer eben nicht. Er wechselt die Buffer vorher ja einige duzendmal ohne Probleme.
Der Buffer ist 5 sekunden lang... Da sollte genug Zeit sein den Buffer an die Soundkarte zu übergeben. Und auch wenn ich erst kurz vor dem abschliessen des Buffers abbreche ist er auch leer.Kann das trotzdem an der Verzögerung liegen?
-
da ist aber wer früh auf
"früh" ist relativ
Woran es geneu liegt, kann ich dir auch nicht sagen. Da hilft nur messen, prüfen, testen ...
Die Hardware und die Treiber-Software ist aber bei On-Board-Chip- und Soundkarten-Konfigurationen verschieden.
5 s sind auch zienmich große Buffer, meine waren immer so im Millisekundenbereich. Wie hoch ist denn die Verzögerung zwischen einem Pegelsprung am Mikro (LineIn) und dem Eintreffen des Buffers in WIM_DATA? Und wann tritt der Pegelsprung im Buffer auf?
Immer jeweils beim Gericom und bei den Soundkarten gemessen.Blackbird
-
Ich habs mittlerweile ziemlich vielen verschiedenen Soundkarten getestet. Irgendwie haben (grob verallgemeinert) alle onboard chips dieses verhalten.
Ich hab mir einfach damit geholfen nicht 2*5s sondern 10 * 0,1s buffer zu nehmen. Da läuft die aufnahme sicherer und diese ganzen waveInReset Probleme sind dahin. Eine zehntelsekunde als maximaler datenverlust ist ok.
-
Keine Ahnung, aber evtl. sind den Onboard-Sound-Chips einfach die Buffer zu groß gewesen
