Discussion :

[Kaptha]

Bonjour !

Je travaille actuellement sur un projet en C# concernant notamment l'intégration d'échantillons sonores.

Ma contrainte concernant ces échantillons est qu'il faut qu'ils soit vite lus une fois le signal donné, et au besoin répété en rythme.

Malheureusement, ma solution actuelle souffre d'un temps de latence important... De l'ordre de 100 ms, ce qui est problématique pour mon application.

J'ai essayé plusieurs solution, et pour le moment, DirectSound donne le meilleur résultat, mais encore un poil insuffisant..

Du coup, je me demandais :

• Quelle est la solution Visual Studio la plus performante pour traiter le son ?
• Dans Direct Sound, peut-on forcer le traitement hardware du son ?

Voici le bout de code qui me permet de créer un objet de la classe instrument qui charge du son... Peut-être devrais-je optimiser quelque chose là-dedans, mais je ne sais pas quoi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
//<Attributs de 'forme' de classe>
private String nom;
private String path;
private int mesures;
private int temps;
//</Attributs de 'forme' de classe>
 
//<Attributs de 'fonctionnement'>
private Device device = new Device();
private SecondaryBuffer buffer = null;
//</Attributs de 'fonctionnement'>
 
 public instrument(String p_nom, String p_path, int pmesures)
 {
            nom = p_nom;
            path = p_path;      
            device.SetCooperativeLevel(Form1.giveMyself(), CooperativeLevel.Priority);
            buffer = new SecondaryBuffer(path, device);
}

Le son qui est joué est toujours traité en software avec ce code... Est-ce normal ? Puis-je forcer le harware, et est-ce que ceci donnerait de meilleures performances ?

Voilà... Je suis assez désespéré, alors j'attend avec impatience toute vos suggestions !

[Mehdi_ab]

Bonjour;


t'as essayé d'utiliser la fonction PlaySound de l'api Win32

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
[sysimport(dll="winmm.dll")]
public static extern long PlaySound(String lpszName, long hModule, long dwFlags);

ensuite dans ton code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
PlaySound( "chemin de ton fichier wav", 0 , 0);

[hegros]

Ce qui ralenti c'est peut-être que tu as ton code qui gère le son dans une form d'où des effets de ralentissement. Peut-être faut-il tagger la méthode en MTThread ou créer un thread dédié à la lecture...

[Kaptha]

Mehdi_AB> J'ai essayé, mais les performances étaient franchement moyennes. Apparemment, la librairie DirectX est la plus performante...

hegros> Mais oui... Je ne sais pas comment j'ai fait pour ne pas y penser ! Merci, je pense que là, ça va mieux marcher !

[champomy62]

Donc si j'ai bien compris, si on fait un calcul dans une form celui ci est ralenti ?

[hegros]

Donc si j'ai bien compris, si on fait un calcul dans une form celui ci est ralenti ?

oui car chaque code nécessite un temps d'exécution pour le thread qui l'exécute et un même thread ne peut pas faire 2 choses ou être à 2 points d'exécutions différents en même temps


Si dans le clic d'un bouton je fais un calcul qui prends 10 minutes alors je ne pourrais pas recliquer sur le bouton ou sur un autre ou exécuter n'importe quel autre code relative à la fenêtre (comme la demande de fermeture avec la croix rouge en haut à droite) tant que les 10 minutes ne sont pas terminées.

Parce que le thread de la form a sa propre pile d'exécution (comme chaque thread d'ailleurs) et lorsqu'il dépile le message et qu'il trouve que c'est un clic bouton alors il exécute le code du clic bouton et ensuite seulement il dépile le message suivant exécute le code associé et ainsi de suite. Cela corresponds à ce que l'on codait avant avec l'api win 32 en utilisant PeekMessage et DispatchMessage pour faire un programme fenêtré.