Sinuston ausgeben und über Mikro Amplitude messen – machbar?

apple-itob

Mitglied
Guten Abend Forum,

aus anderen Foren, bei denen ich auf der anderen Seite sitze, weiß ich, dass es nervig ist, wenn jemand einfach nur fragt wie etwas geht und keine Eigeninitiative zeigt, deswegen sei gleich vorweg gesagt, dass ich keine (fertigen) Code erwarte. Mir geht es eher um eine Art Machbarkeitsstudie …

Nun zum Thema, im Rahmen meiner Bachelorarbeit habe ich – vielleicht etwas naiv und überambitioniert – vor ein Programm zur Visualisierung von Schallwellen zu schreiben, nun habe ich mich in Java eingearbeitet, aber es scheint nicht so einfach, wie ich zunächst dachte. Das Programm soll dazu in der Lage sein, über den PC-Lautsprecher einen Sinuston zu senden und diesen mit dem PC-Mikro zu „empfangen“ und die gesendete mit der empfangenen Amplitude vergleichen (Stichworte Laufzeitunterschied/Phasenverschiebung). Aus dieser Differenz soll dann eine Darstellung berechnet werden. Ich habe bereits rausfinden können, dass es möglich ist, einen Frequenzgenerator zu programmieren, was ich bisher nicht weiß ist, ob dieser Amplitudenvergleich möglich ist. Nun ist meine Frage an euch, ob ihr das für umsetzbar haltet oder ob Java dazu einfach keine Lösungen parat hat. Wenn ihr sagt, dass das möglich ist, würde ich mich über Tips natürlich freuen, aber den tatsächlichen Code will ich – ggf. wieder mit eurer Unterstützung 🙂 – selbst entwickeln. Das muss ich auch schließlich ist es meine BA, in der ich versichere, dass ich das selbständig erarbeitet habe.

Das das ganze in Richtung Messwerterfassung/MSR mit Java geht, habe ich natürlich auch schon in dieser Richtung recherchiert (und zwei Bücher sind auf dem Weg zu mir) aber die Ergebnisse sind eher dürftig. Falls die oben beschriebene softwarelastige Lösung, bei der der Anwender nur einen normalen Lautsprecher und ein Mikro braucht, wäre auch eine Lösung über ein „USB-Gerät“ zur Datenerfassung, das sich mit Java ansteuern lässt, denkbar. Auch dazu sind Hinweise herzlich willkommen.

Ich danke herzlich für eure Ideen und hoffe, dass ich hier an der Richtigen Adresse für derartige Fragen bin! Wenn ihr noch mehr Infos braucht oder ich mich unklar ausgedrückt habe, bitte einfach fragen ;-)

Gute Nacht
apple-itob

Nachtrag: Ganz vergessen, ich arbeite unter OS X und im Moment versuche ich NetBeans zu verstehen. Es wäre toll, wenn das Programm das am Ende rauskommen soll plattformunabhängig ist, also die Tonerzeugung und Messwerterfassung auf möglichst vielen OS (zumindest Mac und Win) klappt.
 
Zuletzt bearbeitet:
Ganz grob würde ich jetzt erstmal behaupten das sowas mit Java locker möglich ist, denn Java stellt bereits in der SE-API für sowas einiges bereit. Allerdings ist das ganze ETWAS komplizierter als du denkst.

Alles was über eine Soundkarte als analoges Audio-Signal zu den Lautsprechern geht (und so natürlich auch umgekehrt) wird von einem Hardwarechip, dem sog. A/D- bzw D/A-Konverter von digitalen Byte-Folgen in analoge Frequenzen mit entsprechender Amplitude bzw. umgekehrt umgesetzt. Daraus folgt : sowohl Frequenz als auch Amplitude (also Lautstärke) sowie Phasenlage müssen bereits in digitaler Form vorliegen (als Byte-Array/-Stream) und bekannt sein. Genau so umgekehrt : man muss wissen wie man die umgewandelten Binär-Daten interpretieren muss um eben Frequenz, Amplitude und Phase zu ermitteln. Das hängt natürlich zum Teil von der verwendeten Hardware aber auch vom sog. Codec ab. Der Codec bestimmt nämlich wie analogen Daten in digitale (bzw umgekehrt) umgewandelt werden. Java ist hier von Haus aus nur sehr mager bestückt : es lassen sich einige WAV-Formate verarbeiten. Das wars dann aber auch schon im großen und ganzen. (Zusätzlich glaube ich noch AU und SND sowie MIDI.)
Also müsstest du dich erstmal mit dem entsprechenden Codec, dessen Implementierung in Java und der verwendeten Hardware befassen um zu wissen wie halt ein Ton von 440Hz mit einer Amplitude von 10dB und einer relativen Phasenlage von 0 mit einer dauer von 1sec in Byte-Form aussieht.

