Chargement...
 
Skip to main content

1 - Le matériel et les pilotes ALSA, FFADO, ...


[résolu] xruns : impossible de descendre en latence - M audio Mobile Pre

Salut

J'ai besoin d'un coup de main parce que j'arrive pas vraiment a descendre ma Latence en dessous de 16ms et encore ça fait déjà pas mal de xruns. C'est malheureusement problématique pour s'enregistrer. Impossible de faire une prise de 2min sans xruns...

Voici ma config :

Pour info, j'ai un copain qui a la même config, meme carte son et lui il tourne à 8ms sans aucun xruns.

J'essaye d'utiliser Jdelay mais ca n'a pas trop l'air de marcher. Lorsque je fais les connexions, j'ai bien un son mais Jdelay me renvoit toujours
Copy to clipboard
Signal below threshold...


Toute aide sera GRANDEMENT appréciée parce que là, j'en ai un peu marre ! 😀

vala
merci d'avance !
jy
France
Coucou 😉
  • carte vidéo : nvidia GeForce 9600 (apparement ca peu deconner avec nvidia)

T'as essayé en changeant ton pilote pour mettre un vesa de base ?
Juste histoire de voir si c'est par là que les problèmes arrivent...

Autres pistes :
  • t'as beaucoup de Xruns avec ta puce-son interne ?
  • essayer avec un autre kernel genre celui de la 8.04

C'est tout ce que je vois comme ça vite fait ...

++ Olivier
T'as essayé en changeant ton pilote pour mettre un vesa de base ?
Juste histoire de voir si c'est par là que les problèmes arrivent...
Ben j'utilise le pilote recommandé (avec accélération graphique). C'est quoi un vesa de base ?

Autres pistes :
* t'as beaucoup de Xruns avec ta puce-son interne ?

Moins mais ça reste sensible. En fait pour enregistrer je suis obligé d'utiliser la carte USB, et c'est vraiment là que j'ai besoin de peu de Latence.
  • essayer avec un autre kernel genre celui de la 8.04

Est-ce que ça veut dire qu'il faut que je change d'OS ou je peux garder Karmic et juste changer le noyau.


Merci en tout cas, je vais tester ça ce soir... 😀
jy
Hello,

- regarde d'abord du cote de tes IRQs:
Copy to clipboard
cat /proc/interrupts


- verifie que ta carte son ne partage son IRQ avec par exemple un device WIFI
- le "power management" peut aussi interferer avec l'audio processing. As-tu configure ton PC (kernel) avec l'Intel speedstep ? Utilise l'application cpufreq-set (ou quelque chose comme ca):
Copy to clipboard
cpufreq-set -c 0 -g performance cpufreq-set -c 1 -g performance


ca va neutraliser les variations de CPU clock et utiliser la frequence maximale de tes 2 CPU cores. Bien sur, ca consomemra plus d'energie 😉

- maintenant, la question qui tue: pourquoi tu veux obtenir une Latence faible ? fais-tu du live ? utilises-tu des effets software en realtime pour monitoring ?

- dans le mesure ou tu as effectivement besoin d'une latence tres basse, il te faut:

- un IRQ non partage pour ta carte son
- ne pas utiliser de WIFI si possible
- une configuration utilisateur specifique pour avoir acces au RT-scheduling (cf. assure-toi que /etc/security/limits.conf est bien configure)

Mon experience est que le driver proprio de nVidia n'a aucune incidence. Je n'utilise pas Ubuntu et ses paquets mais debian sid / sidux. En outre, je compile moi-meme le driver nVidia. Mon kernel n'est pas patche avec le RT patch, pas vraiment besoin. J'utilise le kernel 2.6.32 avec l'option HIGHMEM64 (pour pouvoir utiliser plus que 3.5GB de RAM en architecture 32bit) et PREEMPTION. Les versions tres recentes du kernel sont impressionantes "out-of-the-box" pour leur stabilite et performance audio.

De maniere generale, je prefere "tweaker" mon system a partir d'une configuration minimaliste que d'installer une distribution supposee tout faire a ma place. Mais c'est mon choix bien sur 😊

EDIT: je viens de voir ta config jack. J'ai comme l'impression que tu n'utilises pas la bonne carte son (ton interface USB).

