Faire du SOn sur Jaguar - Page 1

Salut à tous.
C'est un peu mort ici.
Bon, j'aurai pu aller sur Atariage mais coser en anglois ça me fatigue, me prend du temps, et je ne suis pas sûr de bien me faire comprendre...
Et puis ça mettra un peu d'animation ici.

Ma question est simple: comment fait on du son sur Jaguar au juste. A noter que ma question est juste par curiosité.
Je m'explique. Dans les différentes documentations ou codes sources, les informations à ce sujet sont contradictoires !
Un coup ils parlent de PWM DAC 14 bit, une autre fois c'est des DACs 16bit... Sans compter les adresses qui se mélangent avec les DACs 16bit qui se retrouvent à la même adresse que l'I²S...
Dans les sources de SDK pas mieux, puisqu'on peut y voir qu'ils donnent en exemple l'utilisation des DACs 16bit... mais ils disent de ne pas utiliser cette méthode car de toute façon ils n'existeront plus dans le futur....
Dans les source de Cybermorph, ils parlent d'utiliser le PWM ou l'I²S mais rien sur les DACs 16bit.

Alors quoi ?

Merci

Edit : ah flute, j'aurai du mettre ça dans la section "help"...

Les DACs PWM sont bugués, et ne sont de toute façon reliés à rien dans la Jaguar, tu peux oublier toute la section de la doc qui en parle.

Pour faire du son il faut utiliser l'I²S. C'est très basique :

- au démarrage, tu règles la fréquence d'échantillonnage avec SCLK et le format avec SMODE, tu désactives le mute dans le registre JOYSTICK, et tu actives l'interruption I²S avec D_FLAGS.

- à chaque période d'échantillonnage, l'interruption DSP I²S est déclenchée. Il suffit d'écrire le sample 16 bits à sortir sur le canal gauche dans L_I2S, et idem pour le canal droit avec R_I2S. Pas de FIFO, de DMA ou d'autre truc similaire, c'est brut de fonderie.

Si tu n'as pas envie de réinventer la roue, il y a plusieurs moteurs audio déjà faits :

- le lecteur de fichiers MOD à 4 canaux de Sinister Developments, historiquement le premier mais plus vraiment recommandé (la qualité est perfectible)

- celui de SebRmv, à 8 canaux

- celui de U235, à 8 canaux également

- le mien, à 4 canaux. Un peu différent des autres puisqu'il ne supporte que les samples sans changement de fréquence ou de volume, mais avec des bonus par rapport aux autres (samples au format muLaw, interpolation linéaire, mixage à 46 kHz au lieu de ~22 kHz)

ah merci, je n'en demandais pas tant

Ma seule interrogation était en fait sur l'adresse des registres à utiliser à cause de la confusion induite dans les différentes docs et sources.

Je savais déjà que les DACs PWM n'étaient pas connectés, mais j'ai fini par avoir un doute à force de toutes ces informations contradictoire.
D'ailleurs, si ils ne sont pas connectés, comment savoir qu'ils sont bugués ?

Ensuite, l'adresse des DACs 16bit est donc la même que les registres de transmission de l'I²S (F1A148 et F114C de mémoire je crois) ? Je ne comprend pas trop comment fonctionne l'I²S alors.... cela veut dire qu'on ne peut pas se servir de l'interface série synchrone quand on fait du son ? Et comment décider de telle ou telle fonctionnalité ?

DEATH (./3) :
Ma seule interrogation était en fait sur l'adresse des registres à utiliser à cause de la confusion induite dans les différentes docs et sources.

Et encore, dans les anciennes versions de la doc et des fichiers d'include, ils ont inversé le canal gauche et le canal droit

DEATH (./3) :
Je savais déjà que les DACs PWM n'étaient pas connectés, mais j'ai fini par avoir un doute à force de toutes ces informations contradictoire.
D'ailleurs, si ils ne sont pas connectés, comment savoir qu'ils sont bugués ?

