30

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.
avatar

31

SCLK c'est le nombre de bits par secondes en sortie vers le DAC.
donc pour avoir la fréquence d'échantillon audio il faut bien diviser par 32 (16bit par canal).

Utiliser JPIT avec une plus grande fréquence ou activer le mode interruption gauche+droite ne changera rien à la fréquence d'échantillonnage de sortie.
avatar

32

Bon, je viens d'essayer Super Burnout avec l'émulateur Phoenix en mode debug.
Je ne prétend pas du tout connaitre son fonctionnement exact (c'est la 1ère fois que je le lance en mode debug), mais les valeurs que je trouve semble cohérentes avec ce que dit Olivier NALLET

Tout d'abord le jeu semble bien utiliser les timers JPIT, aussi bien pour la fréquence d'échantillonnage que le tempo

En course, on trouve pour les valeurs
JPIT1 : $a63 (2659)
JPIT2 : $63 (99)

ce qui nous donne une fréquence de 26593900/2659/99 = ~100Hz
Tout à fait plausible pour un tempo

JPIT3 : $7
JPIT4 : $84 (132)

Ce qui nous donne une fréquence de 26593900/7/132 = ~28781Hz
pas loin donc des 30Khz annoncé

Dans le menu option musique :
JPIT1 : $109 (265)
JPIT2 : $3e7 (999)

Ce qui nous donne encore une fois 26593900/265/999=~100Hz

JPIT3 : $4
JPIT5 : $84 (132)

Ce qui nous donne cette fois 26593900/4/132=~50367Hz
Donc les 50Khz annoncé aussi

Alors ? Est ce que je me trompe ? Je ne regarde pas au bon endroit ? Je ne comprends pas les valeurs affichées ?
J'ai regardé les valeurs qui sont dans :
> Jerry
>RegBank
PIT10
PIT11
PIT20
PIT21

C'est bien ça non ?

En tout cas ça serait un sacré hasard que ça tombe sur ces valeurs.
avatar

33

Ah j'ai oublié d'ajouter 1 à chaque fois....
avatar

34

Bon ça donne des valeurs "relativement" semblable.

Toujours ~100Hz pour le tempo (même + précis en fait)
et environ 25Kz en course et 40Khz dans le menu
avatar

35

SCPCD (./31) :
SCLK c'est le nombre de bits par secondes en sortie vers le DAC.
donc pour avoir la fréquence d'échantillon audio il faut bien diviser par 32 (16bit par canal).


je peux me tromper, mais quand on utilise i2s pour l'échantillonnage, il me semble que c'est uniquement pour utiliser l'interruption générée.
Et à chaque interruption on viens charger R_DAC et L_DAC

La fréquence de l'interruption I2s ce calcul ainsi :
Horloge système / (2 * (SLCK+1))
Puis il faut tenir compte des "options" de SMOD
WSEN va diviser la fréquence de l'interruption par 16
RISING et FALLING vont encore ajouter une division par 2 chacun

Quand toutes les conditions sont remplis, l'interruption à lieu

Soit toute les ((26593900/(2*(SLCK+1))/16)/2 pour les valeurs les plus courantes qu'on peut voir dans certains jeux (WSEN et FALLING actif)

Vous pouvez faire le calcul avec les valeurs données par ericde45 vous obtiendrez exactement le même résultat.

Mais encore une fois, je peux me tromper.
avatar

36

Non, pour autant que je me souvienne, ça ne fonctionne pas comme ça :
- les échantillons sont envoyés au DAC bit-à-bit avec la période déterminée par la valeur de SCLK, quelle que soit la fréquence à laquelle tu écris dans LTXD et RTXD (ou même si tu n'y écris jamais d'ailleurs). Par conséquent c'est SCLK qui détermine la fréquence d'échantillonnage.
- WSEN de SMODE n'est pas un diviseur, c'est ce qui détermine si le signal de synchro gauche/droite est généré ou pas (le DAC en a besoin, donc ça ne marche pas si on le désactive)
- RISING, FALLING et EVERYWORD de SMODE ne sont pas vraiment des diviseurs non plus, ça détermine à quel moment(s) l'interruption I²S est déclenchée (quand l'état des compteurs internes correspond à la condition correspondante)

Bref aucun intérêt d'utiliser un timer plutôt que l'interruption I²S pour faire du son : au mieux ça n'apporte rien (et ça utilise un timer qui pourrait servir à autre chose), au pire ça apporte des ennuis (déphasage imprévisible si la période est la même que celle de SCLK, rééchantillonnage crade sinon). Si Super Burnout le fait effectivement, je ne vois vraiment pas pourquoi.

J'ai essayé de vérifier dans les netlists pour en avoir le cœur net (c'est dans I2S.NET) mais le code est assez spaghettique, et c'est difficilement lisible sans avoir la correspondance en tête entre le nom des blocs et leur fonction logique. C'est le genre de trucs à analyser à tête reposée (ou à sous-traiter à SCPCD tongue)
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

