Musique interactive : planifier les transitions sur l'horloge audio

Utiliser une horloge propre au moteur de rendu audio

Un callback du thread de jeu signalant qu'un temps vient d'arriver est trop tardif pour garantir qu'un son demandé à cet instant démarre exactement sur ce temps. L'audio est rendu par buffers, alors que les images du jeu peuvent arriver de façon irrégulière. Il faut donc planifier le rendu à l'avance. Quartz, dans Unreal, prend en charge la quantification musicale sur son horloge audio ; AudioSource.PlayScheduled d'Unity planifie par rapport à la timeline absolue exposée par AudioSettings.dspTime. [1][2]

Définir le contrat de planification musicale

Il faut préciser une origine commune, le tempo, la signature rythmique et les frontières qui autorisent une transition. Il faut aussi décider du temps de préparation dont un nouveau segment a besoin, chargement et décodage compris. Toutes les couches doivent rester sur la même horloge, et les frontières doivent se déduire de la position musicale, non d'un cumul répété de durées d'images arrondies. Un changement d'intensité peut demander la prochaine transition valide sans lancer immédiatement un nouveau son. Les demandes répétées doivent être fusionnées, afin que le planificateur ne mette pas en file des entrées en double.

Exemple détaillé : la prochaine mesure peut déjà être trop proche

Prenons, à titre d'illustration, un tempo de 120 pulsations par minute avec des temps à la noire en 4/4 et une fréquence audio de 48000 frames d'échantillons par seconde. Chaque temps dure 0,5 seconde, soit 24000 frames ; chaque mesure dure 2 secondes, soit 96000 frames. L'origine musicale est fixée au temps zéro.

À l'instant audio 5,3 secondes, la mesure suivante commence à 6 secondes, ce qui laisse 0,7 seconde de préparation. Supposons que ce système exige volontairement 0,1 seconde d'avance. Une demande émise à 5,95 secondes ne laisse que 0,05 seconde ; la prochaine mesure admissible est alors celle de 8 secondes. La valeur d'avance est ici une politique donnée en exemple, pas une garantie du moteur. Démarrer en retard sur la frontière manquée modifierait la relation musicale.

Vérifier les transitions sous charge

On commence par des clics sur le temps et une seconde couche qui entre sur une frontière de mesure. Il faut capturer l'audio rendu et inspecter la position des attaques, plutôt que de déduire le timing d'une notification visuelle. On teste des demandes juste avant et juste après l'échéance de planification. On introduit des saccades du thread de jeu et des chargements de ressources à froid, tout en vérifiant si le comportement de repli choisi conserve la musique en cours ou reporte l'entrée.

Le comportement en cas d'annulation, de pause, de reprise et de changement de tempo doit être spécifié. Une transition déjà en file pour un certain état de l'horloge peut nécessiter un remplacement explicite après le changement de cet état. Les frontières de boucle sont à examiner : silences, attaques dupliquées, longueurs de segments incohérentes. Les fondus enchaînés doivent suivre le même contrat de timing que les démarrages de segments.

Rester précis sur la notion de précision

La précision à l'échantillon décrit le placement au sein de l'audio rendu. Elle n'élimine ni la mise en tampon de la sortie, ni la latence du périphérique, ni le délai avant qu'une demande de gameplay n'atteigne le planificateur. Il ne faut pas supposer que les notifications du thread de jeu sont elles-mêmes précises à l'échantillon. Les changements de périphérique et les ressources indisponibles exigent des politiques de reprise. Il convient d'évaluer à la fois la continuité musicale et le temps de réponse : une entrée parfaitement alignée peut sembler peu réactive si la frontière choisie est trop éloignée.

Sources

• [1] Quartz Overview — Epic Games, documentation d'Unreal Engine.
• [2] AudioSource.PlayScheduled — Unity Technologies, API de script d'Unity 6.0.