Parce que c'est marqué dans la doc.
Quand une doc Atari te dit qu'un machin fonctionne, il n'est pas impossible que ce soit bugué ; quand la doc te dit que c'est bugué, il y a de très fortes chances que ça ne marche pas

DEATH (./3) :
Ensuite, l'adresse des DACs 16bit est donc la même que les registres de transmission de l'I²S (F1A148 et F114C de mémoire je crois) ? Je ne comprend pas trop comment fonctionne l'I²S alors.... cela veut dire qu'on ne peut pas se servir de l'interface série synchrone quand on fait du son ? Et comment décider de telle ou telle fonctionnalité ?

Oui, les DACs sont connectés à l'interface série synchrone, donc on ne peut pas faire fonctionner les deux indépendamment en même temps. C'est pour ça qu'il y a un bit de mute, pour éviter que ça fasse du bruit quand on utilise l'interface série synchrone pour transférer des données non audio. C'est détaillé ici :


En pratique ce n'est pas un problème : à moins que tu utilises le JagCD, il n'y a que les DACs qui utilisent l'interface série synchrone (à ne pas confondre avec l'interface série asynchrone, qui sert pour relier les Jaguars en réseau).

AH OUI ! Bien vu le Technical Reference !

Je suis "tellement" toujours plongé uniquement sur le Software reference que j'en avais totalement oublié le reste !

Ah ben oui la du coup je comprends mieux.

Petite question qui n'a pas trop à voir avec le sujet (quoique), pour m'amuser je voulais récupérer les échantillons de cybermorph qu'il y a dans les sources (en fait surtout : Where did you learn to fly . Mais impossible de trouver en quel format ils sont... J'arrive à entendre un peu quelque chose en choisissant certains format mais c'est quasi inaudible. En regardant les fichiers binaire, les données ont l'air très étrange...
Quelqu'un... sais tu quel format c'est ?

Et autre question, où peut on trouver ton moteur audio ?

DEATH (./5) :
Petite question qui n'a pas trop à voir avec le sujet (quoique), pour m'amuser je voulais récupérer les échantillons de cybermorph qu'il y a dans les sources (en fait surtout : Where did you learn to fly

Tu dois être le seul possesseur de Jaguar qui n'en ait pas marre de ce son

DEATH (./5) :
Mais impossible de trouver en quel format ils sont... J'arrive à entendre un peu quelque chose en choisissant certains format mais c'est quasi inaudible. En regardant les fichiers binaire, les données ont l'air très étrange...
Quelqu'un... sais tu quel format c'est ?

Le fichier WDYLTF.BYN du dossier SAMPLES est au format assembleur (avec des dc.w), j'ai pas pris le temps de l'assembler mais je suppose que ça donne ce qu'il y a dans la ROM.
En "écoutant" la ROM au format PCM 8 bits signé, on a bien les samples, mais il y a une distorsion bizarre. Je sais que le moteur audio d'Atari supporte un format où c'est la racine carrée (il me semble) de la valeur audio qui est stockée, c'est peut-être ça.

DEATH (./5) :
Et autre question, où peut on trouver ton moteur audio ?

Je ne l'ai pas vraiment diffusé directement vu qu'en gros il n'y a que Reboot qui était intéressé pour l'intégrer dans rB+.
Tu as les sources ici, mais c'est assez crade (c'était au départ juste un essai qui a pris de l'ampleur, et ça gère d'autres trucs qui n'ont pas de rapport avec l'audio, comme les manettes, les rotaries et les souris) :
http://www.mirari.fr/Glxo

Vue la diffusion limitée, je n'ai pas vraiment fait de doc en-dehors des commentaires dans les sources (regarde dans audio.s, le code 68k est celui de l'API, le "vrai" boulot est fait dans le DSP).
Tu peux aussi regarder la doc de rB+, vu qu'il reprend essentiellement les fonctions telles quelles : http://atariage.com/forums/topic/263346-rb-tutorial-3-rb-and-audio-untangling-a-mess/

