amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Tonerkennung [ - Suche - Neue Beiträge - Registrieren - Login - ]

Erste 5 6 7 8 9 -10- 11 [ - Beitrag schreiben - ]

22.09.2006, 15:06 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von MaikG:
Oh, simmt nun sind es 1.648439 - mit goertzel also 1,0 müssten es sein.
Wie muss ich das machen wenn ich 20sekunden will?
Um der Schleife noch eine geht nicht.


Öhm, nicht? Beherrscht MB keine verschachtelten Schleifen??

Ansonsten:
BASIC code:
WHILE Repeat1% < (intervall% * seconds%)
.
.
.
WEND


wäre z.B. ein gangbarer Weg.

Abgesehen davon: 1.648439 ist eindeutig zu lang. Also scheint der Goertzel in BASIC etwas zu langsam zu sein. Da wäre es evtl. sinnvoller, den Telefon-Sound in einen Puffer zu samplen und dann auszuwerten

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

22.09.2006, 15:41 Uhr

MaikG
Posts: 5172
Nutzer
>Öhm, nicht? Beherrscht MB keine verschachtelten Schleifen??

Doch, aber wenn ich das mache passiert gar nichts mehr.

>Abgesehen davon: 1.648439 ist eindeutig zu lang. Also scheint der
>Goertzel in BASIC etwas zu langsam zu sein.

Nein, nicht langsamer als C.
Ohne goertzen ists 1.164063 ergo läuft der Code genausowenig
wie die anderen...

>Da wäre es evtl. sinnvoller, den Telefon-Sound in einen Puffer
>zu samplen und dann auszuwerten

Das geht nicht wirklich gut, es soll z.B. ein Zuganscode bearbeitet
werden, da ist die erste Ziffer noch nicht fertig wenn ich
die letzte eingegeben habe.
Ich müsste versuchen das vorauszuwerten, aber das geht nicht,
weil wir dann wieder bei störgeräuschen sind. Wind/Autos/Züge/Wasser
kann ich nur genauso wie DTMF als Amplitude sehen...


> WHILE Repeat1% < (intervall% * seconds%)
> WEND

Bei seconds%=20 bekomme ich so 4.78125 Sekunden realtime???

