Je passais par là donc j'en profite pour laisser mon commentaire :)

Tout d'abord un peu de pub: pour générer du son à la volée (et aussi en enregistrer) il y a aussi mes composants TWaveIn et TWaveOut:
http://www.delphifr.com/codes/SON-MONTE-MONTE-MONTE_33689.aspx
http://www.delphifr.com/codes/PROGRAMME-MIX-AUDIO- APPRENTI-DJ_33254.aspx
http://www.delphifr.com/codes/CHRONOMETRE-THE_47398.aspx

Ils sont basés sur des API plus performantes que sndPlaySound et permettent de faire la même chose avec plus de paramètres. Les données du son doivent être générées à la volée dans un événement, qui permet de ne pas avoir à se soucier de le faire dans un thread externe (donc le programme ne bloque pas).

Autre chose: dans ta boucle, je vois:

for i:=0 to BEAUCOUP do begin
  if VARIABLE=1 then ...
  if VARIABLE=2 then ...
  if VARIABLE=3 then ...
  ...
end;

Déjà, un "case VARIABLE of" serait mieux. Mais étant donné que la boucle peut potentiellement consommer beaucoup de ressources et que VARIABLE est un invariant par rapport à la boucle (ie: ne varie pas) le code suivant serait plus efficace, car il permet de ne pas faire le test à chaque itération:

case VARIABLE of
  1:for i:=0 to BEAUCOUP do ...
  2:for i:=0 to BEAUCOUP do ...
  3:for i:=0 to BEAUCOUP do ...
  ...
end;

Dans ce cas-là ça n'est pas très important car le calcul n'est pas très compliqué, mais si tu commences à générer des effets audio complexes en temps réel alors cela peut avoir de l'importance.

Idem pour la division Frequency / SampleRate qui devrait être stockée dans un flottant avant la boucle pour éviter de la recalculer à chaque itération. La multiplication par i pourrait alors être changée en une incrémentation par cette valeur.

Dans le même ordre d'idée, les générateurs de son en temps réel utilisent aussi des tables de cosinus précalculées.

Caribensila: il me semble qu'ici les PING sont ici exécutés séquentiellement, pas en parallèle (c'est même le but de la man½uvre!). Il n'y en a donc jamais plus d'un à la fois, ce qui ne devrait pas trop gêner le scheduler.

MAURICIO: Peut-être que TASKLIST ne fonctionne pas pareil alors. Théoriquement, lorsque le processus n'existe pas, la commande renvoie 1 seule ligne de texte. Sinon, elle en renvoie plusieurs (3 il me semble). Mon fichier BAT compte le nombre de sauts de lignes renvoyés par TASKLIST: s'il y en a plus de zéro (processus "running"), il réessaie jusqu'à ce qu'il n'en reste plus (processus "stopped").

Merci d'avoir regardé. Peut-être que TASKLIST fonctionne différemment sous Vista...

En remplaçant SW_HIDE par 0, la fenêtre de console devrait être affichée et donner plus de détails, si tu as le temps.

Au fait si quelqu'un peut tester mon code plus haut sous d'autres versions de Windows que XP, ça m'intéresse.

Je me permets d'ajouter ma solution. Ne laisse aucune trace et fait briller, quel que soit le temps mis par le processus pour se terminer (testé sous WinXP). MonsieurPropre peut être lancé n'importe quand (par exemple au démarrage du programme, ou dans l'événement OnCreate d'une fiche).

Le PING n'est pas vraiment nécessaire, il sert uniquement à éviter de trop gâcher du temps machine.

procedure MonsieurPropre;
var
  l:TStringList;