Verifie avec
Copy to clipboard
cat /proc/asound/cards


Si tu as 2 interfaces (interne et externe), j'imagine que tu veux utiliser l'externe (USB).

Dans la config jack, utilise le nom de l'interface affichee avec la commande precedente (cat) entre crochets , precedee de "hw:" :

hw:nom_de_la_carte_affichee_dans_/proc/asound/cards

- ne force pas 16bit
- coche le RT mode (cette option depend de la config /etc/security/limits.conf) ou "Temps reel" en francais, et utilise une priorite de 70 (au lieu de 89)
D'abord, merci des tuyaux 😀

Hello,
- regarde d'abord du cote de tes IRQs:
cat /proc/interrupts
- verifie que ta carte son ne partage son IRQ avec par exemple un device WIFI

Ca a l'air d'etre bon, tu confirmes ? Log ci dessous (replié)

[+]
- le "power management" peut aussi interferer avec l'audio processing. As-tu configure ton PC (kernel) avec l'Intel speedstep ? Utilise l'application cpufreq-set (ou quelque chose comme ca):
Copy to clipboard
cpufreq-set -c 0 -g performance cpufreq-set -c 1 -g performance


ca va neutraliser les variations de CPU clock et utiliser la frequence maximale de tes 2 CPU cores. Bien sur, ca consomemra plus d'energie 😉

ok je vais tester ça. Comment faire pour revenir a la config originelle si je veux y revenir ?
- maintenant, la question qui tue: pourquoi tu veux obtenir une latence faible ? fais-tu du live ? utilises-tu des effets software en realtime pour monitoring ?
pour une utilisation duplex principalement. A 16ms, je trouve la Latence un peu désagreable. Je prégèrerai déscendre un peu.
- une configuration utilisateur specifique pour avoir acces au RT-scheduling (cf. assure-toi que /etc/security/limits.conf est bien configure)

Oui oui, les accès sont déjà bien donnés. Merci.

EDIT: je viens de voir ta config jack. J'ai comme l'impression que tu n'utilises pas la bonne carte son (ton interface USB).
J'ai pris l'image de ma config carte son intégrée. Désolé. Ceci dit, c'est sensiblement la même que pour la mobilePre. Le 16 bits n'est d'ailleurs pas forcé normalement. c'est une erreur.

utilise une priorite de 70 (au lieu de 89)

pourquoi ?

Question : comme j'ai un core2duo, est-ce que ca vaudrait pas le coup de passer sur jack2 ?

jy
16: 1978 1973 IO-APIC-fasteoi uhci_hcd:usb3, nvidia


Je ne sais pas comment une interface audio USB apparait vraiment dans /proc/interrupt mais il me semble que ta nvidia partage l'IRQ avec au moins un device USB (?) Par contre, ta carte interne (Intel HDA) est toute seule ...


pour une utilisation duplex principalement. A 16ms, je trouve la latence un peu désagreable. Je prégèrerai déscendre un peu.

tu fais du monitoring en mode "software" ? si oui, alors pour etre confortable, ~ 5ms est acceptable. Au dela, ca devient trop genant.


utilise une priorite de 70 (au lieu de 89)

pourquoi ?


parce que 89 semble eleve. Si tu utilises un kernel avec RT patch, il y a des process threads qui demandent plus de priorite que l'audio thread de jackd (les soft-irq threads et les timer threads).

Question : comme j'ai un core2duo, est-ce que ca vaudrait pas le coup de passer sur jack2 ?


oui et non. J'utilise jack2 aussi avec un Core 2 Duo et ca marche tres bien. Jack2 peut balancer les process load (depend de certaines options et quel code source tu as choisi - branche experimentale ou non) mais il reste tout de meme qu'un programme comme ardour n'utilise qu'UNE audio thread. Paul Davis prevoit de bricoler un mechanisme multithread pour l'audio dans ardour et il y a des discussions sur la mailing list de jack sur la question (plus ou moins en rapport avec la question de clients concourants, etc). Mais c'est pas pour demain ...

Pour le cpufreq, regarde si tu as un fichier init /etc/init.d/cpufreq* (je me rapple plus exactement). Tu peux revenir a ta configuration avec
Copy to clipboard
sudo /etc/init.d/cpufreq restart