[ Dieser Beitrag wurde von MaikG am 22.09.2006 um 15:44 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

22.09.2006, 16:23 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von MaikG:
>Öhm, nicht? Beherrscht MB keine verschachtelten Schleifen??

Doch, aber wenn ich das mache passiert gar nichts mehr.

>Abgesehen davon: 1.648439 ist eindeutig zu lang. Also scheint der
>Goertzel in BASIC etwas zu langsam zu sein.

Nein, nicht langsamer als C.


Doch, ist er (Einschränkung kommt gleich). Der Code tut nichts anderes, als 125µs zu warten bzw. in dieser Zeit seinen Job zu erledigen. Wenn deutlich mehr als eine Sekunde dabei herauskommt, stimmt entweder die Zeitmessung nicht (die Einschränkung) oder der Code ist zu langsam und Dein Programm rennt der EClock hinterher.

Zitat:
Ohne goertzen ists 1.164063 ergo läuft der Code genausowenig
wie die anderen...


Da der C-Code hier bis auf die Ungenauigkeiten von GetSysTime() immer brav Zeiträume von 1 Sekunde ausspuckt (sogar inzwischen MIT Goertzel), liegt der Haken vermutlich bei MB. Allerdings weiß ich nicht, wie flott Dein Amiga ist. Aber ein 030er/50MHz sollte das eigentlich eben gerade schaffen...

Zitat:
>Da wäre es evtl. sinnvoller, den Telefon-Sound in einen Puffer
>zu samplen und dann auszuwerten

Das geht nicht wirklich gut, es soll z.B. ein Zuganscode bearbeitet
werden, da ist die erste Ziffer noch nicht fertig wenn ich
die letzte eingegeben habe.


Ich sags mal so: Wenn das System ausschließlich für Deinen Gebrauch bestimmt ist, kannst Du Dir ja (wissentlich) beim Eingeben der Ziffern Zeit lassen. Also so: 1. Ziffer, 1 Sekunde warten, 2. Ziffer...

Das sollte eigentlich tun.

Zitat:
Ich müsste versuchen das vorauszuwerten, aber das geht nicht,
weil wir dann wieder bei störgeräuschen sind. Wind/Autos/Züge/Wasser
kann ich nur genauso wie DTMF als Amplitude sehen...


Der Goertzel erkennt die Störgeräusche aber normal doch nicht als DTMF-Töne?


Zitat:
> WHILE Repeat1% < (intervall% * seconds%)
> WEND

Bei seconds%=20 bekomme ich so 4.78125 Sekunden realtime???


Irgendwie lustig, da ist es auf einmal VIEL schneller... intervall% bezeichnet doch das Warte-Intervall in Hz (Takte/s). Wenn man dann das Intervall (z.B. 8000) mit 20 multipliziert, ergeben sich 160000 Durchläufe der Schleife. Die Schleife wird also erst dann verlassen, wenn repeat% den Wert 160000 erreicht.

Ach, warte: % bezeichnet nicht zufällig ein 16Bit-Integer?? Wenn ja, hast Du da wieder ein Überlauf-Problem (-32768 bis 32767). Mach daraus dann mal ein &.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

22.09.2006, 17:54 Uhr

MaikG
Posts: 5172
Nutzer
>Da der C-Code hier bis auf die Ungenauigkeiten von GetSysTime() immer
>brav Zeiträume von 1 Sekunde ausspuckt (sogar inzwischen MIT
>Goertzel), liegt der Haken vermutlich bei MB.

Ich nehme die Timer funktion von MB zur kontrolle, die stimmt
mit meiner Armbanduhr überein.

>Allerdings weiß ich nicht, wie flott Dein Amiga ist. Aber ein 030er/50MHz
>sollte das eigentlich eben gerade schaffen...

An dem ich Progge ist ein 060@60MHZ drin, später soll es mal
auf 030er/50MHZ laufen.

>Ich sags mal so: Wenn das System ausschließlich für Deinen Gebrauch
>bestimmt ist, kannst Du Dir ja (wissentlich) beim Eingeben der
>Ziffern Zeit lassen. Also so: 1. Ziffer, 1 Sekunde warten,
>2. Ziffer...

Und woher weiss der Computer das grade die erste Ziffe angekommen
ist und nicht nur ein Umweltgeräusch? Das ist ja das Problem
mit der Spracherkennung, innen kein Problem aber aussen ist
es niemal still.

>Der Goertzel erkennt die Störgeräusche aber normal doch nicht als
>DTMF-Töne?

Nein, Goertzel nicht aber ich kann ja nicht 1 sekunde Samplen
2 sekunden auf Goertzel warten, wieder 1 sekunde Samplen usw.
Wenns nicht in Realtime geht müsste ich das vorauswerten.


Zitat:
> WHILE Repeat1% < (intervall% * seconds%)
> WEND

Bei seconds%=20 bekomme ich so 4.78125 Sekunden realtime???

>Irgendwie lustig, da ist es auf einmal VIEL schneller... intervall%
>bezeichnet doch das Warte-Intervall in Hz (Takte/s). Wenn man dann
>das Intervall (z.B. 8000) mit 20 multipliziert, ergeben sich 160000
>Durchläufe der Schleife. Die Schleife wird also erst dann verlassen, wenn repeat% den Wert 160000 erreicht.

Aber es kann doch nicht schneller als Echtzeit sein wenn es über
einen Timer läuft!

>Ach, warte: % bezeichnet nicht zufällig ein 16Bit-Integer?? Wenn
>ja, hast Du da wieder ein Überlauf-Problem (-32768 bis 32767).
>Mach daraus dann mal ein &.

Oh, stimmt Repeat wird ja immer erhöht und muss ja irgendwann 160000
sein.

Hängt sich auf wenn man Repeat1& und 20sek nimmt.

[ Dieser Beitrag wurde von MaikG am 22.09.2006 um 18:09 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

22.09.2006, 18:26 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von MaikG:
>Da der C-Code hier bis auf die Ungenauigkeiten von GetSysTime() immer
>brav Zeiträume von 1 Sekunde ausspuckt (sogar inzwischen MIT
>Goertzel), liegt der Haken vermutlich bei MB.

Ich nehme die Timer funktion von MB zur kontrolle, die stimmt
mit meiner Armbanduhr überein.


Das mag durchaus sein. Nichts desto trotz arbeitet der C-Code so, wie gewünscht. Bis auf die Abweichungen, die offensichtlich von GetSysTime() und der von mir etwas ungeschickt angelegten Reihenfolge stammen.

Da kommt ziemlich häufig eine Differenz von exakt 1 Sekunde bei heraus (bei relativ beliebiger Frequenz, bis etwas über 12000Hz), die Abweichungen bewegen sich im Rahmen von 60000µs, sehr selten 80000µs, meist 20000µs. Aber keine 600000.

Eine so hohe Abweichung wäre für mich ein Zeichen, daß der Code langsamer läuft als der Timer. Bei dem C-Code geht das bei 12500Hz los, bei 13000Hz z.B. bekomme ich eine Abweichung von 120000µs, immer "nach oben".

Zitat:
>Allerdings weiß ich nicht, wie flott Dein Amiga ist. Aber ein 030er/50MHz
>sollte das eigentlich eben gerade schaffen...

An dem ich Progge ist ein 060@60MHZ drin, später soll es mal
auf 030er/50MHZ laufen.


Ein 060er sollte das auf jeden Fall hinbekommen. Meiner schaffts problemlos bis 12000 Hz.

Zitat:
>Ich sags mal so: Wenn das System ausschließlich für Deinen Gebrauch
>bestimmt ist, kannst Du Dir ja (wissentlich) beim Eingeben der
>Ziffern Zeit lassen. Also so: 1. Ziffer, 1 Sekunde warten,
>2. Ziffer...

Und woher weiss der Computer das grade die erste Ziffe angekommen
ist und nicht nur ein Umweltgeräusch?


Wenn er DTMF-Töne erkennt, weiß er in dem Moment, wo ein solcher Ton erkannt wurde, daß die erste Ziffer ankam. Wenn nicht, von vorn anfangen.

Zitat:
Das ist ja das Problem
mit der Spracherkennung, innen kein Problem aber aussen ist
es niemal still.


Genau dafür wurden die DTMF-Töne doch entwickelt. Sie sind relativ unempfindlich gegen Störgeräusche, was die Auswertung angeht.

Zitat:
>Der Goertzel erkennt die Störgeräusche aber normal doch nicht als
>DTMF-Töne?

Nein, Goertzel nicht aber ich kann ja nicht 1 sekunde Samplen
2 sekunden auf Goertzel warten, wieder 1 sekunde Samplen usw.
Wenns nicht in Realtime geht müsste ich das vorauswerten.


Nein, Du wertest es nachlaufend aus. Erst samplen, dann goertzeln, dann wieder sampeln...

Zitat:
Zitat:
> WHILE Repeat1% < (intervall% * seconds%)
> WEND

Bei seconds%=20 bekomme ich so 4.78125 Sekunden realtime???

>Irgendwie lustig, da ist es auf einmal VIEL schneller... intervall%
>bezeichnet doch das Warte-Intervall in Hz (Takte/s). Wenn man dann
>das Intervall (z.B. 8000) mit 20 multipliziert, ergeben sich 160000
>Durchläufe der Schleife. Die Schleife wird also erst dann verlassen, wenn repeat% den Wert 160000 erreicht.

Aber es kann doch nicht schneller als Echtzeit sein wenn es über
einen Timer läuft!


Was, wenn es bei Dir aus irgendeinem Grund eben nicht synchron mit dem Timer läuft? Leider kenne ich den Grund nicht, kann Dir also momentan nicht sagen, was da schiefgeht. Eventuell findet Holger ja noch etwas.

Zitat:
>Ach, warte: % bezeichnet nicht zufällig ein 16Bit-Integer?? Wenn
>ja, hast Du da wieder ein Überlauf-Problem (-32768 bis 32767).
>Mach daraus dann mal ein &.

Oh, stimmt Repeat wird ja immer erhöht und muss ja irgendwann 160000
sein.

Hängt sich auf wenn man Repeat1& und 20sek nimmt.


Umso schlimmer. Schau doch auch mal nach, wie MB die Datentypen wandelt, wenn das Ergebnis nicht mehr "reinpaßt". Eventuell müßtest Du auch die anderen Variablen, die an dieser Rechnung beteiligt sind, als 32Bit-Integer wählen.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

22.09.2006, 23:40 Uhr

MaikG
Posts: 5172
Nutzer
>Ein 060er sollte das auf jeden Fall hinbekommen.
>Meiner schaffts problemlos bis 12000 Hz.

Meine ich doch.

>Nein, Du wertest es nachlaufend aus. Erst samplen, dann goertzeln,
>dann wieder sampeln...

Sagen wir 1 Sekunde Samplen, 2 sekunde Samplen

23:35:01 Samplen
23:35:02 Auswerten
23:35:03 Auswerten
23:35:04 Samplen
23:35:05 Auswerten
23:35:06 Auswerten

Du siehst jeweils immer 2 sekunden indenen nichts erkannt werden
kann. Ich als Mensch habe leider keine Clock leitung so dass ich
micht damit Syncronisieren könnte...


>Was, wenn es bei Dir aus irgendeinem Grund eben nicht synchron mit
>dem Timer läuft?

Das Prog besteht wenn ich den Rest ausklammere nur aus der
Taktung, selbst diese schaft es nicht bei 8000HZ eine Sekunde
zu erreichen.

>Umso schlimmer. Schau doch auch mal nach, wie MB die Datentypen
>wandelt, wenn das Ergebnis nicht mehr "reinpaßt". Eventuell müßtest
>Du auch die anderen Variablen, die an dieser Rechnung beteiligt
>sind, als 32Bit-Integer wählen.

Ich guck.

[ - Antworten - Zitieren - Direktlink - ]

23.09.2006, 11:05 Uhr

MaikG
Posts: 5172
Nutzer
So, ich hab einen Fehler im Programm entdekt, WaitIO& muss hinter
den 3 "newlow" berechnungszeilen. Weil so entsteht die abweichung.
Jetzt hab ich ohne goertzel 20.07422, auch wenn ich zwischendurch
etwas mache z.B. kann ich auch die Zeit ausgeben ohne das dieser
Wert abweicht. Also endlich eine Timer Funktion die zu Funktionieren
scheint.

Schlechte Nachricht: Mit goertel sinds immernoch 26,56641 also
6,56641 sekunden zuviel auf 20 sekunden.


code:
546 IF Repeat1&=160000 THEN 789

        newLow&=myEClockValLo& + diff&
        IF newLow& >= 0 AND myEClockValLo& < 0 THEN INCR myEClockValHi&
        myEClockValLo&=newLow&

	junk&=WaitIO&(tr&) REM neu

       POKEW tr& + IORequestio_Command%, TR_ADDREQUEST&
       POKEL tr& + tr_time% + tv_secs%, myEClockValHi&
       POKEL tr& + tr_time% + tv_micro%, myEClockValLo&

       SendIO&(tr&)

       INCR repeat1&
       REM INCR mycount%:IF mycount%=8000 THEN mycount%=0:INCR myseconds%:move rpS&,20,25:Text rpS&, SADD(TIME$+CHR$(0)),8
       sa&=PEEKB(&hBFE101)<<8
       IF sa&>&H7FFF THEN sa&=sa& OR &HFFFF0000&
       bla%=goertzel%(sa&)
GOTO 546
789


[ - Antworten - Zitieren - Direktlink - ]

23.09.2006, 14:24 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von MaikG:
Nein, Goertzel nicht aber ich kann ja nicht 1 sekunde Samplen
2 sekunden auf Goertzel warten, wieder 1 sekunde Samplen usw.
Wenns nicht in Realtime geht müsste ich das vorauswerten.


Das kannst Du natürlich nicht. Aber der Algorithmus, so wie er hier implementiert ist, benötigt nur 92 Samples, um einen Ton zu erkennen (oder keinen Ton zu erkennen).

Das sind 11,5 ms. Du kannst also problemlos 11,5ms samplen, dann 18 ms zur Auswertung benötigen, und solange ein DTMF-Ton länger als 30 ms dauert, wird Dir keiner entgehen.

Aber, wie schon mehrfach gesagt, erstmal solltest Du ein funktionierendes Programm haben (dem nähern wir uns ja jetzt), und dann können wir uns um die Geschwindigkeit kümmern. Denn bislang haben wir noch nicht wirklich optimiert (was ja auch richtig so ist).

Realtime könnte also immer noch möglich sein.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

23.09.2006, 15:05 Uhr

MaikG
Posts: 5172
Nutzer
>Das kannst Du natürlich nicht. Aber der Algorithmus, so wie er hier
>implementiert ist, benötigt nur 92 Samples, um einen Ton zu erkennen
>(oder keinen Ton zu erkennen).
>Das sind 11,5 ms. Du kannst also problemlos 11,5ms samplen,
>dann 18 ms zur Auswertung benötigen, und solange ein DTMF-Ton
>länger als 30 ms dauert, wird Dir keiner entgehen.

Mh, interesant.

>Aber, wie schon mehrfach gesagt, erstmal solltest Du ein
>funktionierendes Programm haben (dem nähern wir uns ja jetzt),
>und dann können wir uns um die Geschwindigkeit kümmern. Denn
>bislang haben wir noch nicht wirklich optimiert (was ja auch
>richtig so ist).

Ich hab doch jetzt ein Programm was ein Timing liefert, auch
wenn das Timen doch noch recht lang dauert scheint es zu Funktionieren.
Besser währe natürlich ein Timing über den CIA.

Also Timing+goertzel=26,6 sekunden, Timing ohne goertzel=20.07422,
görtzel incl. 16Bit->8Bit ohne Timing=9.46 Sekunden.
Jeweils bei 20 Sekunden echtzeit.

[ - Antworten - Zitieren - Direktlink - ]

23.09.2006, 23:54 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von MaikG:

>Aber, wie schon mehrfach gesagt, erstmal solltest Du ein
>funktionierendes Programm haben (dem nähern wir uns ja jetzt),
>und dann können wir uns um die Geschwindigkeit kümmern. Denn
>bislang haben wir noch nicht wirklich optimiert (was ja auch
>richtig so ist).

Ich hab doch jetzt ein Programm was ein Timing liefert, auch
wenn das Timen doch noch recht lang dauert scheint es zu Funktionieren.
Besser währe natürlich ein Timing über den CIA.


Also, das "Timen" dauert nicht lang. Es funktioniert in weiten Grenzen sehr gut, das Problem ist bisher nur die Laufzeit der Auswertung. Da kann man noch optimieren, wie Holger schon sagte.

Zitat:
Also Timing+goertzel=26,6 sekunden, Timing ohne goertzel=20.07422,
görtzel incl. 16Bit->8Bit ohne Timing=9.46 Sekunden.
Jeweils bei 20 Sekunden echtzeit.


Hm, bei dem Text kann ich mich des Eindrucks nicht erwehren, daß Du nicht verstanden hast, wozu das Timing eigentlich dient.

Es nützt Dir rein gar nichts, wenn Du ungesteuert sampelst. Sicher liest Du dann auch 8000 Werte vom Parallelport, aber die so gelesenen Werte sind nutzlos. Du hast dann keinen Schimmer (bzw. der Algorithmus), welche Frequenz die vorliegende Wellenform besitzt, weil Dir die Zeitbasis fehlt, Du bekommst nur verzerrte Amplituden (manche Werte tauchen doppelt auf, manche gar nicht, völlig ungesteuert halt).

Das Timing mit 125µs dient dazu, die Zeitbasis zu erhalten, die Dir eine Frequenzermittlung mittels Goertzel überhaupt erst ermöglicht.

Angenommen, Du hast bei einer gesteuerten Sample-Frequenz von 8000Hz alle 2 Sample-Werte einen Wechsel der Amplitude (positiv nach negativ und umgekehrt). Dank der Tatsache, daß Du 8000Hz Samplefrequenz gewählt hast, weißt Du somit, daß die gesamplete Wellenform eine Frequenz von 4000Hz besitzt (ein primitives Beispiel, gebe ich zu).

Schlußfolgerung: Wir müssen es hinbekommen, daß Sampling und Auswertung der Sample-Werte im notwendigen Zeitrahmen abgewickelt werden können.

Deine Versuche mit und ohne Timing sowie die Erkenntnis, daß das ohne Goertzel zeitmäßig hinhaut, mit Goertzel aber nicht, bringen Dir überhaupt nichts.

Der C-Code packt es auf schnellen Maschinen mit Goertzel ziemlich problemlos, also mußt Du Dich evtl. mit Holgers Hilfe (ich kann da, mangels MB, wohl nicht allzu viel helfen) hinsetzen und das Programm optimieren, bis alles im gewählten Zeitrahmen abgearbeitet werden kann und Dein Ziel somit erreicht ist.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

24.09.2006, 10:11 Uhr

MaikG
Posts: 5172
Nutzer
> Zitat:
> Also Timing+goertzel=26,6 sekunden, Timing ohne goertzel=20.07422,
> görtzel incl. 16Bit->8Bit ohne Timing=9.46 Sekunden.
> Jeweils bei 20 Sekunden echtzeit.
>
>Hm, bei dem Text kann ich mich des Eindrucks nicht erwehren, daß Du nicht verstanden hast, wozu das Timing eigentlich dient.

Doch das habe ich zu 100% verstanden. Aber warum benötigt görtzel
ohne Timing nur 9.46 Sekunden aber mit Timing 26,6 sekunden?
Das heisst alleine das Timing benötigt mindestens 17 sekunden.
Jeweils liegt gar kein Einganssignal an also die Einganswerte sind
trotz unterschiedlicher Rate die selben.
Das goertzel findet ja zwischen den Timing statt und nicht danach...

[ - Antworten - Zitieren - Direktlink - ]

24.09.2006, 10:30 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von MaikG:
>Abgesehen davon: 1.648439 ist eindeutig zu lang. Also scheint der
>Goertzel in BASIC etwas zu langsam zu sein.

Nein, nicht langsamer als C.


MaxonBasic ist wirklich *bedeutend* langsamer als C. Ich hab damals mal Spaßhalber ein paar kleine Programme von MaxonBasic nach BlitzBasic konvertiert und war erstaunt, wie schnell es mit Blitz geht. Amiblitz läuft ja leider hier nicht auf meinem Amiga, sonst würde ich es gerne auch da testen.
Ich will einfach damit tippen das der Geschwindigkeitsunterschied zwischen MaxonBasic und C enorm ist. Deswegen versuch ich auch möglichst viel mit Betriebssystemroutinen und externen Libs zu machen...
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

24.09.2006, 15:26 Uhr

MaikG
Posts: 5172
Nutzer
>MaxonBasic ist wirklich *bedeutend* langsamer als C.

In dem Fall ist es jedoch mit C vergleichbar.

>Ich hab damals mal Spaßhalber ein paar kleine Programme von
>MaxonBasic nach BlitzBasic konvertiert und war erstaunt, wie
>schnell es mit Blitz geht. Amiblitz läuft ja leider hier nicht auf
>meinem Amiga, sonst würde ich es gerne auch da testen.

Tja, BB ist nicht grade Systemkonform...

>Ich will einfach damit tippen das der Geschwindigkeitsunterschied
>zwischen MaxonBasic und C enorm ist.

Achso, ein C Programm hast du also noch nicht direkt mit MB
verglichen? Ich hab schon in C und Basic ein und das selbe
Programm geschrieben und es gab nur einen minimalen unterschied.

>Deswegen versuch ich auch möglichst viel mit Betriebssystemroutinen
>und externen Libs zu machen...

Das ist immer gut, weil MB wird nicht weiterentwickelt, das
Betriebssystem schon.

[ - Antworten - Zitieren - Direktlink - ]

24.09.2006, 16:29 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von MaikG:
>MaxonBasic ist wirklich *bedeutend* langsamer als C.

In dem Fall ist es jedoch mit C vergleichbar.

Das kann ich kaum glauben, da ich z.b. beim alten BMP-Readerprojekt versucht habe mit MB z.b. BGR nach RGB zu wandeln und selbst das dauert schon relativ lang, schlimmer noch bei Zoomberechnungen. Gerade das ist verdammt langsam, bzw. sieht man gerade da, das MB nicht gerade schnell ist. Sogar ACE ist bei Integer schneller!
Zitat:
Tja, BB ist nicht grade Systemkonform...
Man kann in BB vermutlich genau so Systemkonform programmieren wie mit MB oder C. Hat damit nichts zu tun.
Zitat:
>Ich will einfach damit tippen das der Geschwindigkeitsunterschied
>zwischen MaxonBasic und C enorm ist.

Achso, ein C Programm hast du also noch nicht direkt mit MB
verglichen? Ich hab schon in C und Basic ein und das selbe
Programm geschrieben und es gab nur einen minimalen unterschied.

Bei einem anderen Versuch anfang des Jahres habe ich mal ein Mandelbrottprogramm auf meinem Rechner compiliert und zwar extra für einen 060er und das war schon ein riesiger unterschied zu MB, das kann ich dir tippen. Und dabei war das C-Programm nicht mal vom Code her optimiert...
Glaub mir, MBasic ist wirklich nicht schnell.
Zitat:
>Deswegen versuch ich auch möglichst viel mit Betriebssystemroutinen
>und externen Libs zu machen...

Das ist immer gut, weil MB wird nicht weiterentwickelt, das
Betriebssystem schon.


Noch ein Grund ist halt auch, das das Programm auch bei OttoNormal-User schneller werden kann, wenn das Betriebssystem entweder durch Patchs oder neuere Versionen besser wird.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

24.09.2006, 21:42 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von MaikG:
> Zitat:
> Also Timing+goertzel=26,6 sekunden, Timing ohne goertzel=20.07422,
> görtzel incl. 16Bit->8Bit ohne Timing=9.46 Sekunden.
> Jeweils bei 20 Sekunden echtzeit.
>
>Hm, bei dem Text kann ich mich des Eindrucks nicht erwehren, daß Du nicht verstanden hast, wozu das Timing eigentlich dient.

Doch das habe ich zu 100% verstanden. Aber warum benötigt görtzel
ohne Timing nur 9.46 Sekunden aber mit Timing 26,6 sekunden?
Das heisst alleine das Timing benötigt mindestens 17 sekunden.
Jeweils liegt gar kein Einganssignal an also die Einganswerte sind
trotz unterschiedlicher Rate die selben.
Das goertzel findet ja zwischen den Timing statt und nicht danach...


Eben. Rechne doch mal nach.
[über den Daumen peil]
55µs benötigt der Goertzel bei Dir (9.46 / 8000 / 20)
[/über den Daumen peil].

Das bedeutet, für WaitIO() (inkl. Message-Handling) und die Neuberechnung der EclockVal bleiben 70µs (da sind die Sprünge sowie SendIO() noch nicht drin). Das langt locker.

Das sieht für mich eher so aus, als würde die Zeitmessung via MB-Funktion nicht ganz hasenrein laufen, vermutlich ähnlich wie mit GetSysTime(), nur noch ungenauer, je nach Last.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 24.09.2006 um 21:50 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

24.09.2006, 22:16 Uhr

MaikG
Posts: 5172
Nutzer
>Eben. Rechne doch mal nach.
>[über den Daumen peil]
>55µs benötigt der Goertzel bei Dir (9.46 / 8000 / 20)
>[/über den Daumen peil].
>Das bedeutet, für WaitIO() (inkl. Message-Handling) und die
>Neuberechnung der EclockVal bleiben 70µs (da sind die Sprünge
>sowie SendIO() noch nicht drin). Das langt locker.

Anscheinend aber nicht.

>Das sieht für mich eher so aus, als würde die Zeitmessung via
>MB-Funktion nicht ganz hasenrein laufen, vermutlich ähnlich wie
>mit GetSysTime(), nur noch ungenauer, je nach Last.


Nein das ist nicht so, einmal merke ich den Unterschied von
20 auf 27 sekunden und ausserdem habe ich ebend nochmal
mit der Stoppuhr geguckt, die MB Zeit stimmt mit der auf der
Stoppuhr überein.

[ - Antworten - Zitieren - Direktlink - ]

24.09.2006, 23:55 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von MaikG:
>Eben. Rechne doch mal nach.
>[über den Daumen peil]
>55µs benötigt der Goertzel bei Dir (9.46 / 8000 / 20)
>[/über den Daumen peil].
>Das bedeutet, für WaitIO() (inkl. Message-Handling) und die
>Neuberechnung der EclockVal bleiben 70µs (da sind die Sprünge
>sowie SendIO() noch nicht drin). Das langt locker.

Anscheinend aber nicht.


Also, wenn das nicht reicht, stimmt die Zeitangabe für den Goertzel-Lauf nicht. Definitiv. Der Goertzel ist zwar nicht besonders aufwändig, benötigt aber sicherlich etwas mehr Zeit als die Kombination WaitPort()/GetMsg()/EClockVal-Berechnung und SendIO().

Selbst, wenn das nicht der Fall sein sollte, ist wohl noch ausreichend Reserve für diese Folge vorhanden.

Im C-Code haut das auch einwandfrei hin, MIT Goertzel. Auf einem 060er. Bis 12000Hz.

Zitat:
>Das sieht für mich eher so aus, als würde die Zeitmessung via
>MB-Funktion nicht ganz hasenrein laufen, vermutlich ähnlich wie
>mit GetSysTime(), nur noch ungenauer, je nach Last.

Nein das ist nicht so, einmal merke ich den Unterschied von
20 auf 27 sekunden und ausserdem habe ich ebend nochmal
mit der Stoppuhr geguckt, die MB Zeit stimmt mit der auf der
Stoppuhr überein.


Wir können jetzt noch eine halbe Ewigkeit weiter raten. Der C-Code funktioniert. Er ist ausreichend schnell, liefert Zeitwerte, die sich von Deinen dahingehend unterscheiden, daß sie immer rund um eine Sekunde ergeben (ziemlich oft sogar exakt eine Sekunde, mit maximalen Abweichungen von 80000µs/Durchlauf statt 600000), der selbiges 20 mal problemlos wiederholt (und das sicherlich auch bei 1000 Wiederholungen problemlos erledigt) und wahlweise auch den Goertzel-Algorithmus beinhalten darf, ohne daß sich am Verhalten etwas groß verändert (nur die maximal erreichbare Frequenz sinkt etwas ab).

Frage: Welcher Code liefert ein anderes als das gewünschte Ergebnis?

Offensichtlich der BASIC-Code. Also müssen wir jetzt schauen, woran es bei Deinem Code genau hapert.

Da die Benutzung des timer.device (soweit ich das überblicken kann) identisch mit der C-Variante ist, klemmt es wohl an einem anderen Punkt des Programms.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

25.09.2006, 09:57 Uhr

MaikG
Posts: 5172
Nutzer
>Also, wenn das nicht reicht, stimmt die Zeitangabe für den
>Goertzel-Lauf nicht. Definitiv.

Definitiv funktioniert meine Stoppuhr korrekt!!! Die hat nix mit
Basic oder Computern zu tun.

>Der Goertzel ist zwar nicht besonders aufwändig, benötigt aber
>sicherlich etwas mehr Zeit als die Kombination WaitPort()/GetMsg()/EClockVal-Berechnung
>und SendIO().

Tja so sollte es sein, aber wenn ich ebend diese sachen ausklammere
rennt das Programm.

>Im C-Code haut das auch einwandfrei hin, MIT Goertzel. Auf einem
>060er. Bis 12000Hz.

Alternativ könnte man ein C Programm in betracht ziehen, so
das das Basic Programm irgendwie mit dem C Programm kommuniziert
oder auch als Maschienencode in Basic einbinden.
Mich wurmt das aber das bei dem MB Prog was nicht stimmt.

>Der C-Code funktioniert.

Ist der wirklich Identisch mit dem Basic code? Da wurden einige
änderungen vorgenommen z.B. wo ReadEclock abgestürzt ist.

>Offensichtlich der BASIC-Code. Also müssen wir jetzt schauen,
>woran es bei Deinem Code genau hapert.

Ja.

>Da die Benutzung des timer.device (soweit ich das überblicken kann)
>identisch mit der C-Variante ist, klemmt es wohl an einem anderen
>Punkt des Programms.

Das glaub ich nicht. Es kann sein das es bei der C->Basic umwandlung
zu fehlern gekommen ist aber wenn dann irgendwo im Time Code.
Holger hat den goertzel teil auch schon in Basic mit einer
Datei gemacht und das Funktioniert und entspricht der C geschwindigkeit.

[ - Antworten - Zitieren - Direktlink - ]

25.09.2006, 13:46 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von MaikG:
Alternativ könnte man ein C Programm in betracht ziehen, so
das das Basic Programm irgendwie mit dem C Programm kommuniziert
oder auch als Maschienencode in Basic einbinden.
Mich wurmt das aber das bei dem MB Prog was nicht stimmt.


Daran hatte ich auch schon am Anfang gedacht. Man könnte z.B. aus dem C Programm ein Commodity machen, das aus erkannten Tastendrücken künstliche Tastatureingaben macht. Dann funktioniert es mit jedem beliebigen Programm.

Andererseits finde ich es eben genauso interessant, das Basic-Programm zu vollenden, jetzt, wo es schon so weit gediehen ist. Das ist eben die Sache mit dem Hobby...

Mal ne andere Frage. Was für Optionen zur Ziel CPU/FPU besitzt die Vollversion von MaxonBasic eigentlich? Die Demoversion besitzt da irgendwie gar nichts. Und kannst Du mir mal sowohl Quellcode, als auch ne mit Deinen Optionen übersetzte Version des Programms schicken, damit ich die testweise in nen Debugger stecken kann? (Die NoLines Option vor dem Übersetzen natürlich ausschalten)

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

25.09.2006, 18:00 Uhr

MaikG
Posts: 5172
Nutzer
>Mal ne andere Frage. Was für Optionen zur Ziel CPU/FPU besitzt die
>Vollversion von MaxonBasic eigentlich?

Keine...
Aber erzeugte Programme lauffähig auf allen Prozessoren(68000-68040),
steht auf diesem Hefter dingels.
Abgesehen von einschränkungen von Peek bei 000 auf ungraden adressen.


>Und kannst Du mir mal sowohl Quellcode, als auch ne mit Deinen
>Optionen übersetzte Version des Programms schicken,
>damit ich die testweise in nen Debugger stecken kann?
>(Die NoLines Option vor dem Übersetzen natürlich ausschalten)

Klar, aber ich hab deine Email adresse nicht...
Aber nicht mit diesem mitgelieferten Debugger, der crash auf
060.

[ - Antworten - Zitieren - Direktlink - ]

25.09.2006, 20:59 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von MaikG:
>Also, wenn das nicht reicht, stimmt die Zeitangabe für den
>Goertzel-Lauf nicht. Definitiv.

Definitiv funktioniert meine Stoppuhr korrekt!!! Die hat nix mit
Basic oder Computern zu tun.


Das habe ich ja auch nicht angezweifelt. Andererseits wäre es natürlich denkbar, daß Dir bei dem Goertzel-only-Programm was daneben gelaufen ist...

Zitat:
>Der Goertzel ist zwar nicht besonders aufwändig, benötigt aber
>sicherlich etwas mehr Zeit als die Kombination WaitPort()/GetMsg()/EClockVal-Berechnung
>und SendIO().

Tja so sollte es sein, aber wenn ich ebend diese sachen ausklammere
rennt das Programm.


Und eben das kommt mir etwas seltsam vor. Das Timing ist lange nicht so aufwändig, wie es vielleicht auf einen nicht daran gewöhnten BASIC-Programmierer wirkt.

Zitat:
>Im C-Code haut das auch einwandfrei hin, MIT Goertzel. Auf einem
>060er. Bis 12000Hz.

Alternativ könnte man ein C Programm in betracht ziehen, so
das das Basic Programm irgendwie mit dem C Programm kommuniziert
oder auch als Maschienencode in Basic einbinden.
Mich wurmt das aber das bei dem MB Prog was nicht stimmt.


Das sehe ich ähnlich. Falls es ums Verrecken nicht mit BASIC hinzubekommen sein sollte, kann man immer noch z.B. einen externen Task, der die Erkennung der DTMF-Töne erledigt, in C vorsehen.

Eventuell findet Holger ja etwas heraus, wenn er Dein Executable durch den Debugger scheucht.

Zitat:
>Der C-Code funktioniert.

Ist der wirklich Identisch mit dem Basic code? Da wurden einige
änderungen vorgenommen z.B. wo ReadEclock abgestürzt ist.


Diese "Änderungen" haben wir im C-Code ja auch drin. Da gings darum, auf die Library-Funktionen des timer.device zuzugreifen. Da mußten wir genauso eine Library-Base anlegen und mit einem Wert füllen, wie Du es dann (mit Holgers Hilfe) in BASIC gemacht hast. Ich glaube nicht, daß ausgerechnet dieses Vorgehen was mit dem Zeitproblem zu tun hat. Im Gegenteil, dieses Vorgehen ist zwingend notwendig. Hast Du ja an den Abstürzen merken können.

Zitat:
>Da die Benutzung des timer.device (soweit ich das überblicken kann)
>identisch mit der C-Variante ist, klemmt es wohl an einem anderen
>Punkt des Programms.

Das glaub ich nicht. Es kann sein das es bei der C->Basic umwandlung
zu fehlern gekommen ist aber wenn dann irgendwo im Time Code.


Vergleiche die beiden mal. Die eigentliche Benutzung des timer.device gleicht Punkt für Punkt der C-Variante. Es ist ja auch wirklich nichts Wildes oder Magisches. Werte berechnen, in die timerequest-Struktur eintragen, TR_ADDREQUEST dazu, mittels SendIO() ans timer.device senden, warten. Das wars schon. Das Gleiche macht Dein BASIC-Programm ja auch. Der einzige mögliche Fehler, der sich dabei noch aufdrängen könnte, wäre einer in den OS-Includes von MB. Wäre aber sehr seltsam, wenn es so wäre.

Also, die Zeilen, die wirklich nur mit dem timer.device zu tun haben, sind nahezu identisch in BASIC und in C. Möglich wäre noch ein Problem im "Drumherum" um die Mimik für das timer.device. Mich macht es halt nervös, daß die Sache in C problemlos läuft, aber ein beinahe identisches Programm in BASIC nicht.

Zitat:
Holger hat den goertzel teil auch schon in Basic mit einer
Datei gemacht und das Funktioniert und entspricht der C geschwindigkeit.


Hattest DU den dann auch mal getestet?

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

25.09.2006, 22:49 Uhr

MaikG
Posts: 5172
Nutzer
>Das habe ich ja auch nicht angezweifelt. Andererseits wäre es
>natürlich denkbar, daß Dir bei dem Goertzel-only-Programm was
>daneben gelaufen ist...


Bei MB kann man befehle komplett eleminieren indem man
REM davorsetzt. Genau das hab ich mit den Timing Funktionen
gemacht. Es gibt also kein Goertzel-only-Programm.



Eventuell findet Holger ja etwas heraus, wenn er Dein Executable
durch den Debugger scheucht.


>Ich glaube nicht, daß ausgerechnet dieses Vorgehen was mit dem Zeitproblem zu
>tun hat. Im Gegenteil, dieses Vorgehen ist zwingend notwendig.
>Hast Du ja an den Abstürzen merken können.

Da war noch so ein Extra While Wend das rausgenommen wurde.


>Hattest DU den dann auch mal getestet?

Nein, ich hab mein C-Compiler auf PPC eingestellt und weiss
überhaupt nicht mehr wie also kann ich das nicht rückgängig machen
(den 603e hab ich wegen fehlfunktion von der BPPC gelötet und
bis heute kein Ersatzprozi in QCF gefunden)

[ - Antworten - Zitieren - Direktlink - ]

26.09.2006, 13:11 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von MaikG:
Keine...
Aber erzeugte Programme lauffähig auf allen Prozessoren(68000-68040),
steht auf diesem Hefter dingels.
Abgesehen von einschränkungen von Peek bei 000 auf ungraden adressen.

Das heißt, es gibt keine FPU-Unterstützung. Das macht einen gewaltigen Unterschied beim Vergleich mit dem C-Programm. Denn da braucht man nur eine compiler-option, um deutlich höhere Geschwindigkeiten zu erzeugen.

Dein Zielsystem war allerdings 68030, wenn ich mich richtig erinnere. Mit FPU oder ohne?
Zitat:
Klar, aber ich hab deine Email adresse nicht...
Aber nicht mit diesem mitgelieferten Debugger, der crash auf 060.

Schick mir ne mail über's Forum... Dann bekomms Du meine Adresse mit der Antwort.

Der Debugger von HiSoft ist der gleiche wie beim DevPac-Assembler. Davon habe ich verschiedene Versionen und auch ein bisschen Erfahrung mit gemacht (muss mich nur wieder erinnern)... Das geht schon.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

26.09.2006, 18:12 Uhr

MaikG
Posts: 5172
Nutzer
>Das heißt, es gibt keine FPU-Unterstützung. Das macht einen
>gewaltigen Unterschied beim Vergleich mit dem C-Programm.
>Denn da braucht man nur eine compiler-option, um deutlich
>höhere Geschwindigkeiten zu erzeugen.


Ich möchte sagen die FPU wird durch die Math librarys unterstützt.
Aber wie schon gesagt goertzel währe zumindest auf 060 noch nicht
das Problem.

>Dein Zielsystem war allerdings 68030, wenn ich mich richtig
>erinnere. Mit FPU oder ohne?

Zufällig mit...

>Schick mir ne mail über's Forum... Dann bekomms Du meine Adresse mit
>der Antwort.

Okay, hab ich gemacht.

[ - Antworten - Zitieren - Direktlink - ]

27.09.2006, 21:09 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von MaikG:
Ich möchte sagen die FPU wird durch die Math librarys unterstützt.
Aber wie schon gesagt goertzel währe zumindest auf 060 noch nicht
das Problem.

Also für simple Operationen wie Addition und Multiplikation extra Library-Funktionen aufzurufen, ist keine wirkliche Unterstützung. Außerdem benutzen diese Bibliotheken nur dann ne FPU, wenn es sich um entsprechende Versionen handelt.

Aber wenn man sich so anguckt, was in den Binaries alles so enthalten ist, scheinbar der ganze Basic-Compiler und dann noch irgendein Floating-Point Code von Motorola von 1981, da kommt man schon in's grübeln.

Das einzige, was nicht enthalten ist, sind die Debugging-Informationen. Kannst Du noch mal die Compiler-Optionen überprüfen?

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

27.09.2006, 23:31 Uhr

MaikG
Posts: 5172
Nutzer
>Aber wenn man sich so anguckt, was in den Binaries alles so
>enthalten ist, scheinbar der ganze Basic-Compiler und dann noch
>irgendein Floating-Point Code von Motorola von 1981, da kommt man
>schon in's grübeln.

Ja, aber goertzel machts in 9,x sekunden ohne Timing. Also
wie schlecht der code auch immer sei auf 060 wäre das ausreichend.


>Das einzige, was nicht enthalten ist, sind die Debugging-Informationen.
>Kannst Du noch mal die Compiler-Optionen überprüfen?

In der DTMF1.debug ist nichts drin?
Die hat doch 5kB mehr als die DTMF1 und muss ja demnach
sowas enthalten...

[ - Antworten - Zitieren - Direktlink - ]

28.09.2006, 12:55 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von MaikG:
In der DTMF1.debug ist nichts drin?
Die hat doch 5kB mehr als die DTMF1 und muss ja demnach
sowas enthalten...

Symbole sind drin, aber keine Line-Debug Informationen. Aber in der neuen Datei sind sie drin, soweit ich das auf den ersten Blick erkennen kann. Werd sie heut abend mal in den Debugger stecken.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

29.09.2006, 09:50 Uhr

MaikG
Posts: 5172
Nutzer
>Symbole sind drin, aber keine Line-Debug Informationen. Aber
>in der neuen Datei sind sie drin, soweit ich das auf den ersten
>Blick erkennen kann.


Ja, wie gesagt manche Einstellungen aus dem Programm werden nicht
immer an den Compiler weitergegeben. Deswegen schreibe ich die
Optionen meinstens Inline, aber die Option für Debug kannte ich
noch nicht.

>Werd sie heut abend mal in den Debugger stecken.

Da bin ich mal gespannt was dabei rausgekommen ist...

[ - Antworten - Zitieren - Direktlink - ]

30.09.2006, 22:24 Uhr

MaikG
Posts: 5172
Nutzer
Holger?

[ - Antworten - Zitieren - Direktlink - ]

02.10.2006, 00:24 Uhr

Holger
Posts: 8116
Nutzer
Bisherige Erkenntnis ist nur, dass das von MaxonBasic erzeugte Programm der grauenhafteste code ist, der mir seit langem (bzw. überhaupt?) untergekommen ist.
Debuggen ist schwierig, weil selbst der debugger aus dem gleichen Haus seine Probleme mit dem code hat. Ganz abgesehen von der MaxonBasic-Eigenart, falsche Zeilennummern zu erzeugen. Was für Fehlermeldungen gilt, gilt halt auch für die Line-Debug Informationen. Da ist der Compiler konsequent.
Und es ist eigentlich ein Wunder, dass überhaupt eine benutzbare Geschwindigkeit herauskommt. Aber das timing-Problem erklärt es leider trotzdem nicht.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]


Erste 5 6 7 8 9 -10- 11 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Tonerkennung [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.