Et encore oui ! En effet, c'est au format texte.... Quelle idée aussi...

Je n'avais vraiment pas pensé à regarder avec un éditeur de texte... Mais qui sauvegarde des échantillons sonores sous forme de sources ASM ???

bon, je vais essayer d'assembler ça avec un émulateur ST, je n'ai pas grand chose d'autre sous la main

Effectivement il y a une forte distorsion... Pas grave, je verrai plus tard... un jour...

Je ne voudrais pas abuser mais, comment le Jaguar CD, enfin plutôt la Jaguar fait pour lire des CD audio à 44100Hz ?
La fréquence de l'horloge de la Jaguar, même avec les différents diviseurs qu'elle possède, ne permet pas d'avoir exactement 44100Hz

C'est le Jaguar CD qui provoque une interruption à 44100Hz ? Comment ça se passe ?

Effectivement, les fréquences d'échantillonnage de la Jaguar sont des valeurs à la con (la grande spécialité d'Atari depuis le ST).

Dans le cas de la lecture d'un CD audio, le bit 0 de SMODE est à 0, et c'est le JagCD qui génère les signaux d'horloge à la place de Jerry pour avoir du 44100 Hz. Mis à part ça, ça fonctionne pareil.

Petit necrobump de la semaine

Au niveau du son, je m'amuse un peu avec JagStudio et les exemples de u235 et de ton driver @zerosquare (avec les exemples en C je précise, mais j'imagine que ça ne fait pas de différence).
Jusqu'ici j'ai réussi à faire jouer un de mes MOD avec u235 et un de mes mp3 avec ton driver... Il me semble que mon mp3 était bcp plus lent mais je ne sais pas si c'est à cause de l^échantillonage ou simplement parce que l'émulation ramait (j'ai testé à partir d'un vieux portable)

Mais j'ai pas mal de questions en fait, sachant que l'audio n'est vraiment pas mon domaine de programmation (je sais utiliser FMOD quoi ^^).
- Quelle transformation est appliquée au mp3, j'imagine que ce n'est pas un vrai player mp3 qui est implémenté dans ta lib ?
- Au niveau de la qualité, et au vu de ton expérience, qu'est ce qui donne le meilleur rendu entre toutes les solutions possibles (mod u235, mode zero, mp3 zero)
- Quelle est l'utilisation approximative des resources quand on joue une zik pendant le jeu ? J'imagine que tout se fait sur le CPU ? Quel est le meilleur compromis ?

Voila le dev jag c'est un peu la jungle quand on compare à ce quôn a sur Lynx finalement, mais jagstudio va dans le bon sens, y a juste la partie son qui reste assez obscure pour moi.

Merci

lordkraken (./10) :
Voila le dev jag c'est un peu la jungle quand on compare à ce qu'on a sur Lynx finalement.

Vu l'habitat naturel des bestioles, ce n'est pas étonnant

C'est vrai qu'il y a une certaine logique !

lordkraken > paradoxalement, je ne suis pas le mieux placé pour répondre à tes questions J'ai juste codé la bibliothèque audio de base (à la base, c'était un simple essai pour tester une idée) ; toute la partie intégration dans Raptor/rB+/Jagstudio et outils de conversion/build ont été faits par d'autres membres de Reboot, et je n'ai jamais regardé en détails comment ça fonctionnait.

Effectivement, le MP3 n'est pas supporté directement ; les formats supportés sont du 8 bits linéaire classique (signé ou non signé), et du 8 bits µLaw (non linéaire, la qualité audio est généralement meilleure à taille identique). J'imagine que le process de build inclut une étape qui convertit d'abord le MP3 en l'un de ces formats. Ton problème de vitesse de lecture est probablement lié au fait que les fréquences d'échantillonnage supportées que celles des MP3. Du coup je te recommande de rééchantillonner d'abord à une fréquence supportée avec un logiciel comme Audacity, et de sauvegarder au format WAV 16 bits non compressé.