Wenn du soweit bist ist alles was du brauchst eigentlich nur noch eine Lib die dir entsprechend des Codecs die Binär-Daten in eine bestimmte visuelle Darstellung umrechnet. Dafür sollte es bestimmt schon was fertiges geben.


Ich wünsch dir viel Erfolg und wäre persönlich mal so auf die Ergebnisse gespannt da sich das Thema recht interessant anhört. (Ich würde mir dann auch mal deine Arbeit reinziehen falls das i-wie möglich ist. xD)
 
Guten Morgen,

danke für die Antwort! Das es nicht einfach wird, habe ich mir schon gedacht und die Sache mit der DA-Wandlung war mir klar, aber ich dachte, da gäbe es was, was das für mich im Hintergrund machen kann. Hättest du vielleicht noch ein paar konkretere Anlaufstellen, an denen ich suchen/lesen kann, ehe ich (mehr oder minder blind) losgoogle?
Ich bin auch nicht sicher, ob das deutlich geworden ist, aber es reicht mir nicht, wenn ich die (maximale) Amplitude des Tons kenne, ich muss auch den aktuellen Ausschlag der kurve kennen, um die Differenzen zu berechnen. Letztlich muss ich also wissen welche Spannung zu einem bestimmten Zeitpunkt gerade am Lautsprecher liegt (wie weit ist er ausgelenkt) und welche Spannung das im Mikro verursacht (wie doll wird es angeregt). Ich fürchte, das ist in meinem Ausgangspost nicht ganz deutlich geworden …
 
Zuletzt bearbeitet:
Ich habe keine Ahnung, was du mit "Darstellung" meinst, also was am Ende rauskommen/sichtbar sein soll. Das solltest du vielleicht noch etwas ausführen. (Und sei es nur drum, dass es dir selbst klar wird, du musst es ja nicht unbedingt hier posten.)

Ansonsten, wenn ich dich richtig verstanden habe, geht es grob darum: Ton erzeugen, Ausgabe auf Lautsprecher, Eingabe dieser Ausgabe über Mikrofon, und dann irgendetwas "darstellen", was man beim Vergleichen von Ein- und Ausgabe so rausbekommen könnte.

Wenn das also stimmt, würde ich dir raten, dich erst einmal grundlegend mit Signalverarbeitung zu beschäftigen, insbesondere mit DFT (diskrete Fouriertransformation). Was Geschwindigkeit und/oder Latenzen angeht, könnte es vielleicht sinnvoller sein, etwas anderes als Java zu verwenden, zumal eine der wichtigsten Bibliotheken, die du da gebrauchen könntest, in C geschrieben ist (nämlich fftw). Es gibt aber auch andere Ansätze, die ich in irgendeinem wissenschaftlichen Artikel bei der IEEE gefunden habe ("sliding DFT", oder so ähnlich), eventuell könnte der auch nützlich werden. (Ich will dir jetzt aber nicht deine ganze Arbeit abnehmen. 😀)

Worauf modularity hinauswollte, ist mir leider gar nicht verständlich geworden:
Daraus folgt : sowohl Frequenz als auch Amplitude (also Lautstärke) sowie Phasenlage müssen bereits in digitaler Form vorliegen (als Byte-Array/-Stream)
Ich meine jedenfalls, dass D/A- bzw. A/D-Wandler im Zeitbereich arbeiten (und nicht im Frequenzbereich), und warum man sich groß mit Codecs herumschlagen sollte, ist mir auch schleierhaft. Ich meine, PCM wird ja wohl reichen, oder?

