Skip to main content

4 - Toutes les autres applications, les émulateurs...


Jack, Jamulus & Jacktrip

Articles: 98 France
Salut,

Jamulus : outils très connu et open source de Jam online avec GUI. https://jamulus.io

Jacktrip : outils de Jam online sans GUI. Permet aussi de faire un broadcast (ce n'est plus temps réel mais le son doit être plus stable de meilleur qualité.) https://github.com/jacktrip/jacktrip

Au début quand je faisais un test local (sur une machine) avec 5 sessions jamulus et un serveur plus d'autres applications démarré automatiquement par ma session, j'avais quelques XRuns éparses.

Après avoir fait un script qui décharge les modules du noyau inutiles (bluetooth, wifi, printers, webcam, virtualbox) ainsi que les applications inutiles (navigateur internet, applications réseaux sociaux ...), je n'observe plus de XRuns même si periods = 2 alors que periods = 3 est en général conseillé pour les cartes sons USB.

J'ai fait ce dev (rapide) à partir de Librazik3.

Ci-dessous voici des exemples de ces scripts.

J'ai fait un script startMusicSession.sh
Copy to clipboard
#!/bin/bash nmcli radio wifi off # on stoppe le service wifi sudo systemctl stop cups.service # on stoppe le service imprimantes sudo rmmod vboxnetadp vboxnetflt vboxdrv btusb btrtl btintel btbcm bluetooth lp uvcvideo videobuf2_v4l2 videobuf2_common videodev iwlmvm iwlwifi mac80211 cfg80211 # On stoppe les applications inutiles killall Telegram


Et un script stopMusicSession.sh
Copy to clipboard
#!/bin/bash sudo modprobe -a vboxdrv vboxnetadp vboxnetflt bluetooth btusb btrtl btintel btbcm lp uvcvideo videobuf2_v4l2 videobuf2_common videodev cfg80211 mac80211 iwlmvm iwlwifi nmcli radio wifi on # # on redémarre le service wifi sudo systemctl start cups.service # on redémarre le service imprimantes # On redémarre les applications "$HOME/opt/Telegram/Telegram" -workdir "$HOME/.local/share/TelegramDesktop/" -autostart &


Mon but est de faire un test avec des musiciens distants pour voir si avec ces optimisations, j'ai moins de XRuns car j'en avais beaucoup en situation réelles même si le son pour mon groupe est d'une qualité correcte, il contient des artefactes ... Pour le moment !

Je posterai le résultat de mes tests ici.

Si vous êtes intéressés par faire des tests sur ces applications avec moi, signalez-vous. 😊

++ Laurent
Articles: 2797 France
Bonjour Laurent, super programme que tu lances là !
Je suis bien sur tes avancées sur Jamulus au moins.
Articles: 1409
bonjour,
j'ai de mon coté fait aussi pas mal de tests avec jamulus afin de l'utiliser de façon hebdomadaire avec le groupe. Je me suis focalisé sur la latence, en raison de la faible puissance de ma machine client jamulus, et de la mauvaise qualité de ma liaison internet.
J'ai mis le buffer de jack à 2.
Je n'ai pas noté de xruns
On peux partager nos expériences
Articles: 98 France
Ce que j'aimerai bien savoir c'est si l'option fastupdate sur le serveur Jamulus activée par l'option petits tampons réseaux sur le client Jamulus et par un buffer audio à 64 provoque plus de XRuns ou pas. (Je pense que oui)

Auquel cas, je demanderai à certains membres de mon groupe de revenir à 128 pour minimiser les XRuns et pour diminuer le traffic réseau.

On a tous la fibre optique donc la communication est en général bonne même si on a eu des grésillements parfois à certaines de nos sessions (Mais rien d'anormal).
Articles: 98 France
Salut,

Les tests que j'ai fait aujourd'hui rien qu'à deux montre déjà que l'utilisation des petits tampons réseaux sur la session jamulus distante (64) provoque des XRuns sur ma session jamulus locale en 128.

Lorsque la session jamulus distante passe à 128 et décoche les petits tampons réseaux, il n'y a plus de XRuns de mon côté.

Mais je tempère ce résultat pour le moment car on a eu des soucis réseaux. Néanmoins sans en être sûr à 100%, c'est la tendance qui se dégage ...

Je completerai par d'autres tests dans les semaines à venir.
Articles: 1409
Mème constat, les petits tampons réseaux me faisaient des xruns, il ne faut pas les activer. Ça augmente la charge réseau, et celle de ta machine.
Pour Choisir ta config de jack, il faut se reporter au tableau de la doc
https://jamulus.io/fr/wiki/Network-Requirements paragraphe "audio bandwith".
Essaie de rester dans la fourchette de taille de buffers recommandée (64--256) et 48kħz.
Tu pourras jouer avec 2 autres paramètres que sont les tailles des buffers client et serveur jamulus pour affiner tes réglages.

Pour tester ta bande passante internet, utilise les outils listés ci dessous
https://www.bufferbloat.net/projects/bloat/wiki/Tests_for_Bufferbloat/
Fait des tests à divers moments de la journée. Attention de ne pas confondre débit et latence, même si les 2 sont liés.

Il faut aussi que tu utilises un noyau basse latence. Tu peux tester ta config matérielle + noyau + jack avec jack_iodelay.
Articles: 98 France
Salut piratebab,

merci pour les liens.

Tu utilises les tests for bufferbloat sur Debian/Librazik3 ? (Ça ne marche pas out of the box car il ne trouve pas netperf).

Pour mesurer le débit et le ping, j'utilise speedtest-cli.

Copy to clipboard
git clone https://github.com/sivel/speedtest-cli.git cd speedtest-cli python setup.py install

Articles: 1409
ça date un peu, mais oui, j'ai utilisé les tests préconisés. ILs se lancent dans un navigateur.
Par exemple https://www.speedtest.net/
Articles: 98 France
Voici la discussion en anglais sur ce sujet sur le github Jamulus

https://github.com/jamulussoftware/jamulus/discussions/1836

Quelqu'un vient de proposer d'utiliser un audio buffer 64 et mettre le nombre de périodes à 4 dans Jack (au lieu de 128/2). Ce qui permettrait apparemment de bénéficier des bienfaits des petits tampons réseaux sans avoir trop de XRuns du côté de Jack.

À vérifier.
Articles: 2797 France
Comme je l'ai déjà écrit ailleurs, le fait de trop réduire les tampons de JACK font que les tampons de Jamulus augmentent énormément. Du coup, dans ce cas, baisser les tampons de JACK revient à augmenter la latence totale.
Une chose simple pour s'en apercevoir est de regarder les réglages de tampons de gigue dans Jamulus côté machine et côté serveur. à partir d'une certaine valeur de tampon de JACK, les tampons de Jamulus ne diminuent plus ... et même chez moi ils augmentent.
Articles: 98 France
Oui je me souviens mais je me suis dit que :

- 128 par 2 = 256
ou
- 64 par 4 = 256

ça revient au même, non ? En tout cas, qjackctl affiche la même latence.

La seule différence est le traitement par lots de 64 au lieu de 128 qui serait peut-être plus adapté si d'autres membres du groupe utilise un buffer audio de 64 ...

En tout cas, sur mes tests locaux (donc toutes les sessions jamulus avec 64/4), j'observe le résultat suivant:

- sans les optimisations noyaux : Des XRuns éparses mais le nombre de sauts est plus important qu'avec 128/2.
- avec les optimisations moyaux : Pas un seul XRuns une fois que les applications sont connectées.

Donc ai-je des raisons d'être optimiste sur cette proposition ? Le test avec quelqu'un de distant sera déterminant !

EDIT:

Je suis en 64/4 mais je n'ai pas activé les petits tampons réseaux sur ma session de test locale.
Articles: 2797 France
J'ai une installation Linux avec un noyau récent qui utilise l'ordonnancement des tâches en temps réel avec une priorité forte sur l'audio qui passe devant les choses non essentielles au système.

J'ai une interface USB (1.1) donc je configure JACK comme préconisé par les sachants :
48000 / 128 / 3

J'ai la fibre orange + Livebox 5.

J'utilise la version 3.8.0 compilée avec la version du codec Opus intégrée à mon système et les réglages en mono et basse qualité.

Avec tout ça, je me connecte à un serveur Raspberry Pi à 800 km de chez moi (serveur dédié fibre orange Livebox 5 port UDP ouvert dans le pare-feu). L'expérience est très satisfaisante en terme de qualité sonore et je n'ai aucun décrochage.

Les tampons de gigue de Jamulus, qui s'ajustent automatiquement, s'établissent à 2 pour le serveur et 2 en local, parfait pour la plus faible latence possible sans décrochage. Une session à 5 participants (Allemagne France Pays bas) hier confirment la robustesse de la connections.
Articles: 98 France
En ce qui me concerne sur mes tests 128/2 ou 64/4 :

tampon de gigue local (5) serveur (4)

Qualité haute, mono-entrée vers stéréo-sortie

Ce sont à peu près les réglages associés à mon groupe qui utilise la fibre optique et Windows 10 ou Mac.

J'utilise le noyau librazik3 et j'ai installé jamulus 3.8.0 (package officiel Ubuntu)

Copy to clipboard
Linux librazik3 4.19.0-12-lzk-bl-amd64 #1 SMP PREEMPT Debian 4.19.152-1 (2020-10-18) x86_64 GNU/Linux


Mes cartes son sont USB 2.0. La XR18 supporte jusqu'à 128. Je fais mes tests principalement avec la XR18 afin de comparaison.
Articles: 2797 France
Il existe aussi le noyau 5.4 basse latence libraZiK.
Articles: 98 France
Ok merci pour l'info. Je vais l'essayer.

Note : Je ne peux pas installer les drivers virtualbox car il y a un souci avec les headers 5.4 et il me semble que je dois les installer pour compiler les drivers virtualbox. Mais bon c'est accessoire. Je teste le noyau.

Copy to clipboard
sudo apt install linux-headers-5.4.0-0.bpo.4-lzk-rt-amd64 Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Certains paquets ne peuvent être installés. Ceci peut signifier que vous avez demandé l'impossible, ou bien, si vous utilisez la distribution unstable, que certains paquets n'ont pas encore été créés ou ne sont pas sortis d'Incoming. L'information suivante devrait vous aider à résoudre la situation : Les paquets suivants contiennent des dépendances non satisfaites : linux-headers-5.4.0-0.bpo.4-lzk-rt-amd64 : Dépend: linux-kbuild-5.4 (>= 5.4.19-1~bpo10+1) mais il n'est pas installable E: Impossible de corriger les problèmes, des paquets défectueux sont en mode « garder en l'état ».

Articles: 98 France
En effet, ce noyau se comporte mieux.

J'ai pu lancé mon test + Firefox (avec nice +20)

Malgré le chargement des pages internet et un load de certains CPU qui allait parfois jusqu'à 100%, pas un seul XRuns ...

Voici le descriptif de ce noyau:

Copy to clipboard
Linux librazik3 5.4.0-0.bpo.4-lzk-rt-amd64 #1 SMP PREEMPT_RT Debian 5.4.19-1~bpo10+1 (2020-03-09) x86_64 GNU/Linux


Alors qu'avec le noyau 4.19, le navigateur internet lancé de la même façon fait rapidement apparaître des XRuns.

Bravo ! C'est cool. Merci pour le tuyau !

Le noyau 4.19 est PREEMPT et le 5.4 PREEMPT_RT mais je ne sais pas ce que ça implique au niveau des priorités ...
Articles: 2797 France
Bein, tu as installé le noyau temps réel au lieu du basse latence...
Articles: 98 France
Avec le noyau basse latence, l'utilisation de firefox provoque des XRuns que je n'ai pas avec la version rt.

En d'autres termes, j'ai une meilleure expérience avec la version rt du noyau 5.4 que la version bl.
Articles: 98 France
Je ne sais pas si Olivier ou d'autres personnes ont fait des constatations similaires.
Articles: 1409
Sur ma librazik, le noyaux 5.x normal se comportait mieux que les 4.X basse latence.
ais je n'ai pas réussi à trouver dans les changelog des versions kernels ce qui pourrait l'expliquer.
Articles: 2797 France
Je ne comprends pas pourquoi tu n'utilises pas le noyau 5.4 basse latence de LibraZiK. Selon ton matériel, ça pourrait être mieux.
Page: 1/2  [Suivant]
1  2