[Exelvision] Nouvel émulateur EXL100

[gilles]

Mise en ligne de la version 0.7, synthèse vocale pour la version Allegro.
Le rendu dépend de la machine, pour le moment chaque trame de 200 échantillons est un sample individuel, ca marche assez bien sur les cartes sonores qui acceptent les samples courts... mais ce n'est pas idéal car il y a des trous ou de la superposition... Pour sonner mieux, l'émulateur devrait se synchroniser sur les samples gérés en stream... un fichier 8bits non signé à 10KHz est généré : out.raw, il donne un apercu de ce que serait le son avec une synchro correcte.

[gilles]

Il faudrait que je vois le code exact et que je joue un peu avec le debugger pour comprendre... qu'il ne sorte pas de son est assez étrange... il faudrait voir dans les traces si les données ont été envoyées vers le TMS5220.
Je sais que le format WAV est assez contraignant pour bosser, c'est pour ca que je privilégie le format ROM. Pour bosser quand même en WAV, il suffit de passer dans les options et passer en vitesse maxi pendant le chargement, sur une machine récente le temps de chargement est assez raisonnable.
Pour Daniel, en fait il est possible de faire mieux que l'exl dans la gestion des chaines LPC, il est possible d'envoyer directement toute la chaine et calculer le sample alors que sur la machine réélle, le 7041 risque d'être occupé, et de ne pas charger les données assez vite et stopper le son. Pour ma part je triche un peu avec un buffer de 24 octets (identique à celui géré par le 7041) alors qu'il y a en réalité 2 niveaux de buffer (24 dans le 7041 et 16 dans le TMS5220)

[jester]

Voici l'archive avec le code test : format wav, K7, et les sources.

Après vérification à l'oreille, ton émulateur reproduit presque le comportement de la vraie machine : une note, puis le début de la seconde et plantage comme sur Exl100.

Je ne suis pas un gros pro de l'assembleur, j'ai surement fait une grosse boulette que je ne vois pas ?

PS: Attention les sources et le fichier Wav sont différents, j'avais bricolé un autre test foireux, donc les sources ne produisent rien de bon. Le fichier Wav est basé sur la méthode ci-dessus (ja regarde si le pointeur R7/R8 est supérieur à la fin de la chaine LPC).

[OlivierP]

Voici le son avec SDL ainsi que le binaire mac : http://dl.free.fr/vQTmAZgGt
Je te laisse regarder et faire le binaire windows.
Il y a 4 fichiers modifiés : audio/speech.c, config.h, mem/memory.c, wxRenderLoop.cpp
Utilise WinMerge en ignorant les espaces pour comparer.

[gilles]

j'utilise winmerge depuis pas mal de temps. sinon araxis merge est encore mieux, mais payant...

[gilles]

j'ai testé ce matin (mise en ligne ce soir). Le timer de la version wx pose visiblement encore plus de problèmes que celui d'allegro (du moins sur ma machine winxp) et les pauses entre 2 samples sont très longues, ça parle quand même de manière compréhensible mais il va falloir trouver un moyen de ne faire la synchro que sur le sample pour que ça sonne bien...

[OlivierP]

Quelques optimisations (sources et binaire Mac) : http://dl.free.fr/gTaoXFvck

[gilles]

sur winXP j'ai tenté avec 20, puis avec 10 pour le timer mais sans différence notable, la doc précise bien que le timer peut être faux à +-10 millisec ce qui est un peu trop pour cette tache.
Est il par contre possible de notifier un update à la fin d'un callback du sample? dans ce cas il faudra réécrire exl_loop pour s'aligner sur la durée d'un sample.

[OlivierP]

Utilisation de plusieurs buffers pour le son : http://dl.free.fr/teFCh30vY
J'ai laissé le fichier sound.log, est-ce que tu as comme moi ?

[jvernet]

Utilisation de plusieurs buffers pour le son : http://dl.free.fr/teFCh30vY
J'ai laissé le fichier sound.log, est-ce que tu as comme moi ?

Y'a un truc bizarre. Je n'arrive pas à ouvrir de ROM dans la boite de dialogue: j'ai pas le focus souris dessus. Il faut utiliser le clavier. L'usage CPU ne change pas grand chose. Et y'a du son !

Un projet XCode et un CVS uptodate avec cette branche, ça serait cool. Je coince sur un truc que je n'arrive pas à voir, pour le projet XCode, mais j'ai pas planché bcp dessus.

Et le Make me donne ça:

Code : Tout sélectionner

