Chargement...
 
Skip to main content

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


[½ RÉSOLU] Changer l'irq dune carte PCI FireWire

Bonjours à tous.

Je solicite votre aide, car en cherchant sur le net j'ai eu du mal à trouver une technique pour changer l'irq d'un préripherique
Voila j'ai une carte PCI firewire, avec une carte son externe 8piste branché dessu(Presonus FirePod).

Seulement defois j'ai des craquement quand j'ecoute de la musique ou que je change de fenetre.
Apres lecture sur le net, une des solution est de donner une meilleur priorité à ma carte firewire PCI.
Seulement voila, sur windows ça ce fait avec des click, mais sur Linux c'est pas pareil.

J'aimerais passer ma carte son à la meilleur priorité.

Voici le contenu de mes IRQ

[+]

Apres l'avoir changé de port PCI

[+]

Pouvez vous me dire comment passer ma carte PCI firewire sur un meilleur IRQ (lequel ?) et si je peu faire d'autre optimisation IRQ pour ma carte 3D par exemple ?
Merci d'avance
Bonne continuation
jour'

c'est pas dans le bios ça ? tu ne peux manuellement l'attribuer ?
Nan je ne peu pas manuelement l'iattribuer, je n'ai pas de jumper 😑
Pas mal de personne me dise de regarder le bios, mais je n'ai rien trouver de spécial, je vais reregarder, je vous tien au jus
Allemagne
Je pense qu'un tour dans les pages optimisations, va t'aider.
T'as bien un noyau rt qui marche ? quelle distrib et tout.
Alors dans le BIOS, je peu seulement mettre PCI ou Reserved devant les IRQ, je ne peut pas le préciser pour mes periphérique PCI.

En ce qui concerne ma configuration LINUX, j'ai un kernel 2.6.26-1-686 qui n'est pas en réal-time (je vais pas tarder à me le construire) sur une Debian 4.0 unstable.

En tout cas il dise dans la rubrique Optimisation que plus un périphérique et sur un IRQ faible moin il y a de craquement...
Bonjour

De nos jour bidouiller le bios n'apporte plus grand chose sur ce point. La première action est d'autoriser les applications utilisateur à acquérir des priorités temps-réel. Pour debian il faut ajouter ces lignes dans le fichier /etc/security/limits.conf :

Copy to clipboard
# Support Temps réel pour le groupe audio @audio - rtprio 99 @audio - nice -19 @audio - memlock unlimited


et ajouter l'utilisateur au groupe audio :
Copy to clipboard
sudo adduser "utilisateur" audio


puis relancer la session.

Ensuite il faut que les applications utilisent effectivement leurs droits fraîchements acquis, il faut démarrer jack avec l'option temps-réel en cliquant sur la case realtime de l'onglet Setting de Qjackctl ou bien en ajoutant l'otion -R à la ligne de commande.

Arrivé à ce point le fonctionnement peut être satisfaisant si les exigences en terme de latence ne sont pas trop élevées et si l'ordinateur peut éviter les drivers graphiques propriétaires.
Sinon il faut agir au niveau du kernel. Le premier niveau d'action peut consister à le recompiler en positionnant simplement l'option de préemption de l'ordonnanceur sur realtime. Le temps réel obtenu est qualifié de temps réel mou, la latence espérée est de l'ordre de la dizaine de milliseconde. Les avantages de cette solution sont la simplicité et le minimum d'impact sur la distribution, seule une option de compilation est modifiée.
Le deuxième niveau d'action est de patcher le noyau et de le compiler. C'est ainsi que les latences les plus basses sont atteintes voir même dépassées! Mais le travail d'intégration des modifications apportant le temps réel dur n'est que partiellement réalisé pour les noyaux récents. Actuellement le dernier à avoir bénéficié de tous les travaux est le 2.6.24.
Bonjour,

Remonter la priorité de la carte-son avait réglé mes problèmes de Xruns, en effet.
Il faut d'abord lister ces "latency" avec "lspci -v". Tu vas obtenir des valeurs (décimales) pour chaque IRQ.
Tu pourras modifier cette valeur par :
setpci -s xx:xx.x latency_timer=FF (vérifie quand même la syntaxe, c'est vieux...)
où xx:xx.x est le numéro de ta carte (genre 00:04.0) et FF la priorité que tu veux lui attribuer (en hexa...). Mettre FF assure de lui attribuer la valeur maxi.
Si cette manip' résolvait ton problème, tu peux la mettre dans les commandes à lancer au setup de Jack car elle est volatile entre deux démarrages du PC. Ca permet de la lancer dès que tu lances Jack donc dès que tu travailles l'audio.
Bon courage, à+
Ouaah 😬
Alors là chapeau, 2 reponses qui me tombe du ciel comme ça, et en plus pertinente ! Même sur debian-fr il on séché, je vais leurs raporter tout ça quand j'aurais résolu le probleme ! 😉

Voici quand meme le contenue de "lspci -v" pour le firewire
Copy to clipboard
01:0a.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller (rev 46) (prog-if 10 [OHCI]) Subsystem: VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller Flags: bus master, medium devsel, latency 64, IRQ 21 Memory at d2eff800 (32-bit, non-prefetchable) [size=2K] I/O ports at c800 [size=128] Capabilities: Kernel driver in use: ohci1394 Kernel modules: ohci1394


Allé j'aurais certainement fini toute ces manip avant ce week-end (partiel oblige 😑)
Je test tout ça et je vous tien au jus !
Merci encore
Bon alors, deja les partiel, une catastrophe 🙄

En ce qui concerne les modification de /etc/security/limits.conf

Il m'on permi d'enlever les probleme de craquement de son quand je switch de fenétre ou que je solicite l'affichage, c'est génial 😉

Un second probleme est aparu, à vrai dire je ne sais pas si il y etait avant, mais quand je solicite la lecture sur le disque dur par exemple quand je vais dans mon dossier MP3, le temps qu'il cherche ce qu'il y à dans le dossier, le son craque mais vraiment beaucoup, et au bout de 3,4 seconde tout rentre dans l'ordre. Si je recommence c'est la meme chose. Cela vient donc quand je fait des opération de lecture (en écriture je ne sais pas, il faudrait que je test).

En ce qui concerne les modification conseillé par "allany" avec lspci, je n'ai pas encore essayé (c'est peu être la solution)

Si quelqu'un à une idée ?
Byebye