Nouveautés de la version d’octobre 2022
- Deux nouvelles API, XDspConnectWithMaximumStreamLimit et XDspSubmitCommandWithEnvelope, ont été ajoutées. XDspConnectWithMaximumStreamLimit utilise moins de mémoire en interne si le nombre maximal de flux pouvant être activés est inférieur à 256. XDspConnect, en revanche, prévoit 256 flux et utilise donc plus de mémoire. XDspSubmitCommandWithEnvelope permet l’enveloppement du filtre de réponse impulsionnelle. Consultez la Vue d’ensemble de l’enveloppement à l’aide de l’API XDSP.
Fonctionnalités de la version
- Pour la convolution, les tailles de bloc prises en charge sont de 512 et 1024 trames. Les performances seront meilleures avec une taille de bloc de 1024 trames.
- Pour la FFT/IFFT, les tailles de bloc prises en charge sont de 512, 1024 et 2048 trames.
- La convolution est prise en charge en modes mono, stéréo et stéréo désentrelacé, avec des réponses impulsionnelles mono et stéréo.
- L’appel à XDspConnect ou à XDspConnectWithMaximumStreamLimit établit une connexion avec le matériel et retourne un XDspClientHandle. Seules 8 connexions peuvent être actives à un moment donné.
- La valeur maximale de aggregateImpulseResponseInSeconds prise en charge dans l’appel à XDspConnect est de 128. Il s’agit également du maximum pour l’ensemble des appels à XDspConnect. Si un seul appel à XDspConnect est effectué avec 128 pour aggregateImpulseResponseInSeconds, aucun autre appel à XDspConnect ne peut être effectué avec une valeur aggregateImpulseResponseInSeconds supérieure à 0. aggregateImpulseResponseInSeconds doit être supérieur à zéro pour permettre l’activation de flux pour le traitement par convolution.
- Un maximum de 256 flux peuvent être activés à l’aide de XDspActivate pour un XDspClientHandle donné retourné par XDspConnect. Un maximum de maximumStreamCount flux peuvent être activés à l’aide de XDspActivate pour un XDspClientHandle donné retourné par XDspConnectWithMaximumStreamLimit, où maximumStreamCount est le nombre de flux utilisé dans l’appel à XDspConnectWithMaximumStreamLimit. Ces flux peuvent être de n’importe quel XDspProcessType.
- Lorsqu’une entrée stéréo est utilisée, la réponse impulsionnelle agrégée maximale prise en charge passe à 64 secondes.
- Toutes les mémoires tampons transmises à l’API doivent être alignées sur 16 octets. Le matériel peut subir une défaillance et se réinitialiser si les mémoires tampons ne sont pas alignées sur 16 octets. XDspStatus.result indiquera XDSP_E_DEVICE_FATAL_ERROR lorsque le matériel a subi un plantage ou un blocage.
- La réponse impulsionnelle doit être dans le domaine fréquentiel. Un outil est fourni pour convertir les réponses impulsionnelles du domaine temporel vers le domaine fréquentiel. Téléchargez-le à partir de https://aka.ms/gdkdl.
- L’outil de conversion de réponse impulsionnelle prend désormais en charge la réduction, ce qui vous permet d’échanger une baisse de qualité contre de meilleures performances. Consultez la Vue d’ensemble de la réduction de réponse impulsionnelle XDSP pour plus de détails.
- La latence de l’appel à XDspConnect a été améliorée.
Problèmes connus
- L’option « EnablePolarFormat » de XDspActivationOptions pour le traitement FFT/IFFT prend beaucoup de temps comparativement au format cartésien par défaut, qui est plus performant.
Meilleures pratiques
- Il y aura une réponse pour chaque commande soumise au matériel, même lorsque le matériel subit une défaillance. L’appelant doit attendre que toutes les commandes soient traitées par le matériel avant d’appeler XDspDeactivate pour désactiver le flux. XDspStatus.lastProcessedCommandSequence indique le numéro de séquence de la dernière commande traitée par le matériel pour ce flux. Les autres flux XDSP ne seront pas affectés et le matériel continuera de traiter leurs commandes.
- Le « baseBuffer » transmis à l’appel à XDspConnect ne doit pas être libéré tant que tous les flux n’ont pas été désactivés à l’aide de XDspDeactivate et que XDspDisconnect n’a pas réussi.
- Il existe une limite de file d’attente interne pour chaque flux, et XDspSubmitCommand retourne XDSP_E_QUEUE_FULL lorsque cette limite est atteinte. Lorsque cette erreur se produit, laissez suffisamment de temps au matériel pour traiter les commandes de ce flux avant d’en soumettre d’autres. XDspStatus.lastProcessedCommandSequence peut être utilisé pour vérifier la dernière commande traitée par le matériel pour ce flux.
- Les performances de la convolution sont meilleures avec une taille de bloc de 1024 qu’avec une taille de bloc de 512.
- L’algorithme de convolution n’est pas homogène en ce qui concerne le traitement des commandes consécutives, c’est-à-dire que tous les blocs ne prennent pas le même temps à se terminer et que certains peuvent prendre plus de temps que d’autres.
Mise en pause et reprise d’un titre
Un titre doit pouvoir se mettre en pause et reprendre, par exemple lorsque l’utilisateur le place en mode Contraint. Lorsque le gestionnaire de suspension est appelé, cessez simplement de soumettre des commandes XDSP au matériel. Les commandes déjà soumises seront traitées normalement et XDspStatus sera mis à jour en conséquence.Exemples
- Disponibles en téléchargement à partir de https://aka.ms/gdkdl et dans les exemples ATG. Des procédures pas à pas sont disponibles pour Réverbération par convolution à flux unique et FFT IFFT à flux unique
- Un exemple XDSP qui utilise l’accélérateur matériel pour convertir une réponse impulsionnelle du domaine temporel vers le domaine fréquentiel est inclus avec les autres exemples sur le portail de téléchargement du GDK https://aka.ms/gdkdl. Cet exemple produit exactement la même sortie que l’outil Impulse Response Transform inclus dans l’installation du GDK. Il montre comment l’accélération matérielle peut être utilisée pour convertir à la volée une réponse impulsionnelle afin de l’utiliser avec l’API XDSP.