ou bien, si tu as une GUI applet connectee au daemon powersaved / powerdevil ou je sais pas trop comment ca s'appelle de nos jours, tu peux toujours revenir a une configuration "dynamique" (CPU clock ajustee selon la demande / load). Pour le travail en RT-audio, il est preferable de desactiver la chose et rester en mode "performance".
Ben j'utilise le pilote recommandé (avec accélération graphique). C'est quoi un vesa de base ?

C'est un driver pour carte graphique standard, mais sans accélération 3D, enfin, je crois... 😉
Waaaaouuuu

super merci de ces précisions. je vais tester ca bientot.
je vous tiens au courant.
tu fais du monitoring en mode "software" ?

qu'est ce que t'entends par là ? que tout se fait en soft ? parce que c'est souvent le cas (hydrogen + ardour) et beaucoup moins du monitoring physique (enrregistrement d'un instrument). meme si ce dernier va devenir de plus en plus important.

@yanshee : ok c'est noté merci 😀

jy
Hello !

J'opterais aussi pour la piste de Thorgal : les IRQ...
Pourrais-tu poster le résultat d'un :
Copy to clipboard
lspci -v

afin de voir si tu n'as pas d'interrupts partagées ?
L'affichage-écran peut, en effet y être pour quelque chose, s'il y a conflit d'IRQ.
As-tu le script rtirq installé ? Tu dois, je crois, pouvoir le vérifier avec Synaptic.

A+tard...
Salut Allany

J'ai rtirq-init installé et voici le retour de lspci -v

[+]
Je te mets aussi le retour de car /proc/interrupt

[+]
Merci beaucoup 😀

jy
Bonjour,

En effet, les IRQ sont bien attribuées dans le bon ordre.
Ce qui me surprend, par contre, c'est que les priorités (latency) sont toutes au même niveau (0).
Ca peut signifier que lorsque tu travailles sur ton périphérique audio, n'importe quel évènement sur un autre périph' interrompra le traitement (affichage, réception wifi,etc...) et provoquera craquements et/ou xruns.
Je n'en suis pas certain à 100% (bizarre que tout soit à 0, c'est peut-être voulu ?...) mais ça vaudrait le coup de faire un test qui, de toute façon, est sans danger et volatil au prochain reboot.
Si tu veux, essaie de faire :
Copy to clipboard
sudo setpci -s 00:1b.0 latency_timer=8E


Le 00:1b.0 est l'adresse (donnée dans lspci) de ta carte-son (HDA) et 8E la valeur de priorité maximum (134 en décimal).

Une fois ce test effectué, si rien ne change, je déconnecterais puis déchargerais les drivers wifi (-+sudo ifdown ethxx / sudo modprobe -r ethxx+-, etc...) lorsque je fais de l'audio.

Chez moi, je me suis écrit un script shell avec ces commandes et depuis, je descends à 5ms sans xruns alors qu'avant, je plantais carrément après quelques centaines de xruns...
J'espère que ça sera idem chez toi...

Bon test,
A+tard
salut

ok je note tout ca, je ferai un test bientot.
en revanche je viens de me rendre compte que ma carte USB M-Audio mobilePre n'apparait pas.
Je suppose qu'on y a accès par les ports USB mais je ne comprends pas trop comment voir cette carte.
Donc la question se résume à :
puis-je faire la meme chose pour ma carte audio externe USB ?
si oui comment la reconnaiter ?

Merci beaucoup!!

jy
en revanche je viens de me rendre compte que ma carte USB M-audio mobilePre n'apparait pas.
...

si oui comment la reconnaiter ?


salut jy,

c'est ce qui m'a intrigue lorsque tu as copie-colle /proc/interrupt apres mon 1er message. Je n'ai pas vu d'elements indiquant quelle IRQ ta carte USB utilise.
Donc, pourrais-tu poster l'output de
Copy to clipboard
cat /proc/asound/cards


Ce fichier ALSA 'proc' contient toutes tes cartes son reconnues par ALSA.

Ensuite, pourrais-tu poster l'output de
Copy to clipboard
lsusb


Ca va lister les devices connectes aux differents ports USB de ton systeme.

J.
salut Thorgal