begin
  l:=TStringList.Create;
  try
    l.Add(':LOOP');
    l.Add('PING 127.0.0.1 -n 2 -w 1000');
    l.Add('SET N=0');
    l.Add('FOR /F "delims=" %%i IN (''TASKLIST /FI "IMAGENAME EQ %1"'') DO SET /a N+=1');
    l.Add('IF %N% NEQ 0 (GOTO LOOP)');                            
    l.Add('DEL %1');
    l.Add('DEL %0');
    l.SaveToFile('MrPropre.bat');
    ShellExecute(0,nil,'MrPropre.bat',PChar(ExtractFileName(Application.Exename)+#0),nil,SW_HIDE);
  finally
    l.Destroy;
  end;
end;

Ricquet: il faut regarder les deux fichiers SimpleCompressorDialogFormUnit.pas et ExtendedCompressorDialogFormUnit.pas qui implémentent toutes deux une procédure similaire:

function ExecuteSimpleCompressorDialog(ABIH:TBitmapInfoHeader;AMode:Cardinal;var Quality,DataRate,FrameRate,MaxFramesBetweenKeys:Cardinal;var AutoKeyFrames:Boolean):HIC;

function ExecuteExtendedCompressorDialog(ABIH:TBitmapInfoHeader;AMode:Cardinal;var Quality,DataRate,FrameRate,MaxFramesBetweenKeys:Cardinal;var AutoKeyFrames:Boolean):HIC;

Dans ces deux cas, le résultat de la fonction correspond à la variable SelectedIC qui doit être renvoyée par l'événement custom. Il faut entre autres utiliser les API ICOpen, ICGetInfo, ICCompressQuery et ICInfo pour obtenir la liste des codecs installés ainsi que leurs propriétés, et renvoyer un handle dans SelectedIC . Pour cela, j'ai peur qu'il faille aller lire les doc MSDN correspondantes...

philgeorges: ça viendra quand j'aurai le temps. En ce moment ça n'est pas vraiment d'actualité, j'ai trop de boulot!

Il faudrait modifier procedure TAVIWriter.AddFrame: à la place de AVIStreamWrite(...) il faudrait envoyer les données sur un socket. Ca c'est facile. Ce qui est plus difficile, c'est de décompresser à l'autre bout du socket (entre autres, il faut que l'IC soit ouvert avec exactement les mêmes paramètres).

Au fait, correction par rapport à ce que j'avais écrit précédemment: la propriété AVIMaxFramesBetweenKeys est bel et bien supportée. C'est le nombre de frames entre chaque keyframes. C'est un peu technique, mais généralement, plus le fichier final a de keyframe, plus le seeking dans le fichier sera précis. S'il n'y a que deux keyframes (au début et au milieu par exemple), on ne pourra commencer la lecture du fichier qu'au début ou au milieu du film. Moi j'utilise en gros la valeur 20 (grosso modo, une keyframe toutes les secondes). Cette propriété n'est utilisée que si AVIAutoKeyFrames vaut true. Là encore, certains compresseurs ont leur propre gestion des keyframes (dans ce cas, utiliser AVIAutoKeyFrames:=False).

En fait, AviDataRate correspond à une taille fichier moyenne des frames sur 1000 secondes (même unité que AVIFrameRate).

Ton calcul plus bas est faux, car il faut donc multiplier par 1000. En outre, ça n'aurait aucun sens car les frames ne seraient pas compressées!

Le paramètre AviDataRate n'est pas le seul à déterminer la taille du fichier final. Il y a aussi le paramètre de qualité, qui est supporté par la plupart des compresseurs (beaucoup plus souvent que le datarate).

L'unité de temps est définie à 1000 secondes. Donc pour un AVI à 24 images par secondes, il faut utiliser AviFrameRate=24000.

Idem pour AviDataRate, qui correspond à la taille moyenne (en octets) occupée par 1000 secondes d'AVI. Cette propriété n'a rien à voir avec le framerate, et peut être ou non supportée par le compresseur. Si c'est le cas, et si le nombre de frames est connu elle peut être utilisée pour fixer une taille approximative au fichier final à générer (je crois qu'il faut utiliser datarate := taillefinaledésirée * framerate / nombredeframes ). Ce paramètre n'est pas à modifier à la légère pour certains compresseurs. S'il est égal zéro, la valeur par défaut du compresseur est utilisée (recommandé).

La propriété AVIMaxFramesBetweenKeys n'est pas supportée car je ne sais pas comment transmettre le paramètre au compresseur. Mais elle peut pourrait être supportée en implémentant une boîte de dialogue spéciale (OnCustomSelectCompressor).

Dans la plupart des cas, il est préférable de faire appel à la boîte de dialogue du compresseur pour changer les paramètres plutôt que de le faire manuellement.