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 davantage 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 sont 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 cumulé sur l’ensemble des appels XDspConnect. Si un seul appel XDspConnect est effectué avec la valeur 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 cumulée maximale prise en charge tombe à 64 secondes.
- Toutes les mémoires tampons transmises à l’API doivent être alignées sur 16 octets. Le matériel peut rencontrer une erreur 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 depuis https://aka.ms/gdkdl.
- L’outil de conversion de réponse impulsionnelle inclut désormais la prise en charge de la réduction, ce qui vous permet d’échanger une baisse de qualité contre de meilleures performances. Pour plus de détails, consultez la Vue d’ensemble de la réduction de la réponse impulsionnelle XDSP.
- 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 par rapport au format cartésien par défaut, qui est plus performant.
Bonnes pratiques
- Il y aura une réponse pour chaque commande soumise au matériel, même lorsque le matériel rencontre une erreur. L’appelant doit attendre que toutes les commandes aient été 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 à traiter leurs commandes.
- La “baseBuffer” transmise à l’appel XDspConnect ne doit pas être libérée 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 dans le traitement des commandes consécutives, c’est-à-dire que tous les blocs ne prennent pas le même temps à s’exécuter 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 restreint. 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 le XDspStatus sera mis à jour en conséquence.Exemples
- Disponibles en téléchargement depuis https://aka.ms/gdkdl et parmi les exemples ATG. Des procédures pas à pas des exemples 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 avec l’installation du GDK. Il montre comment l’accélération matérielle peut être utilisée pour convertir une réponse impulsionnelle à la volée en vue de son utilisation avec l’API XDSP.