le son sur jaguar - Page 2

j'ai fait 2 versions, une en interruption en temps réel, et une avec buffers que je joue comme un sample, un sample crée chaque vbl dans le timer 1

la deuxième version était sensée m'aider à debugger mais au final elle buggait + que la version temps réel

par contre il faut vraiment que je creuse la réalité de la fréquence des timers , le nombre d'octets lus , etc, car là je trouve que c'est aigu ( alors que je calcule toutes les frequences en fonction de mes paramètres de timer I2S)

il faut que je puisse afficher mes compteurs sur la vraie jaguar donc là je creuse la doc sur l'object processor

pour l'instant j'ai la doc V8 + ce lien : https://www.mulle-kybernetik.com/jagdox/op.html
si vous avez de la doc sur l'OP je suis preneur bien sur.

PS : pour info le source actuel sans la gestion du sinus sid, qui est juste un canal de sample de plus à gérer, fait 3393 lignes...

j'aurais surement du commencer par cela, ça m'aurait faciliter la vie de voir un peu ce qui se passe dans mon replay:

Ca sonne super bien je me demande pourquoi on a jamais pu vouloir faire des chips son plus complexes
C'est quoi le morceau ?

[Édit] Le medley aussi il a des morceaux qui assurent

c'est le morceau nommé Buzzer de Mad Max

si vous voulez tester :

Fichier joint : ym1.abs

bonjour

sur un morceau j'ai un bug très sympathique, le SID dès le début déconne sur la voie A
sur l'emulateur russe, tout le temps
sur Virtual Jaguar : par ci par la, parfois c'est OK.
et si je démarre en debug, et que ça deconne , que je mets en pause, et que je relache la pause, ça se met à remarcher...

je vais ré-écrire cette partie là

je suis arrivé à un stade où je me dis que c'est une version 1.0 acceptable : https://github.com/ericde45/YM2149_JAG

j'ai remarqué que la stéréo droite et la stéréo gauche sont inversées entre Virtual Jaguar et Phoenix.
je n'ai pas vérifié lequel des 2 est juste.

Bravo

Pour la stéréo, je ne serais pas surpris qu'un des deux émulateurs inverse les canaux... il y a cette erreur dans certaines versions de la doc développeur et du fichier INC avec les constantes (ç'a été corrigé ensuite). Une autre possibilité, c'est que tu écrives trop tard dans les registres I²S dans ton interruption DSP (ça peut poser problème sur le vrai hardware aussi, tu peux te retrouver avec un sample de décalage entre le canal gauche et le canal droit. En stéréo l'effet est subtil, mais en mono ça fait un effet de filtre bizarre).

hello

je ne sais pas ce que tu appelles trop tard ?
l'interruption I2S est autorisée pendant l'interruption timer 1 ( les registres utilisés ne se chevauchent pas )
j'envoie les 2 canaux à la suite :

en stéréo :
movei #L_I2S,r26
store r25,(r26) ; write right channel
addq #4,R26
store r23,(r26) ; write left channel

en mono:
movei #32768,R27
...
movei #L_I2S,r26
sub R27,R20 ; resultat signé sur 16 bits
store r20,(r26) ; write right channel
addq #4,R26
store r20,(r26) ; write left channel

est ce juste ?

Bonjour,
Je n'ai pas la réponse a ta question mais, au cas ou, il y a quelques années j'avais porté sur Windows l'outil JWARN d'Atari.
Il permet de checker les "best practices" discuter dans la doc développeur ('Writing Fast GPU Programs').

bon j'ai modifié, je fais les 2 écritures à la chaine, en mono et en stéréo. paf !

bonjour

j'ai fait une première version d'un player de modules :

He be... Ca déchire Ca me fait pensé a du Jean-Michel Jarre.
Congratulations.

Superbe

Bravo, sans doute l'une des meilleures musiques produite par la Jaguar avec celle de Tempest2000 ! Tu nous rappelles la finalité de tout cela ? Une démonstration, un programme de développement, un jeu ?

Bien joué !

Elysium ? Je vois que tu as toujours bon goût en matière de musique

la finalité actuelle c'est m'amuser en codant des trucs sympas et mettre le code source à dispo
là je vais optimiser pour pouvoir augmenter la fréquence de replay, par challenge , car au delà de 30 Khz ça doit pas changer grand chose vu la fréquence d'origine des samples Amiga.
sur la jaguar réelle je suis à 46 Khz maxi actuellement.

