Le problème de son haché ne provient pas d'une quelconque difficulté au niveau mémoire (cette hypothèse a été évoquée à ce sujet ? Je ne me souvient pas...mais bon...)
La gestion du décodage audio et vidéo est réalisée par le STB 02500 de manière totalement hardware, dans des zones de mémoire dédiées à cet effet. Sur un TGS 100, on a deux banques de 32 Mo et l'une d'elles ne contient QUE des buffers techniques utilisés pour cette activité.
Le décodage audio et vidéo requiert environ 3 Mo de RAM qui sont bloqués EN DUR et définitivement.
En dehors de cela, le processeur se charge NORMALEMENT d'opérer la synchro son / image en utilisant les données d'horloge présents dans les données, et sa propre horloge...celle-ci pouvant dériver plus ou moins, le processeur utilise un mécanisme de correction de dérive qui peut parfois etre complété par un traitement logiciel au niveau des drivers..
Mais pour le reste, tout est "hardware".
Donc il ne peut y avoir que peu d'explications :
Les infos horloge transmises par ces chaines sont douteuses (peu probable).
Les drivers sont buggés (vraissemblable) et les algos de compensation sont mauvais (voir absent).
Le fait que la situation revienne à la normale lors de certaines manip comme la relance d'un ému n'est pas révélateur...en effet, quand on zappe, quand on coupe un ému puis le relance..etc...bref quand on "touche a un truc qui concerne la chaine en cours de réception", le traitement du flux est interrompu fugitivement puis va reprendre.
Par exemple : je coupe l'ému
coupure de décryptage du flux
coupure des circuits audio...je relance l'ému
on repart de zero et on refait une synchro initiale, comme si on venait de zaper en fait.
Par contre je pense que le fait que cela ne survient pas sur toutes les chaines, mais plus souvent sur certaines que d'autre (tf1...) est révélateur d'un problème lié à la densité du flux : ces chaines ont-elles une bande passante supérieure ? Un débit audio supérieur ?...probablement.
