Geräuschpegel messen

  • 30 Antworten
  • Letztes Antwortdatum
Aber wenn mehrere Dinge parallel nebeneinander ablaufen sollen, ist meine Variante wirklich nicht das was du brauchst
Zum Vergrößern anklicken....
Ein Thread läuft nicht parallel, sondern führt die einzelnen Thread abwechseln aus. Es läuft immer nur ein Thread. Das nennt man auch Nebenläufigkeit.

Deine Variante war gar nicht so schlecht. Du hast eine Methode benutzt, die eine Sensor, der in einem Thread lauft, aufruft. Ist genau der richtige Weg. ;)

Das ganze schimpft sich Callback. Rückruffunktion

In Java werden zumeist einer der folgenden Entwurfmuster benutzt:

Observer, Visitor und Strategy.

Observer pattern - Wikipedia, the free encyclopedia
Visitor pattern - Wikipedia, the free encyclopedia
Strategy pattern - Wikipedia, the free encyclopedia
 
  • Danke
Reaktionen: ui_3k1
Aber wenn sein sensor keine Daten liefert weil der Sensor z.B. defekt ist (Ok dann ergibt das Spiel gar keinen Sinn ;)) oder aber das Telefon so still liegt das keine Änderungen stattfinden (hat bei mir allerdings nicht funktioniert) dann würde bei ihm auch die Zeit nicht ablaufen und es würde einfach gar nichts passieren.

Funktioniert ja nur, weil der Sensor "zufälligerweise" andauernd neue Daten schickt.
Meiner Meinung nach müsste er (zumindest in der Theorie) das Zeit zählen auslagern ;)

Und meiner Meinung nach laufen Threads (zumindest in der Theorie) gleichzeitig.
Wikipedia definiert Nebenläufigkeit übrigens so:
"Die Nebenläufigkeit, auch Parallelität (englisch concurrency) genannt, ist in der Informatik die Eigenschaft eines Systems, mehrere Berechnungen, Anweisungen oder Befehle gleichzeitig ausführen zu können."

Wenn mehrere CPUs vorhanden sind kann man wirklich parallel arbeiten.
 
Threads laufen unter Java nicht parallel. Aber die CPUs sind so schnell, da fällt es nicht wirklich auf.
Es gibt aber eine Möglichkeit, unter Android wirklich parallel zu arbeiten. Benutze ein RemoteService. Der läuft wirklich auf einem zweiten Kern (Mit einen Kern, ist alles wie gehabt). Man sollte dann nur keine SharedPreferences benutzen, die kommen damit gar nicht klar.
 
Ich finde den Austausch hier super interessant und ziemlich hilfreich. Top!
@amfa: Dass ein stiller Sensor den Thread hinter dem Sensorlistener pausiert glaube ich nicht, schließlich ist der Listener trotzdem im "lauschmodus". Gleichzeitig gibt es ja auch keine Anweisung den Sensorlistener (oder gar die activity) zu verlassen, wenn keine Erschütterung erfolgt. Sicher bin ich mir allerdings auch nicht..
Wo du definitiv recht hast ist, dass es die Nutzbarkeit beeinträchtigen kann, hatte mal ein Programm für einem Arm 91 gebastelt, das einen counter hochzählt und je nach Zählerstand eine LED angesteuert wird. Gleichzeitig sollte die Peripherie einen Tastendruck erkennen, wobei der Tastendruck nicht zu jedem Zeitpunkt "abfangbar" war. Ich meine ein Thread wäre dazu auch die passende Lösung. Werde es die Tage mal testen.
 
@markus.tullius
Gibt's das irgendwo nachzulesen?
Wenn ich z.b. Hier nachgucke:
Parallel Processing and Multi-Core Utilization with Java | EMBARCADEROS

Sieht es mir schon so aus als würden die Threads auf mehreren Cores gleichzeitig laufen (hab mir das jetzt nicht im detail durchgelesen)

@ui_3k1
Naja die Method die du nutzt heist onSensorChanged.
Die wird nach meinem Verständnis nur aufgerufen, wenn sich auch die Sensor Daten geändert haben.
Ändert sich also nichts am Sensor wird die Methode nicht aufgerufen.
Meiner Meinung nach würde dann halt nichts passieren.
 
Natürlich kann man Threads auf mehrere Kernen Laufen lassen, aber dafür muss man zusätzlichen Aufwand treiben. Das package java.util.concurrent unterstützen einen dabei. Und das geht erst sein Java 6. ;)
Ohne diesen Aufwand werden alle Thread nacheinander ausgeführt, wie bei einem Singelcore. Eine andere Möglichkeit unter Android ist, die App mit mehreren Prozessen zu betreiben. Das geht zum Beispiel mit einem Remote Service.
 
Hallo,
Danke für den Beispielcode mit dem Thread! Hat funktioniert.

Nur eine Frage, was wird jetz ausgegeben ?? Das können doch keine dB sein, weil wenn ich reinpfeife zeigt er mir 12,89999 an ??
 
Hmm selber eichen klingt kompliziert, aber gemeint mit der Amplitude sind Pascal oder ?

D.h. ich müsste es dann in dB umrechnen mit 20 log (p/p0), sehe ich das richtig.
 
Soweit ich weiß, kannst du gerade davon nicht ausgehen. Der Sensor wird wohl einen Druck messen, aber ob eine Einheit ein Pascal ist, steht in den Sternen.
 
Super und was kann ich dann jetz machen ?
Wie soll ich es selber eichen wenn ich nirgends nachlesen kann was er mir hier ausgibt ?

Benutze Sony Xperia Miro

Noch ne Frage, bei der Umrechnung, wie komm ich da bitte auf den Wert des Bezugs-Schalldrucks ?? Ist das immer derselbe (20µPascal) ??

Also wenn meine Umrechnung stimmt
db = 20 * Math.log10( amplitude / 20µPascal )

Dann kommt bei mir im Zimmer bei absoluter ruhe, 70dB heraus ...., soll ich jetz einfach ~ immer 68 dB abziehen um ungefähr einen richigen Wert zubekommen ? :D
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten