LoL,
Excelent oui, pour les gourmants

bah perso, merci pour le source, et les explications sur entercriticalsection();
dechire je galere un peu sur le thread, ce source est franchement cool pour ca, je met 10 directe, car tu t'es bien casser le cul je trouve franchment MERCI !!!

bah test ce source la:
-il reprend une partie amelioré de la gestion d'entrée de l'oscillo
-il ajoute la gestion de la sortie
-et permet de faire passer les données dans des socket (donc sur le web) et tcp
un petit webphone quoi, essaye de voir si il s'ouvre chez toi !!!
http://www.vbfrance.com/article.aspx?Val=7834
A++

pareiile, nikel !

Trs bonne idée je trouve !!!!

ourch,
si ca marche c'est tres bien, mais je trouve ca archi lourd deja, alors que tu ne travail pas sur le spectre, alors imagine si tu commence a vouloir raboter les raies inutile du spectre, aille !
tu arrive a quelle rendement avec ce systme ?

j'ai recu pas mal de mail aussi sur la compression.
deposez vos explications ici, ce serait mieux ;)
voila donc mon systeme de codage qui compress pas mal, mais avec un fft par dessus ca serrait le tope
il y'a quelques distortion assez peut perceptible, cette compression est destructive...

points clef: (je me basse sur du 8khz 8 bit pour + de comprehenssion)
------------

deja si vous mattez les valeur d'un signel audio. (mettez la sortie de winmm en 8bit, et ecrire les données ligne par ligne dans un fichier et parlez dans votre micro)
vous verez tres vite que les valeurs sont tres proches les une des autres, j'ai donc opté pour un codage delta...
c'est a dire que j'envois la diference entre chaque echantillons et pas l'echantillon lui meme
le 1er echantillon est envoyé, puis la 2nd valeur est la difference entre les 2 echantillons..
vous me suivez ?
sur un buffer entier on a donc une premeire valeur puis des valeur assez petites (proche de zero)
maintenant imaginé qu'on fait la moyenne de TOUTES ces valeurs et que l'on balance:
d'abors la valeur de la moyenne, puis ensuite la difference entre les valeur (elle meme differentielle).
on a donc des valeur encore + proche de zero que tous...
un buffer plein de valeur proche de zero et un octet en + pour la moyenne)
ou est la compression me direz vous ?
attendez...

imaginez maintenant, que les donnees envoyé ne soit pas de la meme taille, c'est a dire que le code pour representez un octet ne soit pas 8 bit o_O

on sait aussi que:
-nos valeur sont proche de zero !

donc on a besoin de presision dans les petite valeurs et moins dans les grandes valeurs...

ainsi on pose:

1         =0
01        =1
001       =2
0001      =4
00001     =8
000001    =16
0000001   =32

voyez vous l'intert d'un tel codage ?
la presision est dans les petites valeurs et le nombre de bits pour celle si est petits,
comme on en a beaucoup, c'est plutot cool...
et puisqu'il est de longeur variable (c'est du binaire ici), pour le decodage il faut une 'balise', icic le bit a 1
mais au fait, la difference peut etre + ou - ?
oui, obligé de rajouter un bit alors...

1          =0
010        =+1
0010       =+2
00010      =+4
000010     =+8
0000010    =+16
00000010   =+32

1          =0
011        =-1
0011       =-2
00011      =-4
000011     =-8
0000011    =-16
00000011   =-32

voila, rien ne nous empeche de continuer le code, ou de modifier les valeurs de precisions, mais il faut que l'emtteur et le recepteur (compresseur et decompresseur) soit au courant de cette table...
(la moyenne n'est pas forcement codé ainsi)

bien sur vous voyez aussi que ce compresseur est destructueur, impossible de coder un valeur de 11, ici on prendra 8 (le + proche)
et imaginé que vous vouliez passez de 0 a 127, il faudra alors 4 echantillons, donc un temps de reaction tres long pour les grande differentielles...

bref, cette methode de compression est quand meme efficasse et dechire moi le son que d'echantilloné a 4000ko ou de prendre un echantillons sur 2...
les debit peut etre divisé par 1,5 voir 2
(nteraissant pour un multi chat vocal ;) )