Pour ce qui est du choix de la bibliothèque audio, je te renvoie aux posts de ggn et moi ici :

En résumé, la qualité n'est qu'un facteur : si la musique que tu veux utiliser a été composée avec un tracker (ou assimilé), c'est plus intéressant d'utiliser U235 par exemple.

Pour ce qui est de l'utilisation des ressources, j'avoue que j'ai jamais pris la peine de faire de benchmarks... vu que l'utilisateur principal est Cyrano Jones, et qu'il ne s'est jamais plaint des perfs
Et ça va beaucoup dépendre de la fréquence d'échantillonnage que tu choisis ainsi que du nombre de canaux à jouer en même temps. La limitation viendra de l'utilisation du bus qui est commun à tout (vidéo, audio, code), pas de l'utilisation CPU vu que l'audio est essentiellement gérée par le DSP. Comme c'est la vidéo qui a la priorité, si ta musique commence à sonner bizarrement quand il y a trop de trucs à l'écran, c'est que tu as poussé le bouchon trop loin.

En tout état de cause, pour de la musique streamée (en gros, le morceau est un seul gros sample audio), mon code n'est pas censé consommer plus de ressources qu'U235, tout en ayant une qualité audio supérieure à taille équivalente. Et pour les modules, comme il n'y a qu'U235 qui le fait, la question ne se pose pas - à moins de convertir à l'avance le module en fichier WAV, mais comme ça prend beaucoup plus de mémoire ça n'a pas vraiment de sens.

La meilleure solution pour voir ce qui fonctionne bien pour ton jeu, c'est encore de faire des essais

Merci pour ta répone ma foi plutôt exhaustive

Je vais aller voir le topic sur AA, puis je testerais un peu, genre en animant un max de sprite avec les 2 libs et mod/stream/nozik, voir un peu l'impact que ca a.

Avoir le support direct de C sur jagstudio change quand même pas mal la donne

Bonjour

je me greffe à ce sujet car une chose m'étonne sur Jaguar : en lisant des discussions sur les performances des players de modules Amiga, en gros jouer un module à 22 Khz est OK et semble transparent ou presque, alors que sur une situation sans animations, on peut monter à 50 Khz de replay
le proc DSP dédié au son tourne à 26.6 mhz, donc ça me semble largement suffisant pour mixer 4 voies à 50 Khz ?
où est la subtilité ?
est ce que le fait que ce soit sur interruption bouffe plein de temps CPU DSP ?
est ce qu'en fait on limite à 22Khz pour utiliser le DSP audio à faire autre chose en plus ?
car lire un module, qu'on le rejoue à 22 khz ou 50, ça ne génére pas plus de lecture dans la mémoire centrale.

( je m'interroge car je bosse sur le son de l'Archimedes et 1 module 8 voies sur Archimedes à 12 MHZ, ca prend ce temps là : et en 62 Khz 4 voies ça donne ça : )

j'avais fait un mixer son 4 voies dont une voie gère le codec IMADPCM
le seul soucis c'est que ça intégrait le code de gestion de l'adaptateur souris de Zerosquare et que si on enlevait ce code ça ne fonctionnais plus
j'ai jamais trouvé pourquoi, donc c'est peut être pas l'exemple le plus clean qui soit, mais si ça intéresse quelqu'un dite le moi
j'avais même inclus ce codec dans le lecteur Cinepak et modifié l'outil de conversion vidéo pour inclure le stream audio encodé, punaise quand j'y repense j'étais motivé à l'époque !

C'est pas un souci de puissance du DSP (il est rapide), c'est plutôt la bande passante de bus qui pose problème.