37

hello

alors en ouvrant la bonne rom c'est quand même mieux, mea culpa
pour val d'isere je maintiens ce que j'ai écrit
par contre pour super burnout je suis d'accord avec DEATH c'est du 50 KHZ, le replay est en Timer 2, il a R23=F1A14C et R25=F1A148 et il écrit dedans dès le début de chaque interruption timer 2
ce qui fait la qualité dans un replay de module c'est la qualité des samples d'origine
sans interpolation, a 50 KHZ tu rejoues toujours les memes octets si ton sample amiga est a 8 khz a l'origine
pour super burnout, reste a voir si c'est du module ou de la synthese d'instrument en temps réel
nous, nous somme limités parce qu'il faut une source de musique en fichier
un dev de jeu il a un musicien sous le coude à temps plein donc il peut synthetiser des instruments au DSP, les coller dans un outil de MAO et faire faire une musique sur mesure
et là, la qualité sera bien supérieur à un module Amiga
( en plus juger la qualité sur un replay youtube d'emulateur phoenix, heu.... )

et si quelqu'un est motivé pour tenter de porter Amigaklang sur Jaguar je suis partant.
avatar

38

Zerosquare (./36) :
Non, pour autant que je me souvienne, ça ne fonctionne pas comme ça :
- les échantillons sont envoyés au DAC bit-à-bit avec la période déterminée par la valeur de SCLK, quelle que soit la fréquence à laquelle tu écris dans LTXD et RTXD (ou même si tu n'y écris jamais d'ailleurs). Par conséquent c'est SCLK qui détermine la fréquence d'échantillonnage.
- WSEN de SMODE n'est pas un diviseur, c'est ce qui détermine si le signal de synchro gauche/droite est généré ou pas (le DAC en a besoin, donc ça ne marche pas si on le désactive)
- RISING, FALLING et EVERYWORD de SMODE ne sont pas vraiment des diviseurs non plus, ça détermine à quel moment(s) l'interruption I²S est déclenchée (quand l'état des compteurs internes correspond à la condition correspondante)

Bref aucun intérêt d'utiliser un timer plutôt que l'interruption I²S pour faire du son : au mieux ça n'apporte rien (et ça utilise un timer qui pourrait servir à autre chose), au pire ça apporte des ennuis (déphasage imprévisible si la période est la même que celle de SCLK, rééchantillonnage crade sinon). Si Super Burnout le fait effectivement, je ne vois vraiment pas pourquoi.

J'ai essayé de vérifier dans les netlists pour en avoir le cœur net (c'est dans I2S.NET) mais le code est assez spaghettique, et c'est difficilement lisible sans avoir la correspondance en tête entre le nom des blocs et leur fonction logique. C'est le genre de trucs à analyser à tête reposée (ou à sous-traiter à SCPCD tongue)
Ca fonctionne exactement comme tu dis.
avatar

