Chargement...
 
[Voir/Cacher menus de gauche]
[Voir/Cacher menus de droite]

5 - Les serveurs son : Jack, PulseAudio et autres...

Dernier post

Questions générales sur la latence

BlindeKinder utilisateur non connecté
Salut...
Comme je fais pas mal de test avec Jack ffado, mon edirol FA-101 et la latence de tout ce petit monde, je me posais quelques questions:
question-La latence qui est donnée dans les configs de qjackctl est elle réelle ou est-ce une indication approximative?
question-à quoi correspond la latence dans Ardour, qui est systématiquement plus basse que celle de qjackctl (p.ex: 256/3 à 44100 me donne 17,4ms dans qjackctl et 5.8ms dans Ardour)
question-y a t'il un quelconque utilitaire qui mesure la latence réelle?

questionEt la question subsidiaire: pourquoi la latence est plus basse si j'augmente le taux d'échantillonnage? (à 128/3: 8ms à 44100 et 4 à 96000 dans les réglages de qjackctl)

Merci pour vos éclaircissements...

Mysth-R utilisateur non connecté France
bonnes questions j'aimerais bien savoir aussi mrgreen

BlindeKinder utilisateur non connecté
yeah...
Entre temps j'ai cherché un peu également et je suis tombé sur la même page de ffado que tu as donné... J'ai compilé jdelay et ça fonctionne bien... il faut faire une boucle sur la carte son (sortie sur entrée) et faire les connexions dans jack... ça augmente pas mal par rapport à l'indication qjackctl, normal, il y a la carte et tout...
Mais les définitions de frames, périodes, etc ne sont pas claires pour moi... j'ai fait des recherches mais je n'ai trouvé que des définitions assez sommaires... si vous avez une page qui explique tout ça bien...
Et quelqu'un sait comment compiler qjacklam? http://developer.berlios.de/projects/qjacklam/

youki utilisateur non connecté
Les liens donnes par Trinine ont l'air interessants, mais est-ce que quelqu'un maitrisant quelque peu cet anglais technique pourrait en faire un resume en francais courant?
Parce que "roundtrip latency","output latency", etc... ben lapin complis.

BlindeKinder utilisateur non connecté
J'ai creusé un peu tout ça, et finalement j'ai compris le calcul de la latence de qjackctl... Je fais dès que j'ai un peu de temps un petit résumé ici, peut-être à mettre ensuite dans la doc... smile

BlindeKinder utilisateur non connecté
Bon, chose promise chose due. Il s'agit de ma compréhension de la chose, merci de corriger/compléter si besoin:

Je ne reviens que brièvement sur l'échantillonnage, tant ce sujet est expliqué un peu partout.
Prenons une seconde de son, ou plutôt la courbe qui en résulte. Nous la découpons en tranches égales, disons 44100 tranches pour une seconde. On dit alors que le son est échantilloné à 44100Hertz, c'est à dire que 44100 fois par seconde on donne un coup de hachoir...
Bien, appelons chaque segment une Frame.

Prenons donc un son échantilloné à 44100Hz. Une seconde divisée par 44100 nous donne la durée de chaque Frame... Attention, c'est très petit:
1 / 44100 = 22.67e-6 s (ou 0.00002267 seconde)

Il s'agit à présent de définir la taille du Buffer (mémoire tampon). Celle-ci est décisive car elle définit la latence: si l'on met 10ms de son dans le Buffer, le système aura au maximum ces 10ms pour vider le buffer et envoyer les informations à destination. Malheureusement on ne compte pas la taille du Buffer en temps, mais en Frames, qui peuvent varier en durée, comme nous alons le voir.

On mettra dans le Buffer un certain nombre de Périodes, qui contiendront un certain nombre de Frames. Allons-y:

Je décide de mettre 64 Frames dans 3 Périodes. Nous avons donc 3 fois 64 Frames de 22.67e-6 s. Calculons ce temps:
22.67e-6 * 64 = 0.0014512 s = 1.4512ms: C'est la durée d'une période.
3 * 0.0014512 s = 0.004353 s = 4.35 ms: et voilà notre latence.