je précise que j'avais raté ma manip la première fois, ma carte USB n'était pas branchée donc il est normal que tu ne trouves que la carte intégrée.
En revanche j'ai bien fait attention à la brancher pour obtenir les logs de cat /proc/interrupt et de lspci -v dans ce post.

Je ferais la manip cat /proc/asound/cards ce soir et je posterai le log en complétment.

Désolé pour le quiproquo.

jy
Ouaip !

Je m'étais fait la même réflexion : pas de carte son USB, alors que tu en parlais plus haut..
C'est pour ça que je t'ai indiqué la manip' avec ta HDA intégrée...
Mais l'opération est valable avec une USB, il suffirait de changer ton 0:1b.0 par l'adresse de même format qui correspondra à L'USB quand elle apparaîtra par lspci.

A+tard.

Édition (admin olinuxx) : Sujet passé en mode captivant.
Pour des conseils sur le fonctionnement général du forum, vous pouvez voir cette page.

alors attends je crois que je n'ai pas été très clair...
les logs présents dans le post de mer. 20 janv. 2010 19:42 ont été réalisés avec la carte USB branchée !

ca veut dire que la carte n'est pas reconnue intégralement ?

jy
ca veut dire que la carte n'est pas reconnue intégralement ?


verifie quand tu peux ce que j'ai precise plus haut (-+/proc/asound/cards+- et lsusb apres avoir boote avec ta carte branchee).
salut

alors voilà
j'ai démarré ma machine avec ma carte USB branchée.
Ma carte est une M-Audio mobilePre USB.

Voici les retour des différentes commandes :

lsusb

[+]
cat /proc/asound/cards

[+]
cat /proc/interrupt

[+]
lspci -v

[+]
Voilà, je rappelle les autres infos :

Merci beaucoup de regarder ça! Vous êtes trop mais alors TROP sympas 😀

jy
Hello, JY,

Bon , perso, y'a un truc que je trouve encore bizarre.
Tu as ta carte qui est bien identifiée dans le /proc/asound/cards en :

Copy to clipboard
1 [MobilePre ]: USB-Audio - MobilePre M Audio MobilePre at usb-0000:===00:1d.2-2===, full speed


qui correspond, dans ton lspci à :

00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)

ce qui ne ressemble pas à une carte son ???
Le 00:1d.2-2 me surprend car je n'ai jamais vu de suffixe, même avec un hub USB... On dirait que la reconnaissance s'arrête au hub...
Je suis peut-être bigleux mais je ne vois pas, non plus, la carte dans le /proc/interrupts.

Tu as vu, sur un autre post, que je n'ai pas toujours les bonnes recettes mais j'essaierais, pour isoler le problème, de déconnecter tout ce qui n'est pas utile aux tests de son et de lister à nouveau ces quelques commandes. En branchant la carte sur un port du PC, directement.

A+tard
salut Allany

ok ben pour toutes ces manip' en fait, j'ai que la carte USB M-Audio mobilePre qui est branchée et une souris USB. La voici :
Copy to clipboard
Bus 007 Device 002: ID 046d:c00e Logitech, Inc. M-BJ58/M-BJ69 Optical Wheel Mouse

Je précise que j'ai un ordinateur portable.
Veux-tu que je recommance toute la manip' sans la souris ?

Merci
jy
Non. Ce que je voulais dire, c'est que si tu as un hub USB externe, tu devrais peut-être tenter de l'enlever et de connecter la carte son directement sur un port USB de l'ordi.
Par contre, j'avoue ne rien connaitre en portables.
Après, ce que je ferais chez moi, c'est essayer de décharger les pilotes réseau par modprobe -r.
Ce que je constate, aussi, c'est que t'as vachement d'IRQ (14, je crois). Faudrait peut-être mettre le nez dans le script rtirq pour voir s'il n'y a pas une limite (improbable, je crois me souvenir qu'il fonctionne par incrément).
Je suis en train de penser que lspci (comme son nom l'indique) n'est peut-être pas adaptée pour les portables (pcmcia). Peux-tu le vérifier car il faut que j'aille essayer de dépanner mon propre bouzin...
Bon courage, à+
Jacques.
Page: 1/3  [Suivant]
1  2  3