et oui j'ai pris un module que je connais par coeur pour vite me rendre compte des défauts de replay. le player LSP est un peu tordu dans son fonctionnement ( et l'Amiga avec son dmacon aussi )

bonsoir

une petite question technique : est ce que l'un de vous connait la différence de vitesse en cycle entre une lecture par le gpu ou le dsp dans la ram centrale et dans la ram locale ?
que je vois si ça vaut le coup de me battre pour optimiser mon player de modules

Je te conseilles cette lecture
https://www.u-235.co.uk/gpu-in-main-science/

je viens de le lire, mais ça ne répond pas à ma question
il explique la différence de performance entre faire tourner le code GPU en le stockant dans la ram centrale par rapport à la ram locale
mais moi je veux juste la différence entre load venant de la ram centrale, et un load venant de la ram locale
ou alors je peux partir de sa situation + complexe et me dire que ça prend 10 fois plus de temps ?

Ça dépend de pas mal de choses : si l'accès est dans la même page mémoire que le précédent, s'il y a d'autres composants avec une priorité supérieure qui veulent accéder au même moment, ou un refresh de la RAM en cours, etc. Et sur le DSP la différence interne/externe est encore plus grande, vu qu'il n'a qu'une interface 16 bits avec l'extérieur.

SCPCD doit pouvoir te donner les timings exacts

En local, c'est 3 cycles :
1- Register read
2- Memory read
3- Write back to register

En externe, selon mon expérience sur le GPU, on peut dire qu'en moyenne on arrive à du 10-12cycles :
1- Register read
2- Memory gateway
3...N- Shared memory controller / DRAM controller / Shifter/Latch
N+1- Write back to register

J'ai jamais vraiment joué avec le DSP, mais sachant qu'il a un bus 16-bit et qu'il doit faire la demande à TOM de mettre à dispo les datas, c'est peut être plus long.
Néanmoins, je pense que c'est compensé en partie, du moins sur la moyenne, par le fait qu'il est le CPU ayant la plus haute priorité, donc peut-être tabler sur du 15-20cycles.

Sinon, ca peut être effectivement un peut plus rapide, comme ca peut être (beaucoup) plus long dépendant des activités sur le bus :
Typiquement si l'OP bouffe toute la bande passante pour traiter la liste (ce qui est pratiquement le cas sur la demo FActS), tu peux avoir jusqu'à 15360µs (64µs *240lignes) où tu peux bloquer ton GPU/DSP si ils tentent de faire un accès mémoire externe.
Du coup dans FActS, le DSP n'utilise que la ram interne (merci Zerosquare ! ), et le GPU n'accède au bus que sur les lignes non visibles.


Sinon, du fait que le GPU/DSP sont à architectures pipeline, ce que je fais c'est insérer le max d'instructions utiles entre le load et l'instruction qui va avoir besoin de la data lue.
Sur un accès mémoire interne tu peux en général facilement ajouter une instruction dans le slot2.
Sur un accès mémoire externe, c'est en général un peut plus compliquer car le delai étant très long, c'est pas simple d'avoir une 10ene d'instructions utiles qui n'a pas besoin de la donnée lue.
Dans mon optimisation du code pour le Plannar2Chunky (voir sur mon site les explications des optimisations), je me suis arrangé pour lire la donnée un coup en avance par rapport au calcul, du coup je perds une 10ene de cycles au démarrage, mais je ne perds plus de cycles sur les autres boucles.

hello,

merci de ta réponse
j'avais lu ton explication de la création de Facts sur ton site, c'est super intéressant. et il faut vraiment prendre le temps de comprendre chaque phrase pour en saisir la complexité.

j'ai fait une version où je stocke 4 octets par voie et où je joue donc ces 4 octets avant d'aller chercher un autre long word
je tourne à 51941Hz en replay en pal
je vois pas trop où optimiser

si je lis plus d'octets d'un coup, comme c'est sur la même bank de ram centrale, je suppose que ça me coutera moins de temps que de lire plusieurs fois 4 octets ? même si ça fait le même nombre de load au final ?

sur atariage un dev de jeu avait indiqué faire du 50 Khz en replay musique sur val d'isere, hors jeu, sur l'écran titre par exemple ( je ne retrouve plus le sujet, je ne me souviens plus du nom du dev)
il avait quand même bien chiadé son replay module
( parce que là moi je joue du LSP donc c'est un streaming des registres Amiga, y a pas le vrai replay protracker avec tous les effers à décoder )

et un conseil en passant : il faut vraiment mettre à zéro les zones mémoire qu'on utilise sur la vraie console. sinon c'est l'enfer de voir où ca déconne. sur les émulateurs ça passe nickel, la ram est à zéro par défaut.
bss, pile/stack et object list.

Alors, c'est vrai que j'en ai pas parler, mais en principe, il y a un mécanisme de "burst" (appellation personnel) qui existe dans le sens où tu peux faire 2 accès mémoire (load ou store) consécutif avant que le contrôleur mémoire du DSP/GPU ne mette l'unité d'exécution en pause pour cause de congestion du contrôleur mémoire sur un nouvel accès.
Autant je dirais que c'est sans risque sur le GPU (et je l'utilise), autant j'aurais tendance à éviter sur le DSP du fait de son bus 16-bit et du potentiel bug d'accès mémoire du DSP.

bon j'ai promené le chien et j'ai réfléchi
est ce que ça serait viable de copier des morceaux de samples au blitter pour les lire ensuite au DSP ?
actuellement j'ai 5860 octets dispos sur le DSP
donc je pourrais avoir 4 buffers de 1024 octets, 2x512 par voie
et en lire un et remplir si nécessaire l'autre dans la vbl en utilisant le blitter, et sans attendre qu'il ait fini sauf si je dois relancer une autre copie pour une autre voie
est ce que ce sera plus rapide que un load executé par le DSP ?

avec un module qui n'utilise que peu d'espace pour les samples, donc où je peux mettre les samples en ram DSP, je monte à 83 KHz

Le blitter peut probablement accélérer les choses, mais ça pose un problème : si tu l'utilises pour ton player de modules, alors il n'est plus dispo pour le reste du code, en particulier pour accélérer les opérations graphiques. C'est une grosse contrainte, en particulier si tu veux que d'autres personnes puissent utiliser ton code dans leur jeu (ou alors il faut supporter un mode avec blitter, et un mode sans).

Pour ce qui est d'avoir un cache d'échantillons dans le DSP, j'avais eu la même idée mais je ne suis pas convaincu que ce soit vraiment intéressant : pour que ça vaille le coup, il faut que tu réutilises plusieurs fois les données en cache. Or il n'y a que très peu de RAM locale, donc à moins d'avoir un module avec des instruments très petits, je pense que tu n'arriveras pas à garder les données en cache suffisamment longtemps pour profiter du boost de perfs. Pour moi, il vaut mieux utiliser la RAM dispo dans le DSP pour maximiser la taille des buffers de sortie (histoire d'avoir de la réserve au cas où le bus n'est pas dispo pendant un moment).

J'ai pas testé cependant, c'est juste une réflexion "de tête".

(sinon, comme répondu sur AtariAge : pas sûr que faire 2 loads d'affilée au DSP vaille le coup, je pense que le premier va retarder l'exécution du second, et que du coup tu perdras des cycles inutilement. Mais c'est à tester.)

l'utilisation de buffers pour moi c'était forcément avec le blitter, des buffers dynamiques remplis par le timer 1 qui gère le replay. et entièrement d'accord sur l'utilisation du blitter, difficile de le dédier au son.
déjà en stockant 4 octets de samples je réutilise, puisqu'a 50 Khz, je lis plusieurs le même octet, la fréquence des samples Amiga est souvent beaucoup plus faible
par exemple pour un module , LSP m'indique :

Instrument # 1: max replay rate = 16574Hz
Instrument # 3: max replay rate = 23334Hz
Warning: Instrument #3 only use 13459 sample bytes (len=24576)
Instrument # 4: max replay rate = 27928Hz
Instrument # 5: max replay rate = 20864Hz
Instrument # 6: max replay rate = 22168Hz
Instrument # 7: max replay rate = 22168Hz
Instrument # 8: max replay rate = 19704Hz
Instrument # 9: max replay rate = 28800Hz
Instrument #10: max replay rate = 28800Hz
Instrument #11: max replay rate = 14778Hz
Instrument #12: max replay rate = 22168Hz
Instrument #13: max replay rate = 11084Hz
Instrument #14: max replay rate = 9309Hz
Instrument #15: max replay rate = 28800Hz