C'est le temps que vous donnera par exemple qjackctl avec cette configuration. Le système devra donc vider le Buffer au plus toutes les 4.35ms.

Voici quatre exemples que nous allons comparer:
à 44100Hz: la durée de la Frame est de 1 / 441000 = 22.67e-6 s.
64/3: (22.67e-6 * 64) * 3 = 4.35ms 256/3: (22.67e-6 * 256) * 3 = 17.41ms
à 96000Hz: la durée de la Frame est de 1 / 96000 = 10.41e-6 s.
64/3: (10.67e-6 * 64) * 3 = 2ms 256/3: (10.67e-6 * 256) * 3 = 8ms


Que constatons-nous? Comparons ces exemples côtes-à-côtes: à fréquence d'échantillonage égale, si l'on met beaucoup de Frames dans le Buffer avant qu'il ne soit vidé, la latence augmente. C'est logique.
Comparons-à présent les exemples verticalement: avec un échantillonage plus élevé, une frame dure moins longtemps. Ici, entre 44100Hz et 96000Hz, ce temps est quasiment divisée par deux. Si l'on met le même nombre de Frames dans une période à des échantillonages respectivement bas et haut (44100Hz et 96000Hz), dans le premier cas la période sera plus longue, et dans le deuxième plus courte, à une quantité d'informations égale. C'est pourquoi la latence diminue si l'on augmente le taux d'échantillonage. Cependant, il en résulte également une hausse de l'utilisation des ressources, car le buffer sera vidé plus fréquemment, et l'information devra être traité plus rapidement.


Bon, j'espère que cette explication est cohérente... Je me demande juste pourquoi on ne double pas cette latence, puisque il me semble qu'on doit faire une fois le calcul en entrée et une fois en sortie... Et l'autre question, pourquoi mettre plusieurs périodes dans le buffer au lieu d'augmenter simplement le nombre de Frames?

Pour info, en mesurant la latence avec jdelay, j'obtiens 424 frames à 64/3@44100, soit 9,61ms, au lieu des 4,35ms théoriques... Si je passe en plus par PureData, elle augmente encore de 3ms...

Afficher les articles :
Aller au forum :

Documentation [Afficher / Cacher]

Connexion
[Afficher / Cacher]



Mégaphone [Afficher / Cacher]

sub26nico, 17:49, ven. 18 Oct 2019: Salut et bienvenue à grotul et letit69 :-)
sub26nico, 22:33, jeu. 17 Oct 2019: Salut et bienvenue à Beru :-)
olinuxx, 22:29, mer. 16 Oct 2019: Bonjour et bienvenue à Gm4Off cool
sub26nico, 22:39, lun. 14 Oct 2019: Salut et bienvenue à samaudio :-)
sub26nico, 11:04, dim. 13 Oct 2019: Salut et bienvenue à benoitf :-)
sub26nico, 17:56, ven. 11 Oct 2019: Des greffons proprios portés sous GNU/Linux : [Lien]
sri_raoul, 16:50, ven. 11 Oct 2019: The sonaremin: un projet synthé modulaire porté pour arm [Lien]
sub26nico, 22:37, jeu. 10 Oct 2019: Salut et bienvenue à nickythomas :-)
sub26nico, 10:34, jeu. 10 Oct 2019: Salut et bienvenue à Kiara, shadows, flofloy100 et Do_done :-)
r1, 17:24, mer. 09 Oct 2019: Moi aussi j'ai revu olinuxx avec grand plaisir !
allany, 08:37, mer. 09 Oct 2019: Merci, bluedid29, pour toute l'équipe de l'édito !
sub26nico, 08:46, mar. 08 Oct 2019: Bonjour et bienvenue à Notabene78, MOA, Gaz Korbier, setkaabwoy, gegeours et Siryu :-)