Reprise du message précédent :
hé bien j'ai plusieurs appels bon et a un moment le pointeur n'est plus bon et hop ca crash.
et pour la durée de vie du vector, je fait le push dans la même fonction donc après même si c'est killé ca devrait aller non?

non, ca ne devrait pas aller.
Il y a à peu près 99% de chances qu'il conserve juste l'adresse vers les données de ton vecteur.
Il en va de même pour le pointeur vers ton header. Il faut que tu t'assures que tout ca reste bien alloué pendant tout le temps où tu en as besoin.
 
Si le source n'est pas trop long, tu pourrais peut-être le poster ici.

il est quand même costaud le source.. , y fait environ 500Mo
et il n'y a pas un moyen pour le faire survivre un peu ce vecteur?  pasque la ya des threads et tout ca..donc je suis pas sur que je puisse allonger le temps de vie de cette fonction..je vais voir ce que je peux faire..j'ai quelqu'un qui va m'aider un peu dessus demain..je te tiens au courant mais j'ai deja compris beaucoup grace a toi merci

bon alors on m'a conseiller de passer par des pointeurs.. et donc ca donne quelque chose comme ca..
 
 
  // nombre de canaux
  const size_t nbr_canaux = 2;
  // nombre d'octet par sample
  const size_t nbr_octet_par_sample = 2;
  // canal que l'on souhaite garder 0 ou 1:
  const size_t canal = 0;
  // où on va écrire la valeur
  signed short *pCurrentBuffer = reinterpret_cast<signed short*>( phdr->lpData );
  // la valeur à lire :
  signed short const *pNext = pCurrentBuffer + canal;
  int nbSamples = m_headerbufferlen / (nbr_canaux * nbr_octet_par_sample);
  for(unsigned long i=0; i<nbSamples; ++i)
  {
   *pCurrentBuffer = *pNext;
   // on écrit au short suivant :
   ++pCurrentBuffer;
   // mais on saute le bon nombre de canaux :
   pNext = pNext + nbr_canaux;
  }
 
  phdr->lpData = reinterpret_cast <char*> (&pCurrentBuffer[0]);
  phdr->dwBufferLength = nbSamples * nbr_octet_par_sample;
  m_freeq.push(phdr);
 
donc avec ca ca lit, mais j'ai exactement la même chose qu'avant, à croire que le traitement change rien.. pourtant en pas à pas ca à l'air de faire ce que je veux, écrire un octet sur 2..

dans quoi penses-tu stocker les donées concernant ton canal ?

benh je les place à partir de pCurrentBuffer[0].. d'ou la relecture après via phdr->lpData = reinterpret_cast <char*> (&pCurrentBuffer[0]);  
et dans pCurrentBuffer[1], j'ai ce qu'il y a dans lpdata[2] et ainsi de suite..
il est ou le souci?

Je trouve ca un peu triste d'écraser tes données source, qui plus est, tu ne pourras pas même libérer la mémoire correspondant au canal que tu as retiré.
 
le &pCurrentBuffer[0] est strictement identique à pCurrentBuffer (on avait besoin de cette gymnastique avant parce que le buffer était une instance de std::vector)
 
du reste, ca a l'air correct, à condition que m_headerbufferlen  soit juste. As-tu vérifié si les valeurs te semblaient correctes vis-à-vis du wav que tu utilises ?

benh pour l'instant je fait comme ca, une fois que j'aurai réussi à avoir mon son, je verrai comment dupliquer.. paske la pour l'instant ca marche po!
ok pour le &pCurrentBuffer[0]..j'ai fait un changement bête et méchant
oui j'ai changé m_headerbufferlen, je l'ai divisé par 2.
mes valeurs le problème c'est que en debug je vois mon buffer rempli de I : -12831..et c'est ca tout le long..donc impossible de savoir si ca a bien copié ou pas..
par contre, je vois bien que mon buffer est plus petit.. et à la lecture, que j'accelère à 88200, et bien c'est le même son qui sort..à croire que ca n'a rien changé.. étrange..

 
tu n'as pas à changer la fréquence d'échantillonnage de ton buffer dans ton cas ... Ca reste du 44100 si, en entrée, tu avais du 44100, tu n'as fait que retirer un canal
 
Ce que je voulais dire à propos de m_headerbufferlen, c'est que le calcul que tu me montrais plus haut smelbait douteux. Ce que je te demande, c'est, étant donné que tu dois connaître la taille exact de ton wav en entrée, la valeur stockée dans ce m_headerbufferlen te semble cohérente et valide ?

et bien en fait je force le nombre de canal à 1, histoire d'avoir du son sur les 2 enceintes et c'est donc pourquoi j'ai accéleré à 88200.. mais je vois pas pourquoi cette modif serait génante ensuite.
pour ta question, étant donné que sans modif, cela fonctionne, je me retrouve avec un m_headerbufferlen d'une certaine taille donc comme j'enlève un canal, il me parait logique de le diviser par 2.. c'est ca qui me permet de dire que c'est bon car sinon la taille du m_headerbufferlen je ne sait pas comment elle est calculée..
j'ai un wave de 774ko et le buffer fait 17640.. et je fait cet appel 8fois..mais je connais pas le lien..

ptite technique de sioux, si jamais plutot qe faire ca, je copie ma voie droite sur ma voie gauche...et que du coup je modifie aucun buffer, aucun canal..et ptète ca marcherai aussi..
for(unsigned long i=0; i<nbSamples; ++i)  
  {  
   *pCurrentBuffer = *pNext;  
   // on écrit au short suivant :  
   ++pCurrentBuffer;  
   *pCurrentBuffer = *pNext; //copie d'une voie sur l'autre..
   // mais on saute le bon nombre de canaux :  
   pNext = pNext + nbr_canaux;  
  }  
 
ca pourrait etre pas mal ca aussi non?

tu as un buffer avec deux canaux en entrée, chaque canal à 44100hz comme fréquence d'échantillonnage. Tu retires un canal, soit ... Ca change rien à la fréquence du canal qui reste
 
et sinon, ton algo pour copier une voie sur l'autre est fauxtu ne peux pas assumer que le canal sur lequel tu veux recopier est le suivant, ca pourrait être le précédent, ou sinon, tu vas te retrouver avec un (certes très léger) décallage de phase de tes sons
 
Edit : Quand je vois la manière dont tu procèdes, je n'ai qu'une envie, c'est de te dire d'arrêter, de poser tout sur papier, formellement, ce que tu veux faire. Prendre le temps de comprendre la structure des données que tu as en entrée, celle que tu veux en sortie, parce que j'ai l'impression que tout n'est pas clair.

mouai je vois le truc ms si je force en mono, alors mon son est au ralenti..
mais bon jvé tenter la deuxième méthode qd meme, même avec un léger décalage, ca serait déja pas mal.. quitte à régler un peu après, si deja j'arrive à virer une voie, yaura un pas de fait..
 
edit : en même temps je ne connaissai rien du tout au format wave, et je galère en C++.. mais du coup en essayant, ya des idées qui viennent..

oui, enfin, en soi, tu n'auras pas vraiment viré une voie
 
Je me demande tout de même comment tu te retrouves à bosser sur un source de 500Mo (c'est titanesque ! ce n'est pas un projet perso ou un tutorial, à ce niveau là) à faire des modifs aussi hasardeuses sur des sons, alors que, pour le besoin que tu as (passer un son en mono) le sens commun dicterait bien de prendre le fichier d'où le son est tiré et d'en faire une version mono, tout bêtement

bon j'ai remplacé par un strncpy..et ca fonctionne bien, j'ai un son stéréo.. donc voila, j'ai pu qu'à essayer de faire en sorte que ca marche que quand je le souhaite.. merci pour ton aide en tout cas

... euh, c'est une blague ?

benh non même pas.. en regardant ce que faisait la fonction, j'ai regardé un peu ce qui existait et pis voila j'ai rempli mon buffer comme il fallait et je me retorouve avec un son stéréo, pas de décalage..donc pour l'instant je reste avec cette solution..

tu te rends compte de ce que va faire strncpy ?
 
Es-tu sur d'avoir rempli ton buffer comme tu le voulais à l'origine ?

et bien en fait par rapport à ce que je voulai au départ c'est sur mais tu m'avais dit de poser la chose et il s'est avéré qu'il y avait plus simple pour faire ce que je voulai.. mais bon ca m'a permis de comprendre certaines choses dc c'est plutot bon.. maintenant j'essaye de faire passer une information d'une class à une autre.. en C j'aurai fait une variable globale mais la je suppose qu'il y a plus intelligent.. bref beaucoup à apprendre encore

lis la doc de strncpy.
D'une part, c'est une fonction C, pas C++, d'autre part, tu vas avoir des surprises dans de nombreux cas suivant ce qu'il y a dans tes buffers ...