Sujet: Son "haché" ou 'saccadé' sur certaines chaines

[Doume]

Suite à d'autres posts signalant ces problèmes, sur TF1, ou Discovery Channel, etc... , je me suis livré à quelques tests.

Au départ, un TGS100 avec une image 2.0.13 fonctionne correctement.
Même après un zapping intensif
Je n'ai pas constaté ces problèmes sur le son, sur  de nombreuses chaines cryptées ou FTA

Puis j'ai commencé à 'charger la bête' :
- Utilisation du Doume Panel
- Enregistrements sur un disque distant en mode CIFS

Tant que le swap était inutilisé, ou utilisé faiblement, pas de problèmes.

Dès que le swap a été utilisé sur plus de 2 MB, les problèmes ont commencé.
Parfois, le son était inaudible
Uniquement sur des chaînes cryptées, à priori

J'ai essayé d'arrêter/relancer Hypercam : Aucun résultat : Toujours le problème
J'ai tenté de forcer un arrêt/relance enigma : Toujours pareil

Seule solution : rebooter le démo
Bien entendu, le swap est à nouveau non utilisé, après un reboot
Et là, tout redevient normal

Je commence à croire que si certaines parties 'sensibles' de Enigma ou de l'executable Hypercam se retrouvent 'swappés', les performances chutent considérablement, et que le démo n'est plus à la hauteur pour faire face au décryptage et assurer la fluidité du flux.

Décidément, ce manque de RAM sur le TGS100 commence à poser des problèmes insurmontables : Le swap ne permet pas de résoudre le problème, compte tenu de ses faibles performances.

Mais ce n'est qu'une 'impression', qui reste à confirmer.
Peut-être lancer Hypercam avec un 'nice', pour augmenter sa priorité et lui éviter d'être swappé ?

Si vous avez constaté des choses à ce sujet, vos expériences seront les bienvenues....

[GoustiFruit]

Salut Doume,

Tu parles de faibles performances du swap, mais tu utilises du swap sur memory card ou sur disque dur ? Est-ce qu'il y a une différence de performance entre les 2 ? (c'est sûr que par rapport à de la RAM, ça doit se ressentir)

[MiKe]

Salut Doume,

Je partage ton point de vue. En effet, c'est souvent après avoir fait un zapping intensif avec le skin anex platine + picon que j'ai rencontré le problème de son haché. Effectivement, comme il faut afficher les logos, au fur et à mesure du zapping, la barre d'affichage apparaît de moins en moins vite, et le swap se remplit.

Par contre, je ne saurais pas te dire si c'est hypercam qui est en cause ou la 2.013, car avant même avec le skin anex + picon, je n'ai pas souvenir d'avoir eu ce problème sur une 2.011 par exemple.

Il faudrait revenir à une version d'hypercam plus ancienne pour faire des tests...Néanmoins, ce que je suis entrain de tester c'est de n'avoir mis que le simply skin (donc sans les picons) et depuis, je n'ai eu que le problème de son qu'une seule fois et j'ai essayé comme toi de redémarrer hypercam, et enigma mais sans succès. Un reboot complet du démo a résolu ce problème.

Par contre, concernant le swap, j'ai remarqué qu'un swap de 32 Mo travaillait mieux qu'un swap de 64 Mo...j'étais monté une fois à plus de 6 Mo sur 32 alors qu'en 64 Mo pas eu plus de 3 Mo.

Pour finir, la 2.013 est la meilleure de toutes les images depuis le début du TGS je pense. Pas mal d'amélioration ont été faites et il est beaucoup plus stable. Après, rebooté hypercam 2 à 3 fois dans la journée car il décrypte pas toujours ma carte locale, ce n'est pas grave, l'ému étant jeune, il faut laisser le temps au dev de la faire progresser tranquillement, et c'est déjà énorme le taf qu'il y a eu de fait !

Pour info :

Code: [Sélectionner]