Le DSP n'a que 8 Ko de SRAM locale, c'est trop petit pour stocker les samples du module dans la majorité des cas. Donc il faut les mettre dans la DRAM globale, qui est sur le bus commun à tous les composants. Si tu considères un accès DRAM par canal mixé et par échantillon de sortie, ça veut dire deux fois plus de bande passante utilisée en mixant à 44 kHz plutôt qu'à 22 kHz. C'est pas négligeable quand tu as plein de trucs à l'écran qui ont aussi besoin de bande passante.

Après, on pourrait imaginer de gérer un cache dans le DSP pour limiter les accès mémoire en DRAM. Je ne sais pas si les players de module existant le font déjà ou pas.

On peut aussi tricher en mixant à 22 kHz et en convertissant le résultat en 44 kHz à la volée avec le DSP : ça ne rend pas aussi bien qu'un vrai mixage à 44 kHz, mais ça sonne déjà moins métallique que du 22 kHz brut, sans changer la consommation en bande passante.

merci de ta réponse

je pensais que le résultat mixé était calculé au fur et à mesure des interruptions et stocké dans la ram du DSP ou envoyé directement au DAC ?

C'est le cas, mais il faut bien aller chercher les samples des instruments du module, qui sont trop grands pour rentrer dans la SRAM du DSP (sauf si ton module ne fait que quelques Ko, mais avec ça tu ne fais pas grand-chose).

hum hum
mais la musique ça peut se faire sans samples, en plus y a des tables d'ondes dans le DSP de base j'ai lu.

actuellement sur Archimedes, je bosse sur le lien ci joint, et ça demande 16 octets par VBL, sauf si il y a des digidrums.
et encore c'est du YM donc streaming, un vrai format de player ( style Coso, maxYMiser, etc) demanderait moins je pense.

Si y'a pas de samples, j'appelle pas ça un module moi

Mais oui effectivement, si t'utilises pas de samples, tu peux tout mettre dans la mémoire locale du DSP et ne pas utiliser de bande passante. Il y a du code d'Atari qui fait de la synthèse FM, et il me semble quelqu'un avait fait un émulateur de YM2149.

(sinon bravo, tes exemples sonnent très proprement Le lecteur de YM manque un peu d'aiguës, mais très bon choix de morceau de démo )

Je ne peux répondre qu'une seule chose : ça dépend vraiment comment c'est codé.

Et la preuve la plus flagrante c'est Super Burnout, qui est certainement le jeu techniquement le plus abouti/complexe de la Jaguar, à mon avis.
Enfin, je peux me tromper je n'ai pas été le désassembler pour voir, mais vu comment il dépote et ce qui est dit des auteurs...

Et notamment au niveau du son, car d'après olivier Nallet (il me semble) le programmeur du jeu, le son du jeu est composé de quelques 16 voix (ou un truc du genre) à 25 hkz plus ou moins et dans les 50Khz quand elles sont jouées dans le menu.
Les chiffres sont approximatif car je ne me souviens plus très bien, mais c'est dans une des conversations sur la Jaguar sur Atariage (je ne le retrouve pas)
Et il faut compter avec ça entre autre les quelques 1000+ objets affichés en 60img/s
Le secret étant entre autre d'utiliser une zone de cache dans la RAM du DSP en chargeant un max d'échantillon en une fois.

Je crois que sur le même topics (en tout cas sur atariage aussi) un autre programmeurs explique qu'il avait fait un player capable de jouer quelques chose comme 24 voix en moult Khz, pareil en chargeant en cache un max d'échantillon, et en plus en le faisant pendant les "pauses" du processeur objet (typiquement, pendant le Vblank)

Il y a peut être aussi la possibilité d'utiliser des échantillons compressés pour réduire d'autant l'accès au BUS. je n'ai pas idée de la puissance du DSP pour faire de la décompression en temps réel avec cette méthode.

J'ai retrouvé le commentaire :
https://atariage.com/forums/topic/111887-super-burnout-hidden-jaglink-mode/?do=findComment&comment=1398780

D'après Olivier c'est donc 10 voix en 32Khz pendant le jeu, et 16 voix 50 Khz dans le menu

https://atariage.com/forums/topic/111887-super-burnout-hidden-jaglink-mode/?do=findComment&comment=1399401

https://atariage.com/forums/topic/111887-super-burnout-hidden-jaglink-mode/?do=findComment&comment=1399413

etc. etc.

Ici c'est la personne qui affirme avoir fait un player 24 voix : https://atariage.com/forums/topic/111887-super-burnout-hidden-jaglink-mode/?do=findComment&comment=1440439

DEATH (./21) :
Il y a peut être aussi la possibilité d'utiliser des échantillons compressés pour réduire d'autant l'accès au BUS. je n'ai pas idée de la puissance du DSP pour faire de la décompression en temps réel avec cette méthode.

Le A-Law/µ-Law est décompressable avec un impact très faible sur les perfs, je le supporte dans mon lecteur audio. L'ADPCM 4 bits a déjà été fait aussi (au moins dans certains des jeux d'Orion_).

