Utilisation du bus Pci : essuyez les petites fesses irritées

[Stéphane.P]

Bonjour,

Je suis nouveau sur le forum, mais je lis x86 depuis un bon moment.
Mon domaine d'activité est l'informatique (étonnant ça ! ), mais spécialisé dans l'audio, c'est à dire que je monte des configs pour les studios, les musiciens etc...
Les nécéssités pour les utilisateurs sont le temps réel, enfin le plus proche possible du 0 latence, de grosses capacités de stockage (certaines banques de sons dépassent les 200Go), beaucoup de mémoire vive (2Go ca devient juste).
En fait, en ayant monté pas mal de machine différentes, je me suis rendu compte qu'un facteur de performance très important dans ce domaine n'était jamais mis en valeur dans les différents tests qu'on trouve sur le Web : L'utilisation du bus Pci.
En effet, de nombreux périphériques, de nombreuses cartes ont tendance à vampiriser les ressources du bus, des cartes réseaux, des cartes Udma, des cartes graphiques.
Exemple :
La carte mère Asus P4C800-E Deluxe dispose d'un controleur réseau en CSA, et celui-ci lorsqu'il est actif (même s'il n'y a pas de transferts) oblige à augmenter les temps de latence des cartes audio, sous peine de "craquements" dans le son.
Ce problème n'existe pas si on utilise la P4C800 Deluxe.
On retrouve ce genre de problème dans des situations assez différentes.
Un autre exemple :
Sur de nombreux portables Dell, lorsqu'on utilise une carte audio avec pas mal d'entrées/sorties branchée sur le port pcmcia ET un disque dur Firewire, le flux de donnée du disque dur externe perturbe l'audio, comme si il y avait un goulet d'étranglement au niveau du bus pci puisque si je me rappelle bien, le pcmcia et le firewire sont tous les 2 raccordés au Pci.

J'en viens à ma question :
Comment mettre en valeur ce genre de problème avec des tests ?
Il y a-t-il des moyens logiciels pour visualiser l'impact d'une carte sur le bus Pci ?

En espérant que j'ai été suffisamment clair dans mes questions

______________________
Stéphane

[ririck]

Ce que je peux dire c'est que pour le firewire, c'est assez orienté temps réel, que qui pourait être pratique pour une carte son externe sur un portable (Mais, j'ai pas encore vu de carte son firewire. )
Mais pour ton genre de config, un disque sur Firewire, c'est pas bien car le port utilisera les ressources nécessaire en priorité pour approcher le temps réel, et limite ainsi le reste du bus PCI.

Pour la mesure des tranferts et latence du PCI, j'ai pas trop d'idées, désolé.

Pas contre j'ai aussi une question : Mon frère utilise son PC pour mixer, le PC est branché à une table, puis à un ampli 2*200W, mais quand il monte le son de l'ampli, une carte (la SBlive 5.1 platinium) renvoie un signal : une sorte d'onde radio dont on peut distinguer de la voix. Il veut changer sa carte son. Il réencode aussi ses vinils en Wave mais la qualité de la SBlive lui suffit pas.
Tu lui conseillerai quoi ? (dans les 100 ~ 200 € voir un peu plus)

[Stéphane.P]

Ce que je peux dire c'est que pour le firewire, c'est assez orienté temps réel, que qui pourait être pratique pour une carte son externe sur un portable (Mais, j'ai pas encore vu de carte son firewire. )
Mais pour ton genre de config, un disque sur Firewire, c'est pas bien car le port utilisera les ressources nécessaire en priorité pour approcher le temps réel, et limite ainsi le reste du bus PCI.

En fait, dans le cas du disque firewire, le même genre de configuration mais sur un poste fixe fonctionne parfaitement, et c'est parfois le cas aussi sur certains portables.
Pour les cartes audio firewire, il en existe plusieurs modèles, mais leurs performances ne sont pas meilleures qu'en Pci. Cela me semble logique puisque le firewire passe par le bus pci (sauf erreur de ma part).

Il veut changer sa carte son. Il réencode aussi ses vinils en Wave mais la qualité de la SBlive lui suffit pas.
Tu lui conseillerai quoi ? (dans les 100 ~ 200 € voir un peu plus)

Heuu, pour moi, les créative, heuuu ben....... comment dire ....
Disons que je ne considère pas ça comme une interface audio, c'est juste bon pour le multimédia.
Les modèles que je connais commencent plutôt dans la gamme des 250-300 euros, comme l'audiophile 2496 de M-Audio, la Mia de Echo Audio.
Par contre, attention, ces cartes sont de très bonne qualité, mais sont aussi très dépouillées au niveau des caractéristiques d'entrée sorties.
Pour les 2 modèles dont j'ai parlé, il n'y a que 2in/2out au niveau ligne, 1in/1out midi et 1in/1out Spdif en coax.
Pas de préamp, de wavetable, de fonctions Eax ou autres trucs dans le genre, et souvent elles ne fonctionnent pas très bien avec les jeux.

Sinon, il y a aussi quelques modèles chez Audiotrak et Terratec qui sont un peu des intermédiaires, mais je ne les connais pas très bien.

__________________
Stéphane

[ririck]

Creative, pas bien ? :D C'est ce que je lui avais mis il y a trois ans en assemblant son PC ; mais en branchant une guitare électrique un peu après, on a été (très) décu. En plus, il utilise plus que l'entrée et sortie jack 6.25", donc le 5.1, l'eax, et tout le reste lui sont inutile ; comme pour le préampli car la sortie casque de la table est déjà équipée.
par contre la compatibilité Reason et Rebirth ça devrait lui plaire
En plus, les drivers ont l'air d'être mis à jours régulièrement.
Reste juste cette "erreur de conversion" : 199 $ ~ 277 €

[Filou]

La carte mère Asus P4C800-E Deluxe dispose d'un controleur réseau en CSA, et celui-ci lorsqu'il est actif (même s'il n'y a pas de transferts) oblige à augmenter les temps de latence des cartes audio, sous peine de "craquements" dans le son.

Ca c'est pour le moins étrange, vu qu'Intel a fait pas mal de pub en disant que le CSA est connecté directement au Northbridge, justement pour éviter de perturber et d'être perturbé par le PCI et le Southbridge! uch:

[Doc TB]

Le CSA, c'est un moins commercial. Techniquement, c'est un 2e bus Hub-Link 1.5 dédié au controleur lan. ni plus, ni moins. Si il y a des problemes d'interferences, c'est le layout de la carte qui est en cause et pas le bus en lui meme

[Stéphane.P]

Le CSA, c'est un moins commercial. Techniquement, c'est un 2e bus Hub-Link 1.5 dédié au controleur lan. ni plus, ni moins. Si il y a des problemes d'interferences, c'est le layout de la carte qui est en cause et pas le bus en lui meme

Je ne sais pas ce qui est exactement en cause dans cet exemple, je n'ai pas les connaissances technique pour parvenir à une conclusion.
L'histoire de la P4c800-E Deluxe est un exemple parmi d'autres.
Pour continuer sur les cartes réseaux, les petites realtek à 15 euros fonctionnent parfaitement, enfin je veux dire qu'elles ne perturbent pas l'audio, par contre sur des modèles plus "costauds" comme certaines 3com, c'est une catastrophe, on peut se retrouver obligé de doubler le temps de latence pour arriver ne plus avoir de craquement dans l'audio.
Il y a quelques temps, il y avait aussi le chipstet VIA KT133 qui était presque inutilisable en audio.

Bref, il n'y a toujours personne qui verrait une solution pour mettre en valeur ou détecter ce genre de soucis ?

____________________________
Stéphane

[fennec]

Le CSA, c'est un moins commercial. Techniquement, c'est un 2e bus Hub-Link 1.5 dédié au controleur lan. ni plus, ni moins. Si il y a des problemes d'interferences, c'est le layout de la carte qui est en cause et pas le bus en lui meme

Bref, il n'y a toujours personne qui verrait une solution pour mettre en valeur ou détecter ce genre de soucis ?

____________________________
Stéphane

c'est assez étrange comme problème. Je pense que le mieux est d'écrire a Asus et aux constructeur des cartes son. Tu leur envoie le même mail en copie non cachée, comme ça ils se renvoient la balle entre eux il le ferront directement.. Explique aussi que tu brasse beaucoup de sous et de matos "PRO" ça va les motiver.

Je ne pense pas qu'il soit possible de pouvoir prévoir tes problèmes. Souvent les cartes PRO utilisent les bus de façons "non-standard" ou en s'appuiyant sur des normes de qualité plus élévée que la moyenne. Asus est une marque de qualité mais pas du matos "PRO" et je pense que comme les autres (Abit, gigabye, MSI ...) ils s'écratent plus ou moins des normes établies afin de grapiller quelques points aux différents "MerdierMark2222".

Pour éviter ce genre de problème il faudrait se tourner vers des marques comme Tyan ou intel qui en plus de respecter les specs font des tests au niveau des perturbations magnétiques et electroniques.

[Franck@x86]

On a déjà parlé de ça, mais bon y'a longtemps.

Le bus PCI est partagé par les différents devices PCI, et chaque device est susceptible de passer maître du bus si besoin (c'est le bus mastering).
Le PCI latency timer définit le temps en cycles durant lequel un device s'approprie le bus PCI. Cette valeur est différente pour chaque device, car tous n'ont pas les mêmes besoins en bande passante. Une carte vidéo par exemple a une valeur de timer assez haute, car c'est un des éléments qui a le plus besoin de BP.

Cette valeur est fixée pour chaque device par son driver. S'il n'y a pas de driver ou que celui-ci ne le fixe pas, le système utilise la valeur par défaut que tu fixes dans ton BIOS.
Pour savoir la valeur utilisée par chacun de tes périphériques, lance cpu-z et sauve le PCI Device List. Pour chaque device, la valeur du timer est à l'offset D, sur la première ligne.

Vous remarquerez que beaucoup de device ont une latence nulle, notamment ceux intégrés à la carte mère. Cela provient du fait que ces device n'utilisent en réalité pas le bus PCI mais un bus propriétaire (cf les docs Intel à ce sujet).
Pour les autres, les valeurs varient en général de 32 (carte son, port US à 248 (carte graphique).

Comment régler la valeur dans le BIOS ?
A priori plus la latence est basse, moins un device va monopoliser longtemps le bus, les device vont ainsi se passer le flag de maître plus rapidement. Attention cependant, car si la valeur est trop basse le device n'aura pas le temps de terminer son travail et il devra reprendre la main plus tard, ce qui peut au final ralentir les choses.

Sur certains chipsets VIA, une latence trop basse provoquait des conflits entre les device, et les fameux 4in1 sortis à raison de 1 version par jour corrigeaient en partie le problème en augmentant la latence.

Pour les puristes, chaque device peut être réglé différemment avec WPCREDIT par exemple. La règle de base est que plus le device est gourmand en BP, plus la latence doit être élevée.

[Stéphane.P]

c'est assez étrange comme problème. Je pense que le mieux est d'écrire a Asus et aux constructeur des cartes son. Tu leur envoie le même mail en copie non cachée, comme ça ils se renvoient la balle entre eux il le ferront directement.. Explique aussi que tu brasse beaucoup de sous et de matos "PRO" ça va les motiver.

A ma connaissance, Rme était entré en contact avec Dell pour les problèmes de goulet d'étranglement entre le pcmcia et le firewire dont je parlais plus haut. A priori, rien n'a été résolu, et ça ne m'étonne pas vraiment, le marché audio pro est tellement minuscule...

Je ne pense pas qu'il soit possible de pouvoir prévoir tes problèmes. Souvent les cartes PRO utilisent les bus de façons "non-standard" ou en s'appuiyant sur des normes de qualité plus élévée que la moyenne. Asus est une marque de qualité mais pas du matos "PRO" et je pense que comme les autres (Abit, gigabye, MSI ...) ils s'écratent plus ou moins des normes établies afin de grapiller quelques points aux différents "MerdierMark2222".

Pour éviter ce genre de problème il faudrait se tourner vers des marques comme Tyan ou intel qui en plus de respecter les specs font des tests au niveau des perturbations magnétiques et electroniques.

Si il suffisait de bien choisir la carte mère pour éviter ce genre de soucis, tout serait bien plus facile, mais comme je le disais un peu plus haut, le souci peut venir d'une carte réseau, d'une carte graphique, d'un adaptateur scsi, d'un contrôleur Udma additionnel.
Parfois une seule carte peut légèrement déteriorer les perfs, mais sans qu'on ne s'en rende vraiment compte.
Sinon, la solution, c'est de tout enlever, et de remettre les cartes une à une, en vérifiant comme on peut les performances audio à chaque fois.
Ca fait un peu artisanal comme méthode, ce n'est pas très fiable et c'est TRES long.

Bref, j'ai comme l'impression que personne ne connait de solution logicielle pour tester ce genre de chose.
Donc, j'ai une autre question, est ce que quelqu'un a déjà eu l'occasion de tester les analyseurs de bus pci hardware ? Si oui, est ce que selon vous ce genre de matos pourrait m'aider à détecter des utilisations excessives du bus pci ?

_________________________
Stéphane

[pitbac23]

On a déjà parlé de ça, mais bon y'a longtemps.

Le bus PCI est partagé par les différents devices PCI, et chaque device est susceptible de passer maître du bus si besoin (c'est le bus mastering).
Le PCI latency timer définit le temps en cycles durant lequel un device s'approprie le bus PCI. Cette valeur est différente pour chaque device, car tous n'ont pas les mêmes besoins en bande passante. Une carte vidéo par exemple a une valeur de timer assez haute, car c'est un des éléments qui a le plus besoin de BP.

Cette valeur est fixée pour chaque device par son driver. S'il n'y a pas de driver ou que celui-ci ne le fixe pas, le système utilise la valeur par défaut que tu fixes dans ton BIOS.
Pour savoir la valeur utilisée par chacun de tes périphériques, lance cpu-z et sauve le PCI Device List. Pour chaque device, la valeur du timer est à l'offset D, sur la première ligne.

Vous remarquerez que beaucoup de device ont une latence nulle, notamment ceux intégrés à la carte mère. Cela provient du fait que ces device n'utilisent en réalité pas le bus PCI mais un bus propriétaire (cf les docs Intel à ce sujet).
Pour les autres, les valeurs varient en général de 32 (carte son, port US à 248 (carte graphique).

Comment régler la valeur dans le BIOS ?
A priori plus la latence est basse, moins un device va monopoliser longtemps le bus, les device vont ainsi se passer le flag de maître plus rapidement. Attention cependant, car si la valeur est trop basse le device n'aura pas le temps de terminer son travail et il devra reprendre la main plus tard, ce qui peut au final ralentir les choses.

Sur certains chipsets VIA, une latence trop basse provoquait des conflits entre les device, et les fameux 4in1 sortis à raison de 1 version par jour corrigeaient en partie le problème en augmentant la latence.

Pour les puristes, chaque device peut être réglé différemment avec WPCREDIT par exemple. La règle de base est que plus le device est gourmand en BP, plus la latence doit être élevée.

je ne sais pas pour vous mais quand franck parle on comprend tout tellement il explique bien
je te remercie de toute les informations que tu mets a notre disposition continue

:jap: :jap: :jap:

[Filou]

je ne sais pas pour vous mais quand franck parle on comprend tout tellement il explique bien

C'est parce qu'il a la patience de son âge pour expliquer :wink:

[bjone]

De manière générale, il faut fuir les cartes mères qui ont un contrôlleur IDE ou LAN intégré, mais sur le PCI. (c'est plus généralement le cas des cartes mères pour Athlon malheureusement).

Sinon bah, le PCI Express devrait permettre d'éliminer ce genre de problèmes...

[bjone]

c'est assez étrange comme problème. Je pense que le mieux est d'écrire a Asus et aux constructeur des cartes son. Tu leur envoie le même mail en copie non cachée, comme ça ils se renvoient la balle entre eux il le ferront directement.. Explique aussi que tu brasse beaucoup de sous et de matos "PRO" ça va les motiver.

A ma connaissance, Rme était entré en contact avec Dell pour les problèmes de goulet d'étranglement entre le pcmcia et le firewire dont je parlais plus haut. A priori, rien n'a été résolu, et ça ne m'étonne pas vraiment, le marché audio pro est tellement minuscule...

Je ne pense pas qu'il soit possible de pouvoir prévoir tes problèmes. Souvent les cartes PRO utilisent les bus de façons "non-standard" ou en s'appuiyant sur des normes de qualité plus élévée que la moyenne. Asus est une marque de qualité mais pas du matos "PRO" et je pense que comme les autres (Abit, gigabye, MSI ...) ils s'écratent plus ou moins des normes établies afin de grapiller quelques points aux différents "MerdierMark2222".

Pour éviter ce genre de problème il faudrait se tourner vers des marques comme Tyan ou intel qui en plus de respecter les specs font des tests au niveau des perturbations magnétiques et electroniques.

Si il suffisait de bien choisir la carte mère pour éviter ce genre de soucis, tout serait bien plus facile, mais comme je le disais un peu plus haut, le souci peut venir d'une carte réseau, d'une carte graphique, d'un adaptateur scsi, d'un contrôleur Udma additionnel.
Parfois une seule carte peut légèrement déteriorer les perfs, mais sans qu'on ne s'en rende vraiment compte.
Sinon, la solution, c'est de tout enlever, et de remettre les cartes une à une, en vérifiant comme on peut les performances audio à chaque fois.
Ca fait un peu artisanal comme méthode, ce n'est pas très fiable et c'est TRES long.

Bref, j'ai comme l'impression que personne ne connait de solution logicielle pour tester ce genre de chose.
Donc, j'ai une autre question, est ce que quelqu'un a déjà eu l'occasion de tester les analyseurs de bus pci hardware ? Si oui, est ce que selon vous ce genre de matos pourrait m'aider à détecter des utilisations excessives du bus pci ?

_________________________
Stéphane

Mon frère pourrait ramener ça (oscillo numériques couplable à un analyseur logique :D), mais bon oublies ça coûtes entre 2K€ et 15€ du matos comme ça.

[Filou]

De manière générale, il faut fuir les cartes mères qui ont un contrôlleur IDE ou LAN intégré, mais sur le PCI.

Euh ça, ce n'est plus le cas depuis longtemps pour l'IDE, non? A part quand tu as un contrôleur RAID externe mais bon on peut le désactiver.

[Stéphane.P]

1 an plus tard...........

Hé bé, je pensais pas que j'avais décroché de l'informatique aussi longtemps.

Pour les puristes, chaque device peut être réglé différemment avec WPCREDIT par exemple. La règle de base est que plus le device est gourmand en BP, plus la latence doit être élevée.

J'avais regardé WPCREDIT, mais je le trouvais assez compliqué à utiliser, alors je ne sais pas si ça peut intéresser certaines personnes, mais je viens de trouver un autre utilitaire assez simple qui permet de visualiser et modifier les valeurs de latence des différents périphériques, ça s'appelle DoubleDawg, et on le trouve ici : http://www.mark-knutson.com/t3/

[Danmusicfirst]

un an déjà.....
j'ai à qque chose près le même problème qui peut peut etre venir du LAN intégré, j'explique:
-j'ai 2 bécanes en réseau, sur la première j'utilise 2 cartes Creamware (carte mère P4G8X deluxe) et j'utilise le fameux FX TELEPORT qui permet en fait apres avoir installé des VST plugins sur la bécane N°2 de pouvoir en théorie "rapatrier" ces flux audio sur la premiere becane(hôte) via le LAN (Gigabit conseillé), soulageant la bécane Hôte de la charge de calcul.
-et bien ma bécane Hôte à le CPU qui s'accroit comme si les plugs étaient installés sur celle-ci à ma grande désolation!

[Stéphane.P]

un an déjà.....
j'ai à qque chose près le même problème qui peut peut etre venir du LAN intégré, j'explique:
-j'ai 2 bécanes en réseau, sur la première j'utilise 2 cartes Creamware (carte mère P4G8X deluxe) et j'utilise le fameux FX TELEPORT qui permet en fait apres avoir installé des VST plugins sur la bécane N°2 de pouvoir en théorie "rapatrier" ces flux audio sur la premiere becane(hôte) via le LAN (Gigabit conseillé), soulageant la bécane Hôte de la charge de calcul.
-et bien ma bécane Hôte à le CPU qui s'accroit comme si les plugs étaient installés sur celle-ci à ma grande désolation!

Dans ton cas, la première chose que j'essaierai, serait de désactiver le port réseau intégré à la carte mère, et voir si l'utilisation cpu augmente aussi avec une petite carte réseau Pci toute simple comme les realtek.
A part cette solution, tout ce que je peux dire, c'est que pour avoir installé des centaines de carte audio, que ce soit sur mac ou pc, les creamware font partie des cartes qui ont les plus mauvais drivers qui soient.....à moins qu'ils aient arrangé les choses depuis un an.

Mais bon, pour en revenir au sujet d'origine, je n'ai toujours pas trouvé de solution 100% efficace pour valider les différentes carte mère. Je reste sur des solutions 100% Intel, et en essayant de ne pas utiliser les contrôleurs présent en plus de ceux gérés par le chipset, comme les controleurs raid & co qu'on trouve assez courrament.
Il faudrait trouver une solution pour, par exemple, "stresser" au maximum un port réseau, et visualiser l'impact sur les capacité de la carte mère....est ce que les différents bus se retrouvent ralenti, ou bien si
ça ne leur fait ni chaud ni froid.

Les pros des tests....une idée ?

[Stéphane.P]

Gros déterrage de topic

Ce n'est pas la panacé, mais depuis quelques mois, j'utilise DPC Latency Checker, un logiciel qui permet de visualiser si un driver bloque trop longuement la file d'attente des interruptions. Si c'est le cas, tout traitement orienté "temps réel" ne retrouvera interrompu un bref instant.

J'avoue avoir eu quelques (mauvaises) surprises, certains drivers étant vraiment mauvais.

Un C2Q Q6600 sur une carte mère P35, installation super clean :



Rien à dire, tracé plat, avec quelques pics à 50/60 µs, mais rien ne viendra perturber l'audio.




Mon bon vieux Notebook Asus W3 (Pentium M 1.7Ghz) :



C'est moins bon, mais largement dans le vert, et étant donné le nombres de périphériques connectés à cet ordinateur, c'est une agréable surprise.




Un Apple Macbook pro C2D 2.4Ghz avec Windows XP :



Ah ouais !
Tu m'étonnes que l'utilisateur avait des problèmes pour faire des enregistrements sans coupures dans l'audio.

Heureusement que Apple nous prévient que leurs Mac sont aussi les meilleurs Pc....

[newbie06]

Ca ne pourrait pas venir du fait que tu fais tourner XP sur un Mac et que les drivers ne soient pas du tout adaptés ? On ne peut pas aussi imaginer que le BIOS non plus ne soit pas adapté (ou bien XP se passe complètement du BIOS en dehors de l'énumération des périphs et des IRQ ?) ?

[Dandu]

un peu des deux sur le coup.

les pilotes sont généralement bien vieux et assez moyennement efficace (particulièrement sur la carte graphique).

y a pas réellement de BIOS sur le Mac, c'est simplement un émulateur placé dans l'EFI pour Windows XP (a priori).

ce qui serait intéressant, c'est de voir ce qui bloque comme ça, même si un truc genre le trackpad (multitouch ? dernière génération de MBP ?) serait bien possible.

[fefe]

Et ben 16ms a attendre un driver, ils se genent pas . Sans vouloir etre mauvaise langue a tous les coups ca doit etre le GMA

[Dandu]

pas de GMA (en tout cas, pas activé) dans le Pro. Enfin, quelle idée aussi de mettre un MacBook Pro sous XP (ça fait un mois que je dois remettre Windows sur le mien et j'en ai pas encore eu le besoin pressant)

[PrinceGITS]

Question un peu conne, mais Vista SP1 ne supporterais pas nativement l'EFI ?
Car ça résoudrait peut être le problème...
2ème question conne, on peut installer Vista sur un Mac ?

[Dandu]

Pas besoin du SP1, la version de base boote parfaitement sur un Mac, même sans disque dur contenant Mac OS X (pas le cas de XP)

Et oui, on peut installer Vista sur un Mac, ou n'importe quel OS x86 classique (enfin, qui supporte un minimum le matériel, j'ai pas essayé DOS 6 ou Win 3.11).

[Stéphane.P]

Ca ne pourrait pas venir du fait que tu fais tourner XP sur un Mac et que les drivers ne soient pas du tout adaptés ?

Même si c'était le cas, Apple ne le présente pas du tout comme ça.

ce qui serait intéressant, c'est de voir ce qui bloque comme ça, même si un truc genre le trackpad (multitouch ? dernière génération de MBP ?) serait bien possible.

DPC Latency Checker ne permet pas de savoir quel driver impose autant d'attente, la seule solution est de désactiver manuellement des périphériques ou des applications.
Sur les Macbook pro, il y a deux responsables :

1) La puce Atheros qui gère le Wifi. Une fois désactivée, les pics de latence les plus importants disparaissent. J'ai aussi croisé un Notebook Toshiba avec de l'atheros, et le problème était le même. D'ailleurs, même sous MacosX, les perf audio en basse latence sont largement diminuées tant que le Wifi est actif.

2) Le gestionnaire Bootcamp qui se lance au démarrage de Windows. Et là, Apple est entièrement responsable.

Une fois le wifi et bootcamp désactivés, on retrouve un latence qui tourne autour de 60/100 µs

Et ben 16ms a attendre un driver, ils se genent pas . Sans vouloir etre mauvaise langue a tous les coups ca doit etre le GMA

Eh bien tu es mauvaise langue, puisque comme l'a dit Dandu, les macbook pro ne sont pas équipés avec du GMA

pas de GMA (en tout cas, pas activé) dans le Pro. Enfin, quelle idée aussi de mettre un MacBook Pro sous XP (ça fait un mois que je dois remettre Windows sur le mien et j'en ai pas encore eu le besoin pressant)

Toi peut-être, mais certains en ont réellement besoin pour des applications professionnelles.

Bref, dans mon cas, j'utilise cette application pour vérifier qu'il n'y a pas de problème potentiel en audio, mais je me demande si cela ne pourrait pas aussi créer quelques "drop" d'image dans les jeux.

[Dandu]

Ah mais c'est pas un repproche, hein, c'est juste une question.

Sinon, le pilote Atheros est assez moyen, oui, je l'avais remarqué. Le pilote nVidia aussi (bien vieux)

[Stéphane.P]

Ah mais c'est pas un repproche, hein, c'est juste une question.

Dans les deux derniers cas que j'ai croisés, c'était pour utiliser Protools (oui, il existe aussi pour Os X, mais bon, c'est pas moi l'utilisateur), et puis pour Smaartlive, une application qui permet le calibrage des systèmes de diffusion audio.

Sinon, le pilote Atheros est assez moyen, oui, je l'avais remarqué. Le pilote nVidia aussi (bien vieux)

En fait, je viens de croiser encore pire avec un portable Toshiba, même avec presque tout le hardware désactivé, j'ai encore des pics de latence.

Un expert de la place saurait s'il y a un moyen de déterminer quel périphérique pose problème ? Un moyen d'analyser la file d'attente des DPC ?

[Møgluglu]

Intel a sorti depuis peu un outil similaire pour Linux, et qui donne des infos plus détaillées (genre ligne de code qui bloque dans le kernel, trié par process...)
http://www.latencytop.org/

Ça peut valoir le coup d'essayer, ne serait-ce que pour alimenter les trolls.
Par contre il faut un kernel récent (2.6.25) ou patché.

Edit: apparemment DPC Latency Checker mesure les latences de traitement des interruptions, alors que LatencyTop mesure celle des opérations noyau, donc plutôt rien à voir (même si les deux peuvent provoquer des glitches dans l'audio).

[newbie06]

(Hors-sujet) Intel a aussi fait PowerTop qui montre les transitions dans les etats C (power states).