Un premier constat est que Linux prend en compte un paramètre inconnu des drivers Windows (nombre de périodes). Ma compréhension est que l'idée est la suivante : lorsque la carte son est saturée, elle ne génère plus d'interruption pour demander des échantillons. Le noyau peut alors accepter alors plusieurs "périodes" depuis le DAW (ici 2). Lorsqu'il seront pleins, le DAW (son thread audio) sera bloqué car n'ayant rien à faire. Le noyau enverra les périodes à la carte son lorsqu'elle sera disponible, ce qui libérera des "périodes" et décoincera donc le DAW. Si ce dernier met trop de temps à réagir, pas grave, il y a une deuxième période en réserve...
Du coup, au niveau du PC, il y a une latence de 2*64/48=2,67ms, puisqu'il faut compter 2 périodes en réserve au maximum en fonctionnement normal. Cependant, on n'a pas vu ce qu'il se passe du côté de la carte son. Normalement, une carte son est réglée pour éviter des craquements lorsque le PC n'a pas un rythme régulier (et un OS complexe ne peut avoir un comportement régulier à la microseconde)... ce qui induit logiquement un peu de bufferisation ajoutée. Je m'attends donc à plus de 2,67ms
Un réglage recommandé est 2 périodes. Cela me laisse perplexe. Pourquoi pas 1 avec des périodes de taille doubles ? cela limiterait la fréquence des interruptions du DAW sans changer la latence. Ceci-dit, avec un tel réglage, le DAW a plus d'achantillons à calculer en peu de temps, ce qui peut poser problème... 2 est peut-être l'idéal mesuré de façon empirique.
A toute fin utile, 64 échantillons à 48 kHz sur mon UR22 sous Windows affiche 4,125ms (chiffre donné par un drivers Steinberg, donc a priori correct). A 128, on a 6,458ms (ce n'est pas le double !). Cela me laisse donc perplexe lorsqu'un logiciel utilise un règle mathématique simple pour calculer une latence (comme Reaper avec le mode WASAPI qui calcule bêtement 256/44,1=5,8ms... oui, un chipset intégré à 256 plus efficace que l'UR22 à 128... cherchez l'erreur).
Pour info, les spécifications Audio/USB mentionnent une latence interne à l'interface audio (https://www.usb.org/sites/default/files/audio10.pdf, p 59). Et j'ai beau chercher dans les sources de Linux, pas de trace d'usage de cette information précieuse... on l'a dans /include/uapi/linix/usb/audio.h mais dans aucun fichier .c pertinent. (juste /drivers/usb/gadget/function/f_uac1.c ... où on force la valeur à 1 sans la lire).Bref l'info est décodée... puis ignorée !
Commentaire