39

Zerosquare (./36) :

Si Super Burnout le fait effectivement, je ne vois vraiment pas pourquoi.


Peut être parce que c'est indiqué dans la documentation qu'il faut faire comme ça smile

Mais tu es quand même d'accord pour dire que techniquement Super Burnout est un des jeux les plus abouti de la Jaguar.
Il fonctionne de façon impeccable, pas un truc de travers, en 60img/s dans toutes les situations, plusieurs 100aine d'objets à l'écran, et des objets.... "scaled" en plus (Putain c'est quoi le terme en français ?) un son impeccable et du coup avec une fréquence assez élevé (en fait pour le moment la plus élevé que j'ai vu sur Jaguar). Pour le nombre de voix difficile de vérifier....
Bref je crois qu'on ne peut pas lui reprocher d'avoir mal codé.

En tout cas ce n'est pas le seul à le faire comme ça, j'ai testé rapidement hier et il y avait aussi Atari Cart je crois qui utilisait JPIT pour la fréquence de replay
avatar

40

DEATH (./39) :
Peut être parce que c'est indiqué dans la documentation qu'il faut faire comme ça smile
Pour la sortie PWM DAC (car elle utilise justement les JPIT), mais pas pour la sortie I2S qui utilise SCLK. wink


En tout cas ce n'est pas le seul à le faire comme ça, j'ai testé rapidement hier et il y avait aussi Atari Cart je crois qui utilisait JPIT pour la fréquence de replay
Peut-être l'habitude d'utiliser des timers comme sur les autres archis ?
Ou portage ?

C'est une solution comme une autre : soit utiliser plusieurs timers, soit utiliser un seul timer avec des sous compteurs.
avatar

41

il y a meme un replay de module qui utilise un I2S a 20 KHZ et un timer 1 a frequence plus élevé, mais au final ca reste du 20 khz
je vous laisse chercher lequel, il n'y a pas le droit de le "reverse engenirer " smile
avatar

42

Par rapport à Super Burnout, c'est pas mal mais ça reste pas de la vraie 3D... je me demande si la Jag aurait pu avoir un Need for Speed comme sur 3DO. Pour moi y'a un fossé technique/generationnel entre les deux mais je peux me tromper.
avatar
MK !
Collectionneur, retrogamer.
Enfin, un peu moins maintenant.

43

SCPCD (./40) :
DEATH (./39) :
Peut être parce que c'est indiqué dans la documentation qu'il faut faire comme ça smile
Pour la sortie PWM DAC (car elle utilise justement les JPIT), mais pas pour la sortie I2S qui utilise SCLK. wink


En tout cas ce n'est pas le seul à le faire comme ça, j'ai testé rapidement hier et il y avait aussi Atari Cart je crois qui utilisait JPIT pour la fréquence de replay
Peut-être l'habitude d'utiliser des timers comme sur les autres archis ?
Ou portage ?

C'est une solution comme une autre : soit utiliser plusieurs timers, soit utiliser un seul timer avec des sous compteurs.

Dans la dernière documentation disponible les PWR DACs sont bien mentionnés mais uniquement à titre informatif, il est précisé que ça requière une électronique supplémentaire (sur la version actuelle de la Jaguar, c'est un euphémisme...) et si mes souvenir sont exact ils sont sur 14bit.

La il s'agit bien de DAC (pas PWR) 16bits comme mentionné plus loin dans la doc.

Je ne comprends pas pourquoi tu parles de 1 seul timer ou plusieurs. Pour la fréquence d'échantillonnage, qu'on utilise l'interruption I2s ou JPIT, il n'y a qu'un seul timer d'utilisé.

Pour ma part, la partie son n'ayant pas de DMA, la solution logiciel serait bien d'utiliser un JPIT avec une interruption la plus courte possible et un chargement des DACs dès le début.
Avec I2S ça fonctionne peut être très bien, mais on voit bien qua ça n'a pas été conçu pour.

Pour rappel c'est quand même la technique utilisée, entre autre, sur Atari ST (via le timer B généralement) et ça fonctionne très bien.
L'avantage sur la Jaguar c'est que le traitement des interruptions des RISC est instantané (ou quasi instantané, si tu peux confirmer), en tout cas incomparable avec celles du 68000, l'impact est donc très faible sur les performances
avatar

44

DEATH (./43) :
Je ne comprends pas pourquoi tu parles de 1 seul timer ou plusieurs. Pour la fréquence d'échantillonnage, qu'on utilise l'interruption I2s ou JPIT, il n'y a qu'un seul timer d'utilisé.
Justement : les 2 JPIT & l'I2S sont 3 lignes d'interruptions différentes et la seule ligne qui définie la fréquence d'échantillonnage effective est celle de l'I2S. smile


Pour rappel c'est quand même la technique utilisée, entre autre, sur Atari ST (via le timer B généralement) et ça fonctionne très bien.
Jamais fait de son sur ST, mais de ce que j'en comprend c'est plus proche d'un mécanisme comme aurait fait les PWMDAC de la jag (en moins brut de fonderie)
avatar

45

C'est ça.

Sur le STE, on a simplement un registre 8 bits (74F374) avec un DAC 8 bits parallèle (DAC0802) branché directement dessus. Il n'y a pas de broche d'horloge, la sortie est mise à jour quand on écrit dans le registre. On peut utiliser le contrôleur DMA pour transférer régulièrement des données dans le registre, mais il n'y a le choix qu'entre 4 fréquences, donc certains préfèrent utiliser un timer pour ça.

Sur la Jaguar c'est différent : c'est un DAC 16 bits série, qui a besoin d'un flux continu de données, d'une horloge et d'un signal de synchro gauche/droite. Une fois que le module I²S est initialisé, tout ça est géré automatiquement : la valeur de LTXD et RTXD est capturée une fois par cycle d'échantillonnage. Donc si tu utilises un timer plutôt que l'interruption I²S :
- si fréq. timer > fréq. I²S : il y a des échantillons qui sont ignorés
- si fréq. timer < fréq. I²S : il y a des échantillons qui sont utilisés deux fois (ou plus)
- si fréq. timer = fréq. I²S : ça marche, mais comme le déphasage I²S/timer est imprévisible, tu peux avoir une race condition entre l'écriture des registres audio et leur lecture

Bref autant utiliser l'interruption I²S : ça marche mieux et c'est fait exprès pour ça. Quant à savoir pourquoi certains jeux utilisent un timer... ils ont peut-être voulu faire comme ils avaient l'habitude sur les machines qu'ils connaissaient, ou pas bien compris la doc. C'est vrai que c'est pas forcément évident si on ne sait pas comment fonctionne l'électronique qu'il y a derrière. (Et puis si on commence à lister les jeux Jaguar qui font des trucs bizarres/douteux, on n'a pas fini grin)

Sinon, Super Burnout est techniquement très bon en effet smile
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

46

SCPCD (./44) :

Jamais fait de son sur ST, mais de ce que j'en comprend c'est plus proche d'un mécanisme comme aurait fait les PWMDAC de la jag (en moins brut de fonderie)

Je parle ici de son échantillonné, typiquement du PCM 8bit (je crois qu'on peut faire plus mais pareil.... j'ai un peu oublié tout ça).

Sur Atari STF il n'y a pas de DAC (ni de DMA pour le charger), on simule donc un DAC (et un DMA) en mettant les bonnes valeurs dans les 3 voix du YM2149 en se basant sur des tables de conversions prédéfinies et ce à intervalles réguliers grâce à l'interruption du timer B (historiquement le B mais je ne me rappelle plus s'il y a une raison technique) qui va lancer la routine qui chargera les valeurs dans le YM2149.
Et bien sur la fréquence du timer B correspond à la fréquence d'échantillonnage qu'on veut restituer.
L'inconvénient de cette technique c'est que ça bouffe un "max" de temps CPU. Imaginez à 15Khz (ce qui est déjà relativement élevé sur un STF), 15000 interruptions par seconde, quasi 1 par ligne. Et le traitement d'une interruption sur 68000 c'est beaauucoup de cycle, même si la routine elle même est très courte.

Sur STE il y a un DAC et un DMA pour le charger. Je n'ai d'ailleurs jamais entendu parler d'utiliser un timer en natif sur STE pour faire du son digitalisé, et pour cause, l'emploi du DMA son consomme.... 0 cycle CPU, et 0 cycle mémoire supplémentaire (le secret c'est l'entrelacement sur des accès mémoire qui n'était pas utilisés)

Et pour fini il y a aussi une autre technique appelé Digidrum qui consiste à n'utiliser qu'une seul voix du YM2149 pour les sons digitalisés et avec une fréquence très basse. Le rendu est alors très limité (quelques chose comme 4 ou 5 bits je ne sais plus) mais suffisant pour jouer des sons de percussion bien plus réalistes en plus de la musique "soundchip" sur 2 voix + le canal de bruit.
avatar

47

DEATH (./46) :
Je n'ai d'ailleurs jamais entendu parler d'utiliser un timer en natif sur STE pour faire du son digitalisé, et pour cause, l'emploi du DMA son consomme.... 0 cycle CPU, et 0 cycle mémoire supplémentaire (le secret c'est l'entrelacement sur des accès mémoire qui n'était pas utilisés)
Il me semble avoir lu quelque chose à ce sujet il y a... longtemps. Probablement utilisé dans une démo, ou dans un lecteur audio ?

Mais oui, ça m'avait déjà surpris à l'époque : on perd l'intérêt du DMA.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

48

Zerosquare (./45) :

Sur la Jaguar c'est différent : c'est un DAC 16 bits série, qui a besoin d'un flux continu de données, d'une horloge et d'un signal de synchro gauche/droite. Une fois que le module I²S est initialisé, tout ça est géré automatiquement : la valeur de LTXD et RTXD est capturée une fois par cycle d'échantillonnage. Donc si tu utilises un timer plutôt que l'interruption I²S :
- si fréq. timer > fréq. I²S : il y a des échantillons qui sont ignorés
- si fréq. timer < fréq. I²S : il y a des échantillons qui sont utilisés deux fois (ou plus)
- si fréq. timer = fréq. I²S : ça marche, mais comme le déphasage I²S/timer est imprévisible, tu peux avoir une race condition entre l'écriture des registres audio et leur lecture

Bref autant utiliser l'interruption I²S : ça marche mieux et c'est fait exprès pour ça. Quant à savoir pourquoi certains jeux utilisent un timer... ils ont peut-être voulu faire comme ils avaient l'habitude sur les machines qu'ils connaissaient, ou pas bien compris la doc. C'est vrai que c'est pas forcément évident si on ne sait pas comment fonctionne l'électronique qu'il y a derrière. (Et puis si on commence à lister les jeux Jaguar qui font des trucs bizarres/douteux, on n'a pas fini grin)

Sinon, Super Burnout est techniquement très bon en effet smile

J'avoue que je ne comprends pas vraiment, dans Super Burnout (et Atari Kart) SLCK est à zéro, je ne vois pas comment i2s pourrait alors être à la même fréquence que JPIT
De plus JPIT et i2s n'ayant pas les mêmes diviseurs c'est certains qu'il devient difficile d'avoir la même fréquence.

J'ai toujours pensé que quand on utilisait JPIT comme timer pour la fréquence d'échantillonnage, i2s était en quelque sorte "désactivé" dans le sens ou les valeurs 16bits inscrites dans L_DAC et R_DAC étaient directement envoyées tel quel en parallèle vers le DAC. Et donc forcément à la fréquence à laquelle on les y inscrit.
Après, si les échantillons sont réellement envoyé à la fréquence de i2s, quelle importance ? Si SLCK est à 0 je suppose qu'on a la fréquence maxi de i2s. Si la fréquence de i2s est très supérieur au timer JPIT, envoyer plusieurs fois le même échantillon au DAC, ça ne change absolument rien au son produit.
avatar

49

DEATH (./48) :
J'ai toujours pensé que quand on utilisait JPIT comme timer pour la fréquence d'échantillonnage, i2s était en quelque sorte "désactivé" dans le sens ou les valeurs 16bits inscrites dans L_DAC et R_DAC étaient directement envoyées tel quel en parallèle vers le DAC. Et donc forcément à la fréquence à laquelle on les y inscrit.
Non, tu ne peux pas désactiver l'I²S comme ça. Et même si tu pouvais, sans I²S tu n'aurais pas de son du tout.

DEATH (./48) :
Après, si les échantillons sont réellement envoyé à la fréquence de i2s, quelle importance ? Si SLCK est à 0 je suppose qu'on a la fréquence maxi de i2s. Si la fréquence de i2s est très supérieur au timer JPIT, envoyer plusieurs fois le même échantillon au DAC, ça ne change absolument rien au son produit.
Ben déjà, le DAC de la Jaguar (TDA1545A) est prévu pour une fréquence de 384 kHz maximum. Avec SCLK=0, on est à ~415 kHz, donc c'est déjà hors tolérance.

Accessoirement, si la fréquence du timer n'est pas un sous-multiple de la fréquence d'échantillonnage I²S, ça introduit du jitter, donc de la distorsion. C'est plus ou moins audible suivant les cas, mais c'est surtout dommage alors qu'on peut l'éviter facilement.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

50

Ok je viens de relire les documentations techniques de la Jaguar et du TDA pour me remémorer un peu tout ça et effectivement c'est bien un DAC qui reçoit les données en série à la fréquence de i2s.
La seule chose que je n'ai pas vérifier c'est quand sont envoyé les données via TX quand L_DAC et R_DAC sont chargés (1 seule fois lorsque la donnée est chargée ? Continuellement en boucle, et dans ce cas y a t il un buffer pour éviter l'écrasement de l'envoi en cours alors qu'une autre donnée est chargée...)

S'il n'y a pas possibilité d'écrasement d'une donnée en cours d'envoi au DAC, alors il est tout à fait faisable d'utiliser JPIT à la fréquence qu'on veut, de mettre i2s à la fréquence max (si je ne me trompe pas ça doit faire du 13,3Mbit, soit plus de 415Khz en 16bits stéréo, ça va, on est large)
Peu importe à quelle vitesse on met à jour L_DAC et R_DAC (enfin, du moment qu'on ne le fait pas au dessus de la fréquence de i2s bien sûr), i2s enverra toujours les bonnes valeurs au DAC. Peu importe qu'il envoi éventuellement plusieurs fois la même valeur, pour le DAC ça ne change rien, 2 mêmes valeur qui se suivent... ben... en sortie ça reste aussi la même valeur. Je ne vais quand même pas vous faire un schéma.

Je dirai même qu'utiliser l'interruption i2s, pour envoyer les échantillons à la même fréquence que i2s (/16/2) ça ne sert à rien, ça ne fait pas mieux. Je me demande même si c'est pas là que justement on peu potentiellement avoir de la distorsion. Là encore tout dépend comment les données sont envoyées sur TX (continuellement en boucle, 1 seule fois quand le registre est chargé , etc.)

L'avantage de JPIT c'est qu'il permet une plus grande précision, un plus large choix de fréquence.

Y a t il un endroit qui explique quand et comment les données sont transmises au DAC via TX ?
avatar

51

Zerosquare (./49) :

Ben déjà, le DAC de la Jaguar (TDA1545A) est prévu pour une fréquence de 384 kHz maximum. Avec SCLK=0, on est à ~415 kHz, donc c'est déjà hors tolérance.


D'après la documentation du TDA sa fréquence max est de 18,4Mbits donc la Jaguar (13,3Mbit) est bien en dessous de la limite niveau bitrate. Il ne faut pas compter en Khz par rapport au bitrate effectivement.
avatar

52

DEATH (./50) :
Ok je viens de relire les documentations techniques de la Jaguar et du TDA pour me remémorer un peu tout ça et effectivement c'est bien un DAC qui reçoit les données en série à la fréquence de i2s.
La seule chose que je n'ai pas vérifier c'est quand sont envoyé les données via TX quand L_DAC et R_DAC sont chargés (1 seule fois lorsque la donnée est chargée ? Continuellement en boucle, et dans ce cas y a t il un buffer pour éviter l'écrasement de l'envoi en cours alors qu'une autre donnée est chargée...)

S'il n'y a pas possibilité d'écrasement d'une donnée en cours d'envoi au DAC, alors il est tout à fait faisable d'utiliser JPIT à la fréquence qu'on veut, de mettre i2s à la fréquence max
Comme expliqué plus haut, c'est en boucle, que tu écrives ou pas dans les registres audio : la valeur des 2 registres audio est copiée dans des registres internes une fois tous les 32 cycles d'horloge I²S, et envoyée bit-à-bit au DAC.

DEATH (./50) :
(si je ne me trompe pas ça doit faire du 13,3Mbit, soit plus de 415Khz en 16bits stéréo, ça va, on est large)
DEATH (./51) :
D'après la documentation du TDA sa fréquence max est de 18,4Mbits donc la Jaguar (13,3Mbit) est bien en dessous de la limite niveau bitrate. Il ne faut pas compter en Khz par rapport au bitrate effectivement.
Le TDA1545A a une limite de 384 kHz pour la word clock (qui a la même fréquence que la fréquence d'échantillonnage). Visiblement ça continue à marcher quand même à 415 kHz, mais rien ne le garantit.

DEATH (./50) :
Je dirai même qu'utiliser l'interruption i2s, pour envoyer les échantillons à la même fréquence que i2s (/16/2) ça ne sert à rien, ça ne fait pas mieux. Je me demande même si c'est pas là que justement on peu potentiellement avoir de la distorsion. Là encore tout dépend comment les données sont envoyées sur TX (continuellement en boucle, 1 seule fois quand le registre est chargé , etc.)
Ben non justement. L'interruption I²S est déclenchée juste après que les valeurs des registres audio aient été copiées, du coup ton code d'interruption a la garantie d'avoir une période d'interruption entière pour changer ces registres avant qu'ils soient lus à nouveau.

Si tu utilises une interruption timer tu n'as pas cette garantie, du coup la lecture peut arriver avant que tu aies eu le temps de réécrire les registres, ou pire en plein milieu (entre l'écriture du registre "gauche" et celle du registre "droite"). Et si tu utilises une fréquence de timer différente de celle de l'I²S et/ou que ton code n'a pas un nombre de cycles constant, alors tu auras un délai imprévisible entre le moment où tes échantillons devraient être joués et le moment où ils le seront réellement (du jitter), ce qui n'est pas bon du tout pour la qualité audio.

DEATH (./50) :
L'avantage de JPIT c'est qu'il permet une plus grande précision, un plus large choix de fréquence.
Mais ça ne change pas la fréquence d'échantillonnage réelle du DAC. Si les deux fréquences ne sont pas identiques, ça revient à rééchantillonner à la volée en dupliquant ou en sautant des échantillons, ce qui est la pire méthode possible du point de vue qualité.

Vraiment, je comprends pas pourquoi tu tiens autant à ton timer, tu te compliques la vie pour rien grin

DEATH (./50) :
Y a t il un endroit qui explique quand et comment les données sont transmises au DAC via TX ?
La doc officielle ne donne pas beaucoup de détails. Les sources d'infos sont la doc du DAC (et les autres documents qui expliquent comment fonctionnent le standard I²S), et les netlists de Jerry (mais c'est prise de tête à décortiquer).
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

53

DEATH (./50) :
Y a t il un endroit qui explique quand et comment les données sont transmises au DAC via TX ?
De mémoire, il n'y a pas beaucoup de détail, mais il n'y a rien de sorcier : c'est juste un latch + un bitshifter.


tromb Fichier joint : 5kkV
- Le latch est fait lors de l’écriture dans les registres associés.
- La sélection L/R est faite avec WS
- Le shift est fait via un mux déclenché par le MSB à transmettre (par défaut : sortie shifté d'un bit du registre de sortie, et sinon la valeur d'entrée)
- le bit transmit est le MSB du registre de sortie.
- le shift est exécuté tous les SCLK.

C'est pour ça qu'il est déconseillé de ne pas utiliser SCLK comme source de synchro d'écriture pour les raisons énoncées par Zero.
Après on fait comme on veut tongue
avatar

54

Mouais, ok... Doit quand même y avoir une subtilité parce que la preuve est là, le son de Super Burnout est impeccable.

êtes vous sur que les registres L_DAC et R_DAC ne sont pas bufferisés par exemple ?

Le Schéma que tu as mis c'est celui coté Jaguar ou TDA je ne comprends pas trop ?

je sais que les chipset Jaguar tel qu'il sont c'est du bricolage, mais il serait étonnant qu'il n'y ai pas un mécanisme de protection pour cette partie
avatar

55

Pour ce qui est de la freq Max de WS du TDA qui ne semble pas en concordance avec le bitrate max (18,4Mbit devrait donner une fréquence max de 575 Khz) j'ai peut être une explication

La documentation ne semble pas très clair (bon ok je l'ai lu en zig zag...) mais le schéma de transfert semble indiquer que le 1er bit de chaque mot (droite et gauche) prend non pas un cycle, mais 8 (ou 9) ensuite les autres bit sont envoyés à chaque cycle.
Ce qui donne un total de 24 cycles par mot de 16bit pour chaque voix, soit 48 cycles pour envoyer les données droite + gauche

du coup à une freq max de 18,4Mbit, avec 48 cycles pour transférer 2*16bit on a bien une freq max de WS de 384Khz

Sur la Jaguar avec SLCK à max 13,3Mbit ça donne un WS max à 277Khz
avatar

56

Fig 6 de la documentation du TDA

Le MSB de chaque mot doit être maintenu pendant 8 cycles (ou 9, pas très clair)
avatar

57

De ce que j'ai pu trouver, le TDA1545A emploi le protocole EIAJ (un vieux truc japonais, même pas du vrai i2s...) ou du moins une version compatible plus exactement

Pour simplifier ça serait un truc codé sur 18bit sur 24 cycles.
Le premier bit doit être maintenu sur 7 cycles, puis les 17 autres bit sont ensuite envoyés à chaque cycle

Pour être compatible, vu que le TDA1545 emploi des mots de 16bits, le 1er bit doit donc être maintenu 9 cycles au lieu de 7

tromb Fichier joint : [img=http://www.diyaudio.com/forums/attachments/digital-line-level/45434d1117982397-eiaj-i2s-converter-vice-versa-eiaj-i2s.jpg[/img]
avatar

58

Bon, je sens qu'il va falloir que je sorte l'oscilloscope pour te convaincre tongue
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

59

Zerosquare (./58) :
Bon, je sens qu'il va falloir que je sorte l'oscilloscope pour te convaincre tongue

Je ne fais que me référer aux documentations des composant et des protocoles qu'ils utilisent.
avatar

60

D'ailleurs SCPCD, tu as mis quoi comme DAC sur ta Jag FPGA ? Le son de Super Burnout passe correctement dessus ?
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo