Lecture d'un fichier Son avec une Fréquence précise

Bonjour à tous

Je dois dans un de mes programmes lire un son qui a une fréquence et une durée précise (réglable).

J'ai d'abord opté pour la fonction BEEP à laquelle je passe la fréquence et la Durée.
Mon problème c'est que le son ne se déclenchait pas à l'instant ou je le lance mais avec une certaine latence qui n'est malheureusement pas la même à chaque fois. Je dois lancer un son et envoyer un signal à une carte d'E/S National Instrument pour déclencher un autre appareil en même temps donc la latence me pause problème.

Ma deuxième solution à été de générer un fichier waw à la fréquence que je voulais. Pour la durée, je ne peux pas avec le bou de code que j'ai, généré une durée en dessous de 1 seconde. J'ai utilisé l'objet MediaPlayer pour lire le son et l'arrêter quand j’atteins le temps voulu. (même souci de latence).

Ma troisième solution a été de générer un fichier waw plus long et de le lancer en avance avec un volume à 0 (paramètre de MediaPlayer) et de passer le volume à 1 quand je veux lire le son. Problème, pas de son lu car le volume reste à 0.

Ma quatrième solution aurait été d'utiliser PlaySond (API) mais il est en 32 bits, or je développe en 64 bits et je ne peux pas repasser en 32Bits à cause de la Carte d'E/S qui ne répond plus lorsque je suis en 32Bits.

Quelqu'un aurait-il une solution à me proposer pour que je n'ai pas de latence ?

Merci d'avance pour votre aide

Salut
la dll wimmdll est compatible 32 et 64 bits
donc le code suivant
// je te laisse traduire de Delphi en c++

Code:

---

1 2 3 4 5 6 7 8 9 10 11

procedure PlaySoundFile(FileName: string); begin if FileExists(FileName) then PlaySound(pchar(FileName), 0, SND_ASYNC or SND_FILENAME);   { Flags are: SND_SYNC =0 = Start playing, and wait for the sound to finish SND_ASYNC =1 = Start playing, and don't wait to return SND_LOOP =8 = Keep looping the sound until another sound is played } end;

---

devrait fonctionner sous les environnements 32 et 64 Bits

infos sup ici:https://learn.microsoft.com/en-us/wi...sound-function

cordialement

Salut
un petit exemple créé en 64 Bits
j'affiche dans une barre de status le temps entre l'appel de la fonction et la sortie
sur ma becanne de plus de 10 ans le temps est de 3 ms.
le paramètre SND_ASYNC est important car on travaille en mode asymchrone

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

#include <vcl.h> #pragma hdrstop #include"MMSystem.h" #include"Main.h" //--------------------------------------------------------------------------- #pragma package(smart_init) #pragma resource "*.dfm" TForm140 *Form140; //--------------------------------------------------------------------------- __fastcall TForm140::TForm140(TComponent* Owner) : TForm(Owner) { } //--------------------------------------------------------------------------- void __fastcall TForm140::Button1Click(TObject *Sender) { TDateTime Start =Now(); PlaySoundA("SYSTEMSTART", 0, SND_ASYNC); TDateTime Stop =Now(); StatusBar1->Panels->operator[](1)->Text=FormatDateTime(L"hh:mm:ss.zzz",Stop-Start); // 3 ms sur ma vieille machine } //---------------------------------------------------------------------------

---

cordialement

Je vais essayé ta solution. merci beaucoup

Je reviens après avoir testé.

J'ai sensiblement diminué mon temps de latence avec ta solution. ce temps est moins aléatoire qu'avec le MediaPlayer mais il reste à 60ms. par temps de latence j'entends le temps entre l'envoi de la commande de son et le moment ou le son commence à se jouer effectivement. Cela ne reste pas assez réduit pour moi quand je dois lancer dans le même temps un autre évènement qui dois être synchronisé.

Je ne vois pas comment faire pour arriver à lancer un son en instantané ou quasiment en instantané car il y a toujours une latence mais il me faudrait qu'elle soit le plus réduite possible (de l'odre de 2 à 3 ms) et je craint que cela ne soit pas possible.

Si vous avez une solution je suis preneur.

Salut
Ce temps de latence est il toujours le même ?
Pour rappel Windows n’est pas un système en temps réel
Ce que tu appel temps de latence dépend de la charge de ta machine.
Cordialement

C'est extactement ça.

J'ai essayé de m'en affranchir en lançant le son avec MediaPlayer avec un volume à 0 et de passer le volume à 1 au moment ou je dois lancer le son mais cela ne change pas le volume.

Ai-je oublier quelque chose je ne sais pas

Salut
comme windows ne sait pas faire du temps réel
je te proposer d'utiliser une technique utilisée dans les mesures à savoir échantillonnage
cad tu envoie la commande de son, dans un thread secondaire tu contrôle si un son a été émis,ce dernier Thread pourra alors déclencher la mesure et une notification à ton app
cordialement

Merci pour ta réponse

J'utilise déjà un Thread pour envoyer le son et cela ne change rien puisque le son part avant.
Moi il faut absolument que mon son parte en même temps qu'une stimulation ou alors que la stimulation soit décalé d'un temps que je peux régler.

C'est pour cela que je voulais lancer le son par anticipation avec un volume à 0 et de monter le volume au moment ou le son doit véritablement commencer dans les enceintes. Mais cela ne fonctionne pas avec le MediaPlayer, le volume ne change pas.

Une autre idée que je suis en train de tenter de mettre en place. J'utilise une carte d'E/S National Instruments pour envoyer mes stimulations et j'ai vu qu'on pouvait via cette carte envoyer des formes d'onde sur un canal analogique. Je vais essayé de me passer de la carte son de l'ordinateur et générer le signal de mon son via ce canal analogique de la carte pour voir si cela fonctionne.

le fichier son, c'est moi qui le génère donc il me suffit de le balancer directement sur le canal de la carte l'onde du son sans l'enregistrer dans un fichier wav.

Je reviendrais ici quand j'aurais terminé cette solution pour faire un retour

Bonjour,

Il est possible d'augmenter la priorité des traitements sous Windows à deux niveaux : priorité système donnée à l'application et au sein même de l'application. Les modifications au sein de l'application (SetPriorityClass() avec HIGH_PRIORITY_CLASS ou mieux - pire ? - REALTIME_PRIORITY_CLASS) sont encadrées par la priorité donnée à l'application par le système.

La priorité système s'applique à toute l'application même quand elle passe son temps à attendre une réaction de l'utilisateur.

Les modifications au sein de l'application peuvent être circonscrites aux seules opérations critiques.

Le mode temps réel n'est pas vraiment préemptif, il peut donc être interrompu, même si c'est rare d'autant plus que le nombre de cœurs physiques est élevé. En jouant sur les deux niveaux de changement de priorité, il est possible de diminuer sensiblement les latences. Les applications qui jouent des sons utilisent souvent le HIGH_PRIORITY_CLASS.

La REALTIME_PRIORITY_CLASS tend à bloquer les traitements des propres messages à destination du système de l'application rendue prioritaire. Elle est donc à manipuler avec précaution.

Salutations

Il faut rester au plus pres de la machine et ne pas utiliser le Mediaplayer qui a ses propres protocoles !

Mais même dans ce cas on ne peut pas s'affranchir d'une latence, bêtement par ce que lecture et enregistrement se font par buffers !
En lecture, le temps du remplissage dépend de la fréquence d'échantillonnage et du nombre d'échantillons à capturer.
On peut toujours essayer de réduire au minimum la taille de ces buffers ...

Si on a un buffer de 128 échantillons (16 bits mono donc 256 octets)
44,1kHz => 22,6us par échantillon => 2,9 ms pour le buffer de 128 samples (c'est aussi le temps max limite pour le traîtemnt)
96 kHz => 10,4us idem => 1,3 ms idem
L'idée serait alors d'utiliser un enregistrement sans fin tant que ...
On travaille alors avec 2 buffers : pendant que l'un est rempli l'autre est traité et qu'on repasse au dispositif après traitement ...

En flux continu on procèderait par blocs mémoire contigües successifs de plus grande taille...

Donc consulter le mmedia ... waveInOpen, waveInAddBuffer, WAVEHDR et tout ce qui conerne le waveIn avec la plus grande attention !