Forum Linux.général Coupure du son lorsque le CPU est trop chargé

Posté par  .
Étiquettes :
0
3
déc.
2004
Bonjour,

J'ai un petit problème lorsque j'écoute des mp3 avec différents softs (xmms, mpd etc...) : il suffit que j'effectue une opération gourmande en cpu pour que le mp3 "saute", çàd s'interrompe pendant une demi seconde, par exemple lorsque je change de workspace ou je ferme un tab sous le navigateur.

J'ai bien fait un :
> renice -20 `pidof xmms`
ce qui améliore légèrement la chose, mais pas encore suffisamment (d'autant plus qu'il faut passer root).

Pourtant il m'a semblé qu'il y avait eu un peu de bruit autour des nouvelles « fonctionnalités multimedia » du kernel 2.6 qui devaient justement empêcher ce genre de problème!?

Quelqu'un aurait il plus d'information sur ce genre de problème?

  • # AMHA

    Posté par  . Évalué à 2.

    je pense que le changement auquel tu fais allusion entre le 2.6 et le 2.4 est l'augmentation de la reactivité du noyau par le passage du changement de tache de 10ms en 2.4 a 1ms en 2.6, ainsi que le passage du kernel lui meme en pre-emptif alors qu'avant le temps kernel n'etait pas interruptible.
    Les pb que tu pointe ne peuvent pas etre resolu de maniere soft. Il me semble que c'est simplement le manque de RAM et donc l'utilisation de swap sur le disk qui bloque temporairement l'execution d'une tache ou l'autres. Si les données MP3 sont sur le disk et qu'une autres appli se voit chargé du swap disk vers la memoire parce que tu l'active et qu'il faut bien quelle soit dans la memoire pour s'executer je ne vois pas comment dans le meme temps fournir des données a ton lecteur MP3.
    En clair, le 2.6 a ameliorer les performances en vue d'utilisation multimedia mais ne peut pas corriger tous les cas d'emploi.

    • [^] # Re: AMHA

      Posté par  . Évalué à 2.

      Sinon, je vais peutêtre me tromper, (corrigez si c'est le cas), mais je me dis qu'il peut s'agir d'une question de priorité d'interruption matérielle :

      Si la carte son a une priorité plus basse que la carte graphique, le traitement du son sera constamment interrompu dès que de l'affichage sera demandé. C'est, je pense, le même problème que la copie d'un fichier depuis un cdrom qui fait saccader la souris.

      La sortie du son demandant un temps de traitement bien moins important que les opérations d'affichage usuelles (surtout que l'envoi des données sonores est découpé en échantillons de base envoyés à intervalle régulier, temps de traitement très faible pour chacun). Dans ce cas, l'odre de branchement sur la carte mère peut aider ? ou alors le bios propose des options pour changer l'interruption du chip sonore (si intégré) ?

      • [^] # Re: AMHA

        Posté par  . Évalué à 4.

        sur une archi intel x86 il n'y as qu'une source d'interruption sur le processeur (en dehors de nmi et de reset) c'est d'ailleur pour cela que depuis la nuit des temps des controleurs d'interruption 8 bits (il y en as deux et on cascade la 9eme vers la 2) permette de gerer 15 interruptions.
        Donc il n'y as pas d'interruption plus prioritaire qu'une autre sur les systeme PC (contrairement a la plupart des procs que l'on utilise en electronique).
        Les cartee son possede un buffer ram et cela fait bien longtemps que ce n'est pas sample par sample que l'on envoie les données (maintenant on procede par flux dma) et les disques dur pareilles.
        Si un acces au cdrom bloque la souris c'est parce que l'architecteure IDE demande une grosse charge de CPU pour faire des transfert contrairement au scsi et si le cpu transfert des data du cd rom vers la ram il ne peut pas passer sont temps a lire les infos que la souris lui envoie.
        La meuilleure cure pour ce probleme c'est de rajouter de la ram a ce pc.

        • [^] # Re: AMHA

          Posté par  . Évalué à 2.

          C'est quand même bizarre... j'ai 512 Mo de Ram sur ce pc...

          • [^] # Re: AMHA

            Posté par  . Évalué à 1.

            donc il y as un soucis de flux de donnée.
            tu as fais un petit coup de hdparm ?

        • [^] # Re: AMHA

          Posté par  . Évalué à 1.

          Avec xmms, on peut augmenter la taille du buffer de lecture , ce qui devrait permettre d'eviter les trous...
          c'est dans options -> preferences -> "configurer" situé sous "pilote oss de sortie" ->onglet tampon

        • [^] # Re: AMHA

          Posté par  . Évalué à 1.

          ah ?!

          A quoi sert donc http://cae.best.vwh.net/irqtune/(...) (que l'on peut trouver dans le paquet debian hwtools, entre autres) ???

          De toutes manières, je conseille la lecture de http://myweb.cableone.net/eviltwin69/ALSA_JACK_ARDOUR.html(...) pour tenter de régler ce genre de pb (en particulier : 2. Low latency, preemption, IRQs, hard drive tuning, and other arcana)

        • [^] # Re: AMHA

          Posté par  . Évalué à 2.

          Donc il n'y as pas d'interruption plus prioritaire qu'une autre sur les systeme PC

          Il ne faut pas exagérer :-) Comment ca se passerait dans ce cas si deux interruptions se produisaient *exactement* (sur le même cycle d'horloge) en même temps ? Il faut bien qu'il y ai un choix à un moment.

          Par contre, au sujet des cartes sons, je suis allé un peu vite, merci de m'avoir corrigé. Mais mon raisonnement doit rester valable en remplaçant "échantillan par "buffer". Un transfert de 512 ou 1024 octets vers la carte son ou la lecture de la position de la souris, ce n'est pas très violent pour un processeur de nos jours. Par contre, l'envoi de données d'images vers la carte graphique est généralement bien plus lourd.

          • [^] # Re: AMHA

            Posté par  . Évalué à 1.

            Si deux interruptions se produise en meme temps, tout simplement le t kernel va lire dans les deux controleurs (qui sont depuis longtemp dans une seul puce) les interruption en "pending" ( a traiter), il trouve mettons la '0' d'activer et la '11', il apelle la routine correspondante à la '0', a la fin de la routine il recommence a lire les "pendings" si la '0' n'as pas reclaquez il va apellez la routine '11' et ainsi de suite.
            Il n'y as donc pas de priorité hardware aux interruptions, en bidouillant le soft on peut dire que tel ou tel interrupt doit etre traiter plus souvent qu'une autre.(voir le soft plus haut si le package irq-tune)

    • [^] # Re: AMHA

      Posté par  . Évalué à 2.

      > Les pb que tu pointe ne peuvent pas etre resolu de maniere soft.

      Faut voir. Le hard impose bien sûr ses limites à ce qui est faisable sur une machine, mais le soft a quand même son mot à dire sur la façon dont est géré le workload. Perso, j'ai toujours eu des problème de son qui saute avec le scheduler du 2.6 normal (dès qu'il y avait de la charge de compilation derrière et que je browsais le web par exemple), qui ont été reglés par un passage en 2.6-ck. Ça mérite d'être essayé là aussi je pense (en prenant bien soin de ne pas avoir son X renicé comme le font certaines distribs, parceque là sinon c'est coupure assuré au moindre évenement graphique).
      http://members.optusnet.com.au/ckolivas/kernel/(...)

      • [^] # Re: AMHA

        Posté par  . Évalué à 2.

        Je suis du même avis. C'est sûrement dû à des problèmes au niveau de l'ordonnanceur.

        Sur mon PC, il suffit qu'il y a ait un certain niveau d'activité disque pour que le son saute (mise à jour avec apt-get par exemple), ou sinon quand le CPU est à fond (en remuant une fenêtre ou en faisant défiler une page chargée dans Firefox...). Ce n'est pas forcément lié à une utilisation trop importante de la mémoire et donc au swap.

        J'utilise l'ordonnanceur cfq (noyau 2.6.9), sensé être plus adapté à une utilisation "desktop", mais c'est pas encore ça.

        • [^] # Re: AMHA

          Posté par  . Évalué à 2.

          Juste une petite remarque : l'ordonnanceur cfq est un ordonnanceur d'IO disque, pas du processeur...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.