1

Je suis en train de modifier mon contrôleur HDMI pour FPGA, mais il y a un truc que je comprends pas dans le standard :
- il y a un chapitre qui décrit le "audio clock regeneration" avec N/CTS pou recréer la fréquence qui d'après les formules permettrait de faire ce que je souhaite (gérer n'importe quel fréquence en sortie)
- mais, il y a un chapitre qui dit que dans le "audio sample packet", il faut envoyer obligatoirement la fréquence audio parmi les fréquences pré-défini confus

du coup, à quoi sert le clock regeneration ? est-ce juste pour ajuster l'erreur de synchro à la fréquence défini ?


Si j'ai un générateur audio avec une fréquence qui n'est pas dans celle pré-défini dans la norme, ça veut dire qu'il faut obligatoirement faire un resampling ??

Comment ça marche dans les console portées sur MiSTer ?
Le composant hardware resample automatiquement ? (j'ai pas trouvé de doc du composant video utilisé qui explique comment ça marche)
avatar

2

Je ne connais pas ce standard en particulier, mais à mon avis la régénération d'horloge est une simple PLL pour éviter la dérive à long terme (et peut-être aussi diminuer le jitter). Je ne pense pas que la norme HDMI impose aux récepteurs de supporter des fréquences audio autres que celles standard, vu que ça impliquerait une conversion de fréquence d'échantillonnage à la volée, ce qui n'est pas forcément trivial suivant le niveau de qualité souhaité.

Donc tu risques effectivement de devoir faire du resampling, si tu veux quelque chose qui marche partout. Si tu es près à sacrifier un peu la qualité audio, une interpolation polynomiale à 4 points a un bon rapport qualité/complexité (attention cependant au clipping : même si tous les échantillons sources sont dans la plage [-2n ... 2n-1], l'échantillon interpolé peut être en-dehors. L'interpolation linéaire n'a pas ce problème, mais c'est relativement crade pour un usage audio.)

Si tu veux un résultat "qualité hi-fi"... ça va demander pas mal de complexité et de multiplieurs/additionneurs. Il y a aussi des composants dédiés, TI en fait par exemple.

Pour le MiSTer et compagnie, c'est une très bonne question, je n'ai pas la réponse (il est très possible qu'ils émulent directement l'audio à une fréquence standard, plutôt qu'émuler à la fréquence native puis convertir).

EDIT : ceci dit, dans le cas de la Jaguar, beaucoup de jeux font fonctionner le DAC grosso-modo aux alentours de 16 ~ 22 kHz, et il n'y a pas de filtre de reconstruction en sortie. Donc même un rééchantillonnage basique pourrait sonner aussi bien (voire mieux) que sur la console d'origine.
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

3

Effectivement c'est pour la JagFPGA et j'ai bien peur de devoir implémenter un resampler dans le FPGA sad


Tu as des docs/exemples (même en C) pour les différentes solutions de resampling que tu proposes ? (que je vois la complexité à implémenter ou trouver des trucs tout fait en VHDL smile)
Après dans un premier temps je peux faire une version simple (mais pas trop dégueu quand même tongue), et voir par la suite pour améliorer.... wink
avatar

4

Oui, dans un premier temps, je te conseillerais de tester avec une approche bête et méchante : avoir la partie "émulation" et la partie "transmission audio" complètement séparées (et potentiellement asynchrones), avec la partie transmission qui se limite à un timer à la fréquence d'échantillonnage de sortie (48 kHz est probablement le meilleur choix si tu veux que ce soit compatible avec le maximum de trucs). À chaque déclenchement du timer, tu copies simplement les valeurs des registres L_DAC et R_DAC dans le buffer de sortie audio HDMI. Tu peux éventuellement ajouter un étage intermédiaire qui latche la valeur des registres au moment où l'interruption I²S se produit, pour éviter la race condition qui se produit si la lecture tombe en même temps que l'écriture (et donc se retrouver potentiellement avec une ancienne valeur pour le canal gauche et une nouvelle pour le canal droit, ou le contraire).

C'est crade, mais c'est de loin la solution la plus simple pour avoir quelque chose qui fonctionne, à défaut d'être de haute qualité.

J'ai un peu de code pour le resampling, mais en y réfléchissant, c'est pas vraiment adapté à ce cas-là :
- les calculs sont en virgule flottante, donc chiant sur FPGA
- c'est prévu pour une fréquence de sortie variable, or on peut beaucoup simplifier les choses si les fréquences d'entrée et de sortie sont fixes, et encore plus si on accepte de retoucher un peu l'une ou l'autre (de façon à ce que le ratio des deux soit un nombre rationnel, avec un PPCM(numérateur, dénominateur) pas trop grand).
- c'était dans un contexte où le "contrôle de flux" est fait en externe (en gros, le resampler se contente de transformer les échantillons d'entrée en échantillons de sortie, sans devoir gérer le buffering, ce qui se passe quand le nombre d'échantillons en sortie varie de +/-1 par rapport au buffer précédent, etc.)

Donc si tu veux une solution "qualité", je pense qu'il vaut mieux un truc sur mesure conçu d'après les contraintes que tu as :
- est-ce que l'horloge d'entrée et/ou de sortie doit être synchrone avec autre chose (soit directement via un diviseur ou une PLL, soit à plus long terme), par exemple la génération vidéo ?
- est-ce qu'il est acceptable de changer un peu leur fréquence, et si oui, de combien ? (sachant que la fréquence est déjà pas exactement la même entre une Jaguar NTSC et une Jaguar PAL, donc même à la base, il y a déjà une marge de tolérance)
- de quelles horloge(s) et PLL(s) tu disposes dans ton FPGA ?
- est ce qu'il y a un peu de buffering côté audio HDMI, ou c'est strictement isochrone ?

(après, je peux détailler un peu la partie algo, mais je ne sais pas si ce n'est pas mettre la charrue avant les bœufs 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

5

pas con la solution proposé, j'y ai pas pensé smile

Ça me semble la plus simple à faire sans tout casser mon code existant smile
Et je ne suis pas sur que ça change grand chose niveau qualité audio (vu les pistes audio de l’existant tongue)

Le principal c'est d'avoir un truc qui marche sur ma carte FPGA, après les autres cartes ont généralement des composants dédiés HDMI donc y a moins à se prendre la tête sur la génération du signal..


Merci ! smile
avatar

6

(j'approuve la proposition de Zerosquare. Ca me semble pas si mal en effet embarrassed)

7

zttO

section 1:
* signal I2S à ~22kHz (environ vu que la jag on peut pas faire du 22kHz tongue)
section 2:
* signal "rééchantilloné" à 48kHz
* génération du signal vidéo
section 3:
* encodage HDMI
section 4:
* décodage HDMI comme le ferai une TV

on voit qu'il y a quelques défaut lors du rééchantillonnage, mais pas sur que ça sera audible avec l'oversampling des DAC moderne.

Je verrais bien lorsque je testerai en vrai smile
avatar

8

top
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