@apple-itob: Ich würde mir da eher Gedanken darum machen, worauf das ganze Vorhaben abzielen soll. Ich meine, ein handelsüblicher Lautsprecher ist wohl eher schlecht als recht, und auch so ein Mikrofon wird wohl alles andere als geeicht sein. Aber gut, wenn das gerade Gegenstand der Arbeit sein soll, ist es ja auch okay. Wollt's halt nur mal gesagt haben …

Ark
 
Nabend,

ob das ganze mit handelsüblichen Lautsprechern und Mikros zu machen ist ist ein Stück wit schon Teil der Arbeit, denn das ganze Programm soll – wenn’s denn dann mal läuft – für jeden am Heimrechner (oder im Physikunterricht) benutzbar sein, ohne teure Messgeräte bzw. Hardware im weiteren Sinne besitzen zu müssen.

Zur Darstellung: Ich weiß natürlich schon wie es Dargestellt werden soll, wollte aber nicht zu viel verraten. Sei’s drum, so toll ist das Projekt jetzt nicht, das ich Angst haben müsste, es schnappt mir jemand weg … Die gemessenen Daten sollen in einem Raster dargestellt werden, wobei die Position im Raster, sprich Koordinate, über die Maus oder ein Tablett erfasst werden soll. Als benutzer schiebe ich dann Maus oder was auch immer samt Mikro(kapsel) vor dem Lautsprecher hin und her und rastere die Fläche ab. Dabei wir für jedes Feld im Raster von der Software der aktuelle Ausschlag am Audioausgang mit dem am -eingang verglichen (Differenz) und daraus die Färbung des Rasterpunktes bestimmt. Am Ende ergibt sich dann – theoretisch – ein Muster aus dunklen und hellen Punkten, das die Ausbreitung einer Welle zeigt. Ich habe den Versuchsaufbau bereits analog aufgebaut gesehen, d.h. ohne COmputer sondern mit einer kleinen Schaltung die die Helligkeit eines Lämpchens verändert und das ganze wird dann mit Langzeitbelichtung Punkt für Punkt fotografiert. Dieser Aufbau führt durchaus zu brauchbaren Bildern. Und nun gilt es diesen Aufbau zu „digitalisieren“ …

Da ich mich ja eigentlich garnicht für die konkrete Form der Welle interessiere (zumindest nicht solange ich berechne, wie ein Rasterpunkt gefärbt werden soll) sondern nur für die zwei aktuellen Amplituden ist es die Frage, ob ich wirklich die ganze Welle mit Fourier betrachten muss. Vielleicht gehe ich da auch zu naiv ran, aber (aus meiner etwas analogen Sicht) sind es nur zwei Spannungen – gut Wechselspannungen aber das ist mir ja egal, solange ich nur einen zeitlich schmalen Ausschnitt betrachte für ∆t -> 0 sind die Spannungen dann ja konstant –, die ich miteinander vergleichen will.

Ark hat gesagt.:
… könnte es vielleicht sinnvoller sein, etwas anderes als Java zu verwenden, …
Das wäre ärgerlich, jetzt wo ich mich intensiver mit Java beschäftigt habe … meinst du, es ist wirklich blöd das in Java zu machen, weil man sich Probleme ins Haus holt, die man ohne nicht hätte oder ist die Wahl nur nicht ganz so glücklich? Was hälst du für sinnvoller, C++?

Viele Grüße
apple-itob
 
meinst du, es ist wirklich blöd das in Java zu machen, weil man sich Probleme ins Haus holt, die man ohne nicht hätte oder ist die Wahl nur nicht ganz so glücklich? Was hälst du für sinnvoller, C++?
Wenn Java deinen Anforderungen genügt, dann genügt es deinen Anforderungen. 😉 Ich wollte nur ganz allgemein den Hinweis geben, dass bei der Verarbeitung von Audiosignalen möglicherweise Dinge wie Latenzen etc. eine Rolle spielen könnten, die eventuell Java ungeeignet erscheinen lassen.

Ark
 
Hi,

das Problem ist, dass ich nicht einschätzen kann, ob Java ausreicht, weil ich noch zu grün hinter meinen Java-Ohren bin …

Ich habe inzwischen übrigens auch rausgefunden, dass ich nicht die Amplitudendifferenz sondern die Phasenverschiebung messen muss, aber das macht ja vermutlich nicht so einen furchtbar großen Unterschied … oder?
 

Zurück
Oben