driver audio megadrive ?

[Invité]

après divers essais, enregistrements, tests et re-tests, je crois avoir trouvé un petit probleme de restitution audio dans BOBC.

voila une image qui montre ce qui se passe : (plus parlant qu'un son à écouter ou l'on n'entend pas la différence si on ne sait pas à quel détail preter attention)



j'ai enregistré un passage d'une même musique
les 2 pistes sont basées sur la même séquence de départ.

sur la 1ere piste : joué via une rom exportee par deflemask
sur la 2eme piste : joué via le jeu (BOBC)

on peut voir sur la 1e piste que la "cloche" et le "kick" sont parfaitement syncro, quasi indifférenciables, d'une précision astronomique.

ca se dégrade dans la 2eme piste, ou les samples sont décalés par rapport aux voies FM, il en résulte une qualité de restitution pas toujours tres correcte, ca flotte un peu. c'est minime, certes, mais ca s'entend. il y a deux sons qui viennent l'un apres l'autre alors qu'ils devraient etre joués en meme temps.

ce que j'ai remarqué aussi, c'est que parfois, quand une musique commence, si la premiere note jouée est un sample très court, il va tout simplement passer à la trappe.

est-il possible d'apporter un fix à ce petit souci de latence? je pense que les bruitages samplés seraient aussi beaucoup plus réactifs en jeu par la même occasion. (comme Touko l'a remarqué sur la démo du jeu de Tennis de Vetea ou il y a X frames de retard entre l'action à l'écran et le son joué).
la restitution audio s'en verrait grandement améliorée et les pistes samplées gagneraient en précision rythmique.

[Invité]

Pour palier au problème il faut que ce soit de ton côté que tu prévois les 4 frames de retard.
Après tu as peut être aussi déniché des bugs, qui pourront aider stef à améliorer son driver .

[Invité]

Pour palier au problème il faut que ce soit de ton côté que tu prévois les 4 frames de retard.
Après tu as peut être aussi déniché des bugs, qui pourront aider stef à améliorer son driver .

tu vois ca comment pour la maniere de proceder?

hypothese 1: il faudrait reculer d'une case tous les NOTE_ON de son sur le channel 6 (pour qu'un son s'entendre en position 0, il faudrait le lancer en position 63 et ajouter du blanc au début). soit un bordel monumental dans tous les patterns, et un gachis de ram pour stocker le blanc avant un son).

hypothese 2: raccourcir de 4 frames le début de chaque son. d'un point de vue théorique ca se tient. mais quand tu vires l'attaque d'une bassdrum ou d'un charleston, à l'écoute, il ne restera plus grand chose.

hypothese 3 : décaler tout ce qui sort des canaux FM et PSG de 4 frames vers "apres". ou les pistes samplées vers "l'avant". ce que deflemask ne permet pas. on peut farfouiller les opérateurs mais je ne vois rien dans le manuel qui permette de faire ce genre de feinte de ninja.

hypothese 4 : utiliser des drums FM et faire disparaitre le probleme dans la lancée

une idée?

si j'ai fait une erreur ou oublié un truc, pourquoi ca passe tip top via une rom de deflemask?

.:

[Invité]

Non 
Mais je pense que ta numéro 3 devrait être bonne,ou le plus simple est d'éviter les samples dans la musique .

Sinon ça passe niquel avec la ROM dmask, car elle doit utiliser un driver classique, celui de stef est bcp plus complexe, et est fait pour être utilisé in-game .
Après il a aussi fait le choix de 4 voix PCM, ce qui allonge aussi le retard(plus de données à mettre en cache) .

[Stef]

Effectivement Touko a assez bien décrit le problème. Le driver XGM (celui que vous utilisez ici) a un timing basé sur la frame (1/60 ou 1/50s selon le système) et en ce qui concerne les samples y'a effectivement un "flottement" induit par l'utilisation du buffering.
Dans la théorie les samples sont toujours ~3 frames en retard : le buffer fait 4 frames mais y'a 3 frames de "sécurité" pendant que l'une d'elle est réservée à la lecture du sample actuel donc en général tu es toujours aux alentours de 3 frames de latence (un poil plus en réalité). Par contre le convertisseur Xgmtool corrige de lui même cette latence de 3 frames quand tu compiles une musique du coup la latence finale est bien plus réduite mais il restera toujours un petit décalage qui devrait être inférieur a 1 frame théoriquement. Je peux essayer de bidouiller pour décaler un peu plus ou moins mais j'ai fait quelques tests et le résultat actuel me semblait être le meilleur compromis car il n'y aura hélas jamais de synchro parfaite... c'est le propre du driver XGM. Le fait d'avoir 4 PCM et de supporter la contention avec le DMA a un prix :-/
Aussi effectivement les bruitages souffrent de cette latence de ~3 frames (qui ici ne peut pas être corrigé dans ce cas). Je sais que c'est assez fâcheux comme défaut heureusement sur le vrai hardware ça se remarque moins que sur émulateur (qui rajoute leur propre latence).
Il faut savoir aussi que le wrapper BEX est basé sur une vieille version du driver XGM, peut être que la dernière version donnerait de meilleurs résultats (j'ai changé l'ordre de certaines actions et la priorité des événements) mais j'ai quand même des doutes.

