Zeitkritische Programmierung - Einfache Möglichkeiten..?

Hi,

ich habe so ne Idee im Kopf, für die ich ein recht genaues und konstantes Timing brauche. Nun läuft Android ja auf einer "Quasi-VM", bei der Timer und Tasks ja eher nicht sehr präzise arbeiten.

Jetzt wollte ich bei euch mal nachfragen, ob es denn trotzdem Möglichkeiten gibt, zeitkritisch zu Programmieren. Vor allem in Verbindung mit dem Abspielen von Tönen.

Es gibt ja theoretisch das native C für Android mit der NDK, aber das ist schon recht komplex und wenn ich das richtig verstehe vom RollOut sehr umständlich. Für jede API ne extra Compilerversion etc...

Ich hoffe hier sind ein paar Leute die da Ideen beisteuern können.

Cheers,

Smokehead

Hallo Smoke,

zu a) hast du dir mal SystemClock angeschaut ? reicht dir das in Deinem Falle nicht ? (in Verbindung mit einem Thread/Task)
Oder möchtest du IO-Triggern ?
zu b) NDK ist nicht Compilerversions abhängig, die damit erstellten Binaries ( .so) werden wiederum in deinem apk benutzt-
an der VM kommst du nicht vorbei. (Zygote) Die Oberfläche deiner APp läuft nun mal darüber
Es gibt Processor-Kern Unterschiede arm, armV7,armv8 (64 Bit)

Ich weis ja nicht , wie lange das Ganze laufen soll (Langzeit), man sollte auch hier beachten , dass Android von sich aus , den Process jederzeit anhalten/beenden kann .

Wenn du allerdings eine höhere Genauigkeit benötigst, kannst du auch auf einem gerooteten Gerät ohne Probleme reine
C++ Daemons zum laufen bringen.

Ich wage mal die Vermutung , dass aber dann grundsäztlich ein Android-Device nicht die richtige Wahl für dein Vorhaben ist

Schliesslich ist Android im Kernel bewusst so konzipiert ( verbogen) dass der Focus eher auf andere Dinge gelenkt ist.

Ich werd mir mal SystemClock anschauen..

Ich habs bisher mit Handlern versucht, jedoch bekam ich mit dem Abspielen eines kurzen Tons der Länge 100ms. Bei einer Wiederholung von 200 BPM, sprich alle 300ms, kam das Gerät immer aus dem Rhythmud und wurde äußerst unregelmässig. Auch wenn der Ton intern erzeugt wurde und kein gespeichertes wav-File war.

Ich hab mir SystemClock jetzt mal angeschaut und kurz herumgespielt. So wirklich akkurat ist das immernoch nicht.. Bei den Android-Devs steht aber auch, dass man SystemClock nicht unbedingt zur Steuerung periodischer Tasks nutzen sollte. Dafür sei z.B. die Handler-Klasse da.

So richtig Möglichkeiten habe ich noch keine gefunden. Aber dass es möglich ist weiss ich. Gibt ja Apps mit dkesen Funktionen (Metronom).

Natürlich rücken die aber den Cde nich raus..

Cheers,

Smokehead

Hallo Smoke,

so langsam wird es klar was du machen möchtest : ein Metronom.
Hast du denn das Ganze auch mal in einen vernünftigen Thread (e.g. AsynTask) aufgebaut ??

Wie gibst du den Tick aus ?
Asynchron ? Soundfile oder ToneGenerator ?

Ein metronom ist nicht zweitkritisch unter Android, es muss nur in die passende Umgebung

Bisher hab ich mit Handlern und Runnables das Abspielen von Soundfiles versucht. Zusätzlich habe ichs auch mit einem SoundGenerator versucht, jedoch nur in einer Art Loop, die dann alle UI-Prozesse blockierte. Mein Anliegen ist letztendlich die dynamische Steigerung der Tempi während des Abspielens.

Basis dafür hab ich hier her:
Android: Crafting a Metronome with Audio Synthesis

Mit AsyncTasks sollte ich mich evntl. mal etwas genauer auseinandersetzen. Die hatte ich gar nicht auf dem Schirm.

die dann alle UI-Prozesse blockierte

Zum Vergrößern anklicken....

Deshalb solltest du erst mal AsynTask verwenden UND die Tonausgabe ( Tongenerator / Mediaplayer) asynchron durchführen.
Man muss darauf achten , dass der UI Thread frei laufen kann .

Und innerhalb des AsynTasks , kannst du locker deine Pausen mit SystemClock.sleep() steigern / reduzieren
(abzüglich der Dauer deines Ticks)

P.S zu deinem Audiogenerator : Warum Diesen ? der benötigt lange für das Init.
Muss es was 16 PCM mässiges sein ? schau dir mal den Tongenerator an und setze den Init global

Jetzt hab ich gerade schon gelesen, dass AsynTasks nicht für lang andauernde Prozesse genutzt werden sollten. Stattdessen Executor, ThreadPoolExecutorand FutureTask. Da springt mir zunächst mal der Executor ins Auge. Der könnte die Lösung sein. Ich probiere mich mal daran..

Danke schonmal für deine Antworten und die Hilfe!

Cheers,

Smokehead

Das ist richtig , dass er nicht für lange Operationen benutzt werden sollte.


Allerdings hapert es bei dir noch am Grundkonzept - wenn das Ganze erst mal bei dir in einem Async
läuft , ist die Umstellung auf die Alternativen eine Sache von 5 Minuten .
Du hast aber erst mal das grundsätzliche Problem, den Rahmen zu bauen , deshalb habe ich dir erst mal empfohlen
das Ganze mit einem AsynTask zu realisieren.

Du hast erst mal das zeitkritische Problem , nicht wie lange er durchhält

P.S der Async kann Stunden laufen, das hat andere Gründe , warum darauf hingewiesen wird.

Ich werde mich definitiv zurück melden, sobald ich Erfolge erziele (oder auch feststecke! ).

Viel Erfolg !

...und dann bitte mit ein bisschen Code - unsere Kristallkugel ist nur beschränkt leistungsfähig