une fois ceci fait, vous pouvez aussi passez un coup de RLE (run lentgh encoding) qui a pour role deremplacer
une longue serie de zero (binaire) par une balise et ou un indice en debut de buffer...
(moi j'ai mis un indice et le nb de zero dans le debut de l'envois du buffer

avec le rle, vous divisez par 2 voir 3 les debit soit 4Ko a 2 Ko...

voila j'espere que vous avez captez, bien codé ca prend pas enormement de ressources...
(j'ai triché , j'ai codé en c++ la manip des bit, en vb je sait pas faire ou alors trop couteux en patate))

bref, moi actuelment je cherche a mettre un coup de fft la dessus, ainsi
je pensse pouvoir descende en dessous du 1.5 ou 1 Ko
(sympa pour les modem ;) ...)

A++

ce truc sert a montrer la base du stream,
avec wimm et 2 sockets, franchement tu peux streammer test propres echantillon, comme tu le sents winmm est fait pour ca hex_man matte quelque doc la dessus, tu verra c'est simple
winmm est un point d'entree et sortie qui te permet de filer ou de recuperer de windows des buffer's plein'd 'octets'
apres a toi de les faire passer dans  les tuyaux (socket ou autres) comme tu le sents
dure de controler + que ca en vb sans que ce soit trop incomprehenssible...

Approche Winmm:
---------------
en fait la dll winmm.dll est dispo dans depuis les 95 dans les windows,
dans cette dll vous trouvez donc un enssemble de fonction et d'adresse pour echanger de l'info
avec votre matos audio. (l'interet c'est compatibilité, et control 'Bas niveau' des octets sonor)
l'utilisation est assez facile:

vous allez balancez des données ou en recevoir de winmm, par l'intermediarede buffers, ces buffers contiennent, les donéess du son et des données propres a winmm (taille du buffer, format, etc..)
winmm est decomposée en 2 jeux (buffers et fonctions): IN et OUT
pour l'utilisez l'un ou lautre il faut:
-ouvrir le matos sonor (in ou out)
-balancer ou recuper les info
-fermer le matos sonor

pour ouvrir le periph d'entree ou sortie (idem):
-1/ choisir un nom fixe de buffer pour winmm
-2/ preparer son format audio (96Khz, 16 bits ou autre...)
-3/ preparer les buffers (allouer la memoire,position des flag,format,etc..)
-4/ Passer le pointeur vers les buffer a winmm
-5/ lancer l'ouverture (aquisition ou lecture)
-6/ verifier l'ouverture

pour fermer le periph d'entree ou sortie (idem):
-1/ DE-prepare les buffer (vire les pointeru de winmm)
-2/ on desaloue la memoire
-3/ on ferme le periph

Winmm remplie le buffer un a un (ou joue le son des buffer un a un) suivant
l'etat du flag

IN:
---
pour utiliser le periphe en in:
1/ scruter tous les buffer 1 par 1
2/ matter leur flag
3/ si le buffer est pres, recuperer les infos du buffer courant et le balancer dans le sock ou autre
4/ mettre le buffer comme dispo
5/ recommencer a l'infini ^^ !!

OUT:
---
pour utiliser le periphe en in:
1/ scruter tous les buffer 1 par 1
2/ matter leur flag
3/ si le buffer est dispo, remplire ce buffer des octets du son a jouer provenant du socket ou autre..
4/ mettre le buffer comme 'pres a etre joué'
5/ recommencer a l'infini ^^ !!


voila comment ca s'utilise, mattez le module MWinMM dans le source vous trouvez ainsi les rapport
entre explication et nom de fonctions et etat des flags. dans ce module un enssemble de fonction est dispo pour facilement
utiliser winmm, (exemple lecteur vraiement perso (a vous de coder les filtres et tous...)

avec winmm vous avez le controle total du matos...


c'est po tres dure

merci pour la note, et pour les mail, c'est sympo...
mattez aussi une variante de la combox ici:
http://www.combox.fr.st
A++