g++ -o tmp/wxExl100 tmp/7000dasm.o tmp/tms7000.o tmp/mem_explorer.o tmp/trace.o tmp/timer.o tmp/memory.o tmp/io_cpu.o tmp/tms3556.o tmp/speech.o tmp/DebugFrame.o tmp/wxRenderLoop.o `wx-config --libs std` -I/Library/Frameworks/SDL.framework/Headers SDLmain.m -framework SDL -framework Cocoa 
ld: warning: in tmp/7000dasm.o, missing required architecture x86_64 in file
ld: warning: in tmp/tms7000.o, missing required architecture x86_64 in file
ld: warning: in tmp/mem_explorer.o, missing required architecture x86_64 in file
ld: warning: in tmp/trace.o, missing required architecture x86_64 in file
ld: warning: in tmp/timer.o, missing required architecture x86_64 in file
ld: warning: in tmp/memory.o, missing required architecture x86_64 in file
ld: warning: in tmp/io_cpu.o, missing required architecture x86_64 in file
ld: warning: in tmp/tms3556.o, missing required architecture x86_64 in file
ld: warning: in tmp/speech.o, missing required architecture x86_64 in file
ld: warning: in tmp/DebugFrame.o, missing required architecture x86_64 in file
ld: warning: in tmp/wxRenderLoop.o, missing required architecture x86_64 in file
ld: warning: in /System/Library/Frameworks//QuickTime.framework/QuickTime, missing required architecture x86_64 in file
ld: warning: in /usr/lib/libwx_macud-2.8.dylib, missing required architecture x86_64 in file
Undefined symbols:
  "_SDL_main", referenced from:
      -[SDLMain applicationDidFinishLaunching:] in cci8wp0Y.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [wxExl100] Error 1

[OlivierP]

Je n'ai pas mis de -arch x86_64 dans le Makefile, pourquoi est-ce utilisé chez toi ? est-ce dû à ta compilation de wxWidgets ? est-ce que tu utilise le wxWidgets fourni avec Mac OS X ou est-ce une version plus récente ?

L'idéal serait de compiler wxWidgets depuis les sources, avec au moins les paramètres suivants :
./configure --enable-universal_binary --disable-shared --enable-debug=no --enable-debug_flag=no --enable-debug_info=no --enable-debug_gdb=no --enable-stl=no --enable-unicode=yes --enable-compat26=no

Il faut aussi télécharger http://www.libsdl.org/release/SDL-1.2.13.dmg, l'ouvrir puis copier "SDL.framework" dans "/Library/Frameworks".

EDIT : pour la souris, je n'ai pas ce problème (sous Leopard 10.5.8).
pour XCode, je ne l'utilise généralement que comme éditeur de texte, je préfère tout automatiser dans un Makefile (question d'habitude, j'ai appris le C sous Linux et Unix).

[gilles]

je vais tester cette version, mais je suis aussi en train de modifier la structure de la gestion du son et le boucle principale pour pouvoir exécuter une durée donnée de cycle (qui correspondra à la durée entre 2 callbacks audio). Le point un peu critique est de resynchroniser tout sur le son. Le principe sera le suivant.
Timer interne de 1/SPEECH_FREQ pour 199 digits.
au 200ieme mise en buffer puis attente du callback de son.
lors du callback de son, on continue d'executer assez de cycles proc pour arriver à une durée de 200*SPEECH_FREQ.
Je vais commencer par allegro avec l'utilisation des routines de streaming de son et essayer de conserver aussi l'autre mode de fonctionnement (qui sera plus pratique pour le debugger par exemple).
Cela ne modifiera pas trop le timing qui passe à 40 boucles par secondes, donc pas besoin d'un second timer pour redecouper les périodes...
Si ca marche bien... j'adapterai pour mon emu TO8

[OlivierP]

J'ai fait plusieurs buffers pour pouvoir remplir un (ou plusieurs) buffer(s) pendant que le callback joue le (ou les) buffer(s) précédents. D'après le sound.log, il y a deux buffers remplis, puis deux buffers joués, etc.... Ainsi, il n'y a pas a attendre de callback du son et le rendu est fluide.

[gilles]

je vais intégrer les modifs pour voir (ou écouter en fait), le fait de repasser à 25 images au lieu de 50 permet de regagner un peu de précision sur le wxtimer mais il va fatalement nous embeter par la suite. On peut assimiler le son du TMS5220 a du son digitalisé, or pour être synchro il vaut mieux synchroniser sur le son ou au moins que la différence entre le son et le timer de base ne dépasse pas certaines limites.

[jvernet]

Je n'ai pas mis de -arch x86_64 dans le Makefile, pourquoi est-ce utilisé chez toi ? est-ce dû à ta compilation de wxWidgets ? est-ce que tu utilise le wxWidgets fourni avec Mac OS X ou est-ce une version plus récente ?

wxWidget 2.8.8 livré avec Snow Leopard, SDL est une build perso. Je ne sais pas pourquoi il veut passer en x86_64 alors que ce n'est pas explicitement demandé.