Un des projets sur ma (très longue) todo-list est de tester des formats de compression audio plus évolués.

je suis pas assez ancien sur Jaguar pour vraiment juger mais entre dire et vraiment faire, je doute
24 voies a une frequence potable style 28 KHz comme l'Amiga ça me semble impossible
lire les octets en 1 fois ou plusieurs, je vois pas trop ce que ça change sur la conso de bande passante mémoire totale
donc franchement, je pense qu'il a oublié la réalité

je te donne un exemple

ecran titre de val d'isere, lancé sous phoenix, valeur de SCLK = $1B
( pratique le super debuggeur de phoenix )
calcul de la frequence de replay = 14 840,34598214286 KHz
26593900 / ((( $1B+1)*4)*16)

c'est la formule que j'utilise dans LSP donc je sais qu'elle fonctionne sinon le son serait désaccordé

donc le mec a simplement oublié et il peut confondre avec la playstation 1 ou une autre console de l'époque

même exercice sur Super Burnout : même valeur = $1B

et même exercice sous mon player audio dont le source est dispo en toute transparence sous github :
SCLK = $B sous phoenix
34 627,473 KHz

frequence affichée, recalculée et utilisée par le player pour les notes = 34623

autre exemple : FACTS, la démo de SCPCD avec musique de Zerosquare : SCLK sous phoenix = 8
26593900 / ((( 8+1)*4)*16) = 46 169,96527777778
fréquence annoncée dans le texte de la démo = 46 KHz

je ne sais pas, il faudrait demander à leur auteur.
Ils n'utilisent peut être pas non plus SCLK mais les JPIT.
Même s'il parait que ce n'est pas conseillé (je ne sais plus pourquoi) en tout cas ils le sont dans la documentation officielle et en plus ils offres une plus grande précision il me semble

Vu la qualité de restitution sonore de Super Burnout je serais quand même assez étonné que ce soit du 14Khz

Et sinon il me semble que le calcul de SCLK est plus simple que ça : SerialClock = MasterClock/(2*(SCLK+1))

les timers ne sont pas utilisés, j'ai vérifié ce matin quand j'ai regardé le SCLK
la routine DSP est hyper longue, d'un bloc, à partir de l'adresse +$10, les registres de pit sont vides

ma formule est juste, ça j'en suis sur.

un exemple de son application, toutes les notes sont calculées avec cette formule à la base :

Il y a quand même un problème avec cette exemple, bien qu'étant à priori à 34Khz la qualité sonore est bien inférieur à celle de Super Burnout, c'est très flagrant.

Autre chose, quel sont les paramètres exact de SMOD dans chaque cas ? Car sauf erreur cela fait varier la fréquence de l'interruption.