MP3 Player für CPC mit LambdaSpeak III

[TFM]

Der LambdaSpeak III mit MP3 Modul kann ganz einfach MP3s und VOCs abspielen.

Hier eine erste Version eines MP3 Players. Die Daten befinden sich auf Megaupload, da es sich inclusive einiger Demo-Lieder um etwas 432 MB handelt.

Download:
https://mega.nz/#!Sxcj3aAR!9ZKUidqZJQZJaMFczbLhTS0Aja8LnWoDhNATX1Ce3gk

Die Daten im Archiv haben ein Passwort, es lautet "Lambda"

Bei Fragen stehe ich gerne zur Verfügung.

[LambdaMikel]

Super Sache und gute Musikauswahl!  Was ist denn VOC?

[TFM]

Super Sache und gute Musikauswahl!  Was ist denn VOC?

VOC ist so wie beim Digiblaster, direkte Positionsdaten des Lautsprechers, unkomprimiert. Also praktisch ein Sample. Verbraucht also viel mehr Speicher als ein MP3. Aber das Catalex Modul kann es eben auch abspielen (weniger Arbeit als MP3 die Dekodierung).

[LambdaMikel]

Ja, funktioniert ganz gut, aber leider hakt es ab und zu... ist wohl der Serial Mode... wenn ich nur wüsste, wie man das Umschalten verbessern könnte. Leider hilft da wohl nur längeres Warten. Mit v53 scheint es nicht besser geworden zu sein. Leider.

[Rennert]

Hab heut auch mal den MP3 Player probiert.
Funktioniert ganz gut, nur das Titel springen mit den Cursortasten funzt nicht immer zuverlässig an KCC. Also ich drücke den Titel weiter und es erscheint auch der nächste Titel am Bildschirm, aber der vorherige spielt weiter. Ist bei zurück genauso.

[Rennert]

Manchmal geht auch der Ton weg, also läuft stumm weiter.
Mache dann den nächsten Titel und ich höre wieder was.
Werde das mal mit RSX testen ob das da auch so ist.

[TFM]

Manchmal geht auch der Ton weg, also läuft stumm weiter.
Mache dann den nächsten Titel und ich höre wieder was.
Werde das mal mit RSX testen ob das da auch so ist.

Ja, da ist noch irgendwo ein Problem, konnte es noch nicht fingen.

[LambdaMikel]

Die RSX-Befehle habe manchmal auch kleinere Aussetzer... das scheint nicht genügend Wartezeit zwischen Umschalten der Modi und nach dem Senden des Flush Buffer Commands zu sein. Ein paar Millisekunden sollten reichen, denn unter "reinem BASIC" ohne RSX Commands funktioniert es recht zuverlässig - einfach weil BASIC (ohne RSX Commands) lahm ist.

[Rennert]

Per RSX duddelt es seit Stunden vor sich hin.

[TFM]

Die RSX-Befehle habe manchmal auch kleinere Aussetzer... das scheint nicht genügend Wartezeit zwischen Umschalten der Modi und nach dem Senden des Flush Buffer Commands zu sein. Ein paar Millisekunden sollten reichen, denn unter "reinem BASIC" ohne RSX Commands funktioniert es recht zuverlässig - einfach weil BASIC (ohne RSX Commands) lahm ist.

Schön, wenn das in BASIC so gut tut, dann sage mir bitte mal wie viel ms ich wann und wo warten muss. Das würde mir entscheidend weiterhelfen. 

Per RSX duddelt es seit Stunden vor sich hin.

Klar, der RSX Befehl sagt der MP3 Karte einmal was er tun soll, dann tut er es eben. z.B. !MP3PLAYF,folder-nummer.

Beim MP3-Player (also der Software) hingegen, wird für jedes Lied ein RSX abgeschickt. Das funktioniert dann oder eben in seltenen Fällen nicht. Und das liegt daran, dass sich wohl irgendwo im Timing ab und zu etwas ändert, aber ich weiß nicht wann und wo. 

[LambdaMikel]

Ich denke, es liegt am Umschalten der Modi... zwischen Uhrzeit abfragen und Serial Mode. Du hast ja schon FRAME Commands zum warten... u.U. mal verdoppeln.

Hattest Du einmal ausprobiert, wie schnell man Daten zuverlässig senden kann? Im Serial Mode:

Code: [Auswählen]

10 out &fbee,255: out &fbee, 55: ' echo test mode
20 a=round(Rnd(1) * 255)
25 if a = &10 to 20
30 wait &fbee, &10
40 out &fbee, a
50 b=inp(&fbee)
60 if a<>b then print "error!"
70 wait &fbee, &10
80 goto 20


... und das natürlich in MC... damit kriegt man raus, wie schnell man Daten absenden kann. Da Einlesen von "a" in 40 führt intern zum Umschalten von Serial zu Epson (weil man im Serial MOdus keine Daten vom CPC Empfangen kann).

Und dann würde ich noch sicherstellen:
- vor und nach flush mindestens 10 ms warten
- vor und nach entry / exit aus dem Serial Mode mindestens 50 ms warten
- vor und nach Änderen von Serial Mode Baudrate, Parity, Bits o.ä. mindestens 50 ms warten.

Das solle dicke reichen.

[LambdaMikel]

PS Das BASIC oben ist nur zu Illustration... tatsächlich erscheint der Wert für  b = inp(&fbee) nur so kurz, dass BASIC das gar nicht mitkriegt... also immer 16. In MC sollte man den Wert allerdings erwischen können (bevor er wieder auf &10 springt).

[TFM]

Nein, weil ich keine Möglichkeit habe zu sehen, ob die auch ankommen. Das ginge _vielleicht_ mit "jedesmal CPC & LS aus und einschalten". Aber nach dem Einschalten ist eh alles anders. Beim 2. Kommando läuft alles besser & schneller.

Da ich ab morgen einen neuen Job habe fehlt mir jetzt auch die Zeit mich da Tage-lang hinzusetzen. Ist es nicht möglich das auszurechnen indem man die Firmware anschaut?

PS Das BASIC oben ist nur zu Illustration... tatsächlich erscheint der Wert für  b = inp(&fbee) nur so kurz, dass BASIC das gar nicht mitkriegt... also immer 16. In MC sollte man den Wert allerdings erwischen können (bevor er wieder auf &10 springt).

BASIC und MC zu Vergleichen macht IMHO keinen Sinn.

[LambdaMikel]

Viel Glück mit dem neuen Job morgen!   
Alles andere ist erstmal unwichtig.

Das ist nicht zum Vergleichen, sondern um den MC-Algorithmus für den Test zu skizzieren... wie gesagt, es geht nicht in BASIC.

Mit Ausrechnen ist leider nicht, da es sich um unterschiedliche 'autonome Komponenten' handelt die ihren eigenen (nicht-synchronen) Takt haben, und die Reaktions-Geschwindigkeit vom MP3-Modul variiert auch.

Man muss die Wartezeit ja auch nicht genau kennen - die Tastsache dass es in BASIC zuverlässig funktioniert reicht schon um eine (wenn auch langsame) "untere Grenze" zu kennen.

Ich weiß, Wartezeiten sind Dir ein Greuel (zumal so lange), aber so ist es nun mal.

Also - ab ins Bett und nicht mehr dran denken!! Morgen ist wichtig! 

PS. Ich hatte mal die Zeit gemessen, die ich brauche, um zuverlässig nach Flush (&2) aus dem Serial Mode mittels Exit (&20) aussteigen zu können... und bin auf 120 NOPs gekommen. Ganz schön übel!

[TFM]

Äh... meinst Du &FF, &14 ? (Exit serial Mode) ?