Pour le problème de sample qui disparaissent quand ils sont placés en première note, oui en effet, c'était un bug de XgmTools qui devrait être corrigé dans la dernière version, cela est due justement à la prise en compte de la latence des samples qui sont décalés 3 frames en arrière. Problème : si tu as des samples dans les frames 0,1 ou 2, ils devraient alors se retrouver en -3, -2 et -1 :p La solution est alors d'ajouter un silence d'au moins 3 frames au début de la musique pour éviter ce soucis

Une information qui pourrait m'aider serait de savoir de combien de milli seconde le sample est décalé avec la note FM ?
Théoriquement sur une machine NTSC ça devrait être < 16 ms, je dirais même < 10 ms (car je peux choisir de me positionner un peu plus tot ou un peu plus tard au choix). En PAL le décalage devrait être < 20 ms et même < 12 ms avec ce choix de positionnement. Si le décalage est supérieur à ces chiffres alors je peux surement faire quelque chose, sinon c'est déjà le mieux que je peux avoir :-/

Edit: En regardant l'image que tu as posté j'ai l'impression d'observer un décalage de 4 ms environ... dans ce cas je crains hélas de ne pouvoir mieux faire malheureusement. Le pire c'est que je doute que ce décalage soit régulier, j'imagine qu'il varie de 2 ou 3 ms selon la situation... S'il était régulier je pourrais améliorer les choses en décalant le sample d'une frame en amont, on se retrouverait alors avec un sample en avance de N ms sur la FM et il me suffirait alors d'inclure un blanc de N ms au début de chaque sample pour être à peu près synchrone =)

[Invité]

Stef a écrit:
Une information qui pourrait m'aider serait de savoir de combien de milli seconde le sample est décalé avec la note FM ?

Le pire c'est que je doute que ce décalage soit régulier

j'ai zoomé pour voir, ca se promene entre 0.031s et 0.048s (avant la note FM) en PAL.

je confirme pour le décalage irrégulier, que je soupconnais déja à l'oreille.

merci d'avoir répondu en tout cas j'ai appris plein de trucs sur le pourquoi du comment.

[Stef]

Merci pour ta réponse Kaot :) Alors entre 31 et 48 ms, c'est un décalage énorme, et tu es sûr que c'est avant car sur ton screen shot j'ai l'impression que le sample arrive après le son FM ?? Et c'est bizarre que ça soit autant décalé, je m'attendais plutot à un ordre de grandeur entre 5 et 20 ms max.

[Invité]

effectivement jai inversé la ch5 et ch6 sur le screenshot mea culpa

si tu veux verifier par toi meme j'ai mis un sample ici
la cloche = chan 5, le kick = chan 6

[Stef]

Super merci, je vais regarder ça !

[Stef]

Bon effectivement je vois un décalage de 30 ms, c'est énorme, ça ne devrait pas être autant et ça s'entend facilement du coup !
Est-ce que tu pourrais me filer le vgm (tu peux me filer un tronqué si c'est génant d'avoir le VGM complet ^^) ? j'aimerai comprendre le problème dans la conversion :) Merci !

[Invité]

des vgms de test si ca peut eventuellement servir a calibrer/comparer ou quoi que ce soit 

sans boucle et avec

et le meme en rom

[Stef]

Merci, je vais inspecter tout ça !

[Stef]

Je viens de faire des tests, j'observe effectivement des décalage de l'ordre de 2/3 ms (imperceptible) jusqu'à 28 ms au pire (très perceptible :-/)...
Malheureusement ce décalage flottant est pas vraiment soluble, je pense que je pourrais mieux l'aligner mais ça flottera toujours sur une période de 25 ms en PAL et 20 ms en NTSC, ça hélas c'est vraiment pas possible de le résoudre dans le driver...
Je me demande quelle version de xgmtools tu utilises pour convertir tes VGM en XGM/XGC car chez toi le décalage est encore plus important, aussi utilises-tu l'option -p pour forcer le timing PAL (meme si normalement il devrait etre reconnu par le fichier VGM).

Trop dommage que Deflemask ne te laisse pas utiliser les canaux PCM supplémentaires du XGM, tu pourrais ainsi contourner le soucis en utilisant des instrus PCM pour tout ce qui doit etre synchrone en PCM.

[Invité]

Je me demande quelle version de xgmtools tu utilises pour convertir tes VGM en XGM/XGC car chez toi le décalage est encore plus important, aussi utilises-tu l'option -p pour forcer le timing PAL (meme si normalement il devrait etre reconnu par le fichier VGM).

Trop dommage que Deflemask ne te laisse pas utiliser les canaux PCM supplémentaires du XGM, tu pourrais ainsi contourner le soucis en utilisant des instrus PCM pour tout ce qui doit etre synchrone en PCM.

je fournis le vgm en timing PAL, depuis deflemask, mon action s'arrete la.
si ca se trouve cest le rendu de kega qui est différent du rendu sur la console aussi.

[Stef]

Non à ce niveau là tu auras la même chose sur la console (à peu de choses près)... faudrait que je demande à vetea pour la conversion vgm en xgm.