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).
Zerosquare (./36) :Ca fonctionne exactement comme tu dis.
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 )
Zerosquare (./36) :
Si Super Burnout le fait effectivement, je ne vois vraiment pas pourquoi.
DEATH (./39) :Pour la sortie PWM DAC (car elle utilise justement les JPIT), mais pas pour la sortie I2S qui utilise SCLK.
Peut être parce que c'est indiqué dans la documentation qu'il faut faire comme ça
Peut-être l'habitude d'utiliser des timers comme sur les autres archis ?
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
SCPCD (./40) :DEATH (./39) :Pour la sortie PWM DAC (car elle utilise justement les JPIT), mais pas pour la sortie I2S qui utilise SCLK.
Peut être parce que c'est indiqué dans la documentation qu'il faut faire comme çaPeut-être l'habitude d'utiliser des timers comme sur les autres archis ?
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
Ou portage ?
C'est une solution comme une autre : soit utiliser plusieurs timers, soit utiliser un seul timer avec des sous compteurs.
DEATH (./43) :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.
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é.
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)
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.
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)
DEATH (./46) :Il me semble avoir lu quelque chose à ce sujet il y a... longtemps. Probablement utilisé dans une démo, ou dans un lecteur audio ?
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)
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 )
Sinon, Super Burnout est techniquement très bon en effet
DEATH (./48) :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.
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.
DEATH (./48) :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.
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.
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.
DEATH (./50) :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.
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
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) :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.
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.
DEATH (./50) :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.
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.)
DEATH (./50) :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é.
L'avantage de JPIT c'est qu'il permet une plus grande précision, un plus large choix de fréquence.
DEATH (./50) :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).
Y a t il un endroit qui explique quand et comment les données sont transmises au DAC via TX ?
DEATH (./50) :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.
Y a t il un endroit qui explique quand et comment les données sont transmises au DAC via TX ?
Zerosquare (./58) :
Bon, je sens qu'il va falloir que je sorte l'oscilloscope pour te convaincre