[ITGATE(TGS100) /> free                                                 
              total         used         free       shared      buffers 
  Mem:        24852        22564         2288            0         1424 
 Swap:        32760            0        32760                           
Total:        57612        22564        35048                           
[ITGATE(TGS100) />                                                       
                                                             

[Danield]

je n'ai pas rencontré ce problème sur tgs100, mais je dois dire que j'utilise évcamd ou ccam.
Par contre je l'ai rencontré sur une dreambox500

[Doume]

Salut Doume,

Tu parles de faibles performances du swap, mais tu utilises du swap sur memory card ou sur disque dur ? Est-ce qu'il y a une différence de performance entre les 2 ? (c'est sûr que par rapport à de la RAM, ça doit se ressentir)

Je n'ai pas de HDD dans le TGS100 : je n'enregistre que sur le HDD de la Dreambox, en CIFS
Un swap sur disque réseau, c'est à proscrire, trop lent, et pas accessible au boot

Donc actuellement, j'ai un swap de 16 MB sur carte SD

Je crois que le problème, c'est si un bout de code de l'EMU se retrouve en swap : Le temps de le faire remonter en RAM, et il est trop tard : des fonctions sont executées 'trop tard', les datas ne sont plus dispo

L'ennui, c'est qu'à chaque release, le code Enigma grossit, grossit,.... ainsi que celui des outils périphériques. A terme, ça rentrera plus en RAM, même sans EMU

[GoustiFruit]

Ca fait plusieurs fois que je lis des messages de ta part qui font penser que tu passerait bien à autre chose que l'iTgate si il y avait une bonne alternative... 

[MiKe]

Oui le TGS110 avec plus de RAM  Je suis content de l'iTGate moi, surtout avec la Doume 2.013...

[NouNours]

hello,

hier ca m'est arrivé le sons'est mis a saccader severe sur TF1. J'avais la tele dans le dos et le WEBXTV sur mon pc. Aucun probleme sur le PC en stream... en laissant comme ca un ptit moment c'est revenu a la normal!

[Tidus056]

Salut à tous,

Je ne pense pas qu'hypercam en soit la cause puisque j'ai eu le même soucis avec CCcam.

Pour la RAM, j'ai eu le soucis une fois sur le 200 aussi, pourtant il y en a encore de la ram de disponible.

Sur le 100, voici l'occupation de ma ram à l'instant ( le 100 n'as pas été rebooter depuis quelques jours )

Code: [Sélectionner]

[ITGATE(TGS100) /> free                                                 
              total         used         free       shared      buffers
  Mem:        24852        24048          804            0          920
 Swap:        65528         1208        64320                           
Total:        90380        25256        65124                           
[ITGATE(TGS100) />                                                      
                                                                   
La consommation n'est pas exagéré, je pense.

Les chaines coupables sont chez moi tf1, m6 et discovery sur csat. Mais le phénomène est très aléatoire, cela fait plusieurs jours que je n'ai pas eu de soucis.

Il y a déja le bug de l'affichage en 16/9 dans le CVS. Est-ce que le flux audio de ces chaines est particulier par rapport à d'autes?

Voilà si ça peut te donner des pistes....

@+

[zorglub]

Ceci dit tout à l'heur, en chipotant sur les link des libcrypto, j'ai remarqué que le phénomène à disparut, mais je ne me souviens plus exactement si c'était la version 0 (720k) ou 0.9.7. (à 160k). Si j'ai un peut de temps je fouillerai dans ce coin...

Bonne soirée à tous

[skikdi53]

Je ne suis pas callé pour trouver les causes de ce probléme par contre je peux dire que chez moi meme sur des chaines FTA j'ai deja eu ce probleme.
a+

[Pilou]

Salut,

Je viens de l'avoir pour la premiere fois peu de temps apres une sortie de veille sur Tiji, zapping sur AB moteur, retours sur Tiji avec son toujours haché, Teletoon puis retours Tiji OK.

La libcrypto.so.0 fait bien 726 Ko et mon swap est bien utilisé (je suis sur une Doume 2.11b sans picon + CCcam) mais je pencherais plus pour les drivers 2.13 en flash qui semble etre la nouveauté et le point commun à tous (ceci etant, je peux maintenant enregistrer toutes les langues et ne reviendrais pas en arriere) 

@+, Pilou.

[Doume]

Je ne pense pas que les drivers 2.0.13 soient responsables : J'ai constaté cela aussi sur une Dreambox, lorsque la RAM devient un peu chargée.

Par contre, toutes les images à base 2.0.13 nécessitent un peu plus de RAM, sur TGS100, alors.....

[Pilou]

Cela se tient mais on peut toujours essayer d'eliminer ce que l'on utilise pas !

Dans cette chasse au gaspi, je ne m'y retrouve pas entre la taille mémoire de chaque process et celle donnée dans free :

PID  Uid     VmSize Stat Command
  280 root        460 S   /bin/sh /etc/init.d/rcS
  325 root        508 S   /sbin/inetd
  421 root        356 S   telnetd
  422 root        744 S   -sh
  478 root      12664 S   /bin/enigma
  481 root      12664 S N /bin/enigma
  484 root      12664 S N /bin/enigma
  489 root      12664 S   /bin/enigma
  501 root      12664 S   /bin/enigma
  502 root      12664 S N /bin/enigma
  527 root      12664 S   /bin/enigma
  480 root       1532 S   /var/bin/CCcam
  482 root       1532 S   /var/bin/CCcam
  483 root       1532 S   /var/bin/CCcam
  490 root       1532 S   /var/bin/CCcam
  491 root       1532 S   /var/bin/CCcam
  492 root       1532 S   /var/bin/CCcam
  506 root       1532 S   /var/bin/CCcam
  507 root       1532 S   /var/bin/CCcam
  530 root       1532 S   /var/bin/CCcam
  505 root        468 S   /bin/udhcpc --hostname=MySTB  --foreground
  536 root        720 S   smbd -D
  539 root        820 S   nmbd -D
  566 nobody      552 S   in.ftpd
  568 root        688 S   in.ftpd
  618 root        624 R   ps
[ITGATE(TGS100) /mmc> free
               total         used         free       shared      buffers
Mem:        24852        22896         1956            0         2532
Swap:       16376         1156        15220
Total:        41228        24052        17176

Enigma a l'air d'avoir pris environ un Mo entre la Doume 2.11b et la 2.13 mais chacun des process forkés (je ne comprend pas qu'il y en ai autant) ne doit pas utiliser sa propre mémoire ? Le noyau doit bien prendre sa part ?

Merci de tes lumieres, Pilou.

[Doume]

la commande 'ps' est loin de donner toutes les infos concernant l'occupation mémoire de chaque process.
Je trouve d'ailleurs que le choix d'afficher VmSize n'est pas très judicieux. Ce n'est pas représentatif.

Pour connaitre les vraies valeurs, il faut aller voir, process par process, dans /proc/Num_de_process

Enigma et autres sont des 'multithreads', c'est à dire qu'entre eux, ils partagent le code programme, et la zone mémoire data, mais ont chacun leur stack (la pile des appels/return et des variables locales aux objets )

Donc, avant de retrouver tous les octets de la RAM, il va te falloir détricoter un sacré paquet d'informations...
Ainsi, Enigma a plusieurs threads : L'un gère la zap, l'autre les évènements programmés, un autre le tuner, etc...

Amuses-toi bien