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

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

Dernier post
Page : 1/2   -   Aller directement à la page : 1  2 

Jack, Jamulus & Jacktrip

eleandar Articles : 97 utilisateur non connecté 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
#!/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
#!/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

jujudusud Articles : 1265 utilisateur non connecté France
Bonjour Laurent, super programme que tu lances là !
Je suis bien sur tes avancées sur Jamulus au moins.

piratebab Articles : 261 utilisateur non connecté
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

eleandar Articles : 97 utilisateur non connecté 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).

eleandar Articles : 97 utilisateur non connecté 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.

piratebab Articles : 261 utilisateur non connecté
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.

eleandar Articles : 97 utilisateur non connecté 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.

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


piratebab Articles : 261 utilisateur non connecté
ç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/

eleandar Articles : 97 utilisateur non connecté 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.

jujudusud Articles : 1265 utilisateur non connecté 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.

eleandar Articles : 97 utilisateur non connecté 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.

jujudusud Articles : 1265 utilisateur non connecté 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.

eleandar Articles : 97 utilisateur non connecté 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)

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.

jujudusud Articles : 1265 utilisateur non connecté France
Il existe aussi le noyau 5.4 basse latence libraZiK.

eleandar Articles : 97 utilisateur non connecté 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.

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 ».


eleandar Articles : 97 utilisateur non connecté 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:

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 ...

jujudusud Articles : 1265 utilisateur non connecté France
Bein, tu as installé le noyau temps réel au lieu du basse latence...

eleandar Articles : 97 utilisateur non connecté 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.

eleandar Articles : 97 utilisateur non connecté France
Je ne sais pas si Olivier ou d'autres personnes ont fait des constatations similaires.

piratebab Articles : 261 utilisateur non connecté
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.

jujudusud Articles : 1265 utilisateur non connecté 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 
Afficher les articles :
Aller au forum :

Documentation [Afficher / Cacher]

Faire un don
[Afficher / Cacher]

Connexion
[Afficher / Cacher]



Mégaphone [Afficher / Cacher]

sub26nico, 09:25, mar. 15 Jun 2021: Bonjour et bienvenue à Hexaal :-)
Ubuntu_Studio_User, 02:29, lun. 14 Jun 2021: Salut à tous...
allany, 12:12, sam. 12 Jun 2021: @tourneriff : merci pour le signalement, c'est fait !
tourneriff, 07:52, sam. 12 Jun 2021: Bonjour à tous ☺ ! Avis aux modos : pourrait-on voir la "joute 16" en cours à l'accueil du site plutôt que l'antique "joute 15"
sub26nico, 14:56, jeu. 10 Jun 2021: Salut et bienvenue à jamesonmount, freerawsound et Loop :-)
ycollet, 10:28, mer. 09 Jun 2021: Cool, un revival de rakarrak ! [Lien]
sub26nico, 22:08, lun. 07 Jun 2021: Bonjour et bienvenue à ArchLinux59, Djobi et gakgakgak :-)
olof, 09:27, lun. 07 Jun 2021: ardour 6.7 build tourne chez moi, mais pas le package 6.6
allany, 14:46, dim. 06 Jun 2021: @r1 : t'as raison : trop c'est trop, ça sature du goulot !
r1, 22:54, sam. 05 Jun 2021: Mon cerveau a bobo à force de faire le gogo sur l'annonce de l'édito !
allany, 11:49, sam. 05 Jun 2021: Z'ont encore abattu un sacré boulot, les poulbots de l'édito ! [Lien]
ycollet, 20:37, ven. 04 Jun 2021: Un article intéressant sur un truc à venir sur USB audio: [Lien]