Bonjour,
 
je suis débutant en C++, j'ai récupéré un programme pour faire une petite appli pour un projet et voila mon souci..
j'ai un fichier stéréo donc une piste pour chaque enceinte et je souhaiterai pouvoir passer en mono, donc par exemple ne lire que la piste de la voie gauche et l'avoir sur les deux voies..
 
Je paramêtre donc mon entête de wave :  
 
m_datastore = newstore;
 if(m_datastore){  
  m_datastore->GetWavePara(&m_wfx.nSamplesPerSec, &m_wfx.wBitsPerSample,  
  &m_wfx.nChannels);  
  m_wfx.cbSize = 0;
  m_wfx.wFormatTag = 1;
  m_wfx.nBlockAlign = (m_wfx.wBitsPerSample>>3)* m_wfx.nChannels;
  m_wfx.nAvgBytesPerSec = m_wfx.nBlockAlign * m_wfx.nSamplesPerSec;  
  InitQueue();
 
 
je mets ca dans un buffer
 
 m_headerbufferlen = m_wfx.nAvgBytesPerSec/20 * 2;
 for(int t=0; t<HDRCUNT; t++){
  CWaveHdr * phdr = new CWaveHdr();
  ZeroMemory(phdr, sizeof(CWaveHdr));  
  phdr->lpData = new char[m_headerbufferlen];
  m_freeq.push(phdr);
 }
   
et ensuite c'est renvoyé aux enceintes..
 
inline void CWavePlayer::SendToSoundDevice(WAVEHDR * phdr){
 if(phdr){  
  waveOutPrepareHeader((HWAVEOUT)m_hwave, phdr, sizeof(WAVEHDR));
  waveOutWrite((HWAVEOUT)m_hwave, phdr, sizeof(WAVEHDR));
 
voila ce que j'ai compris du fonctionnement..
donc voila à priori je pense que je devrai faire un masque pour mettre à zéro une voie mais je ne vois pas trop comment m'y prendre en fait...
comment acceder aux différents champs du buffer phdr?  
 
Merci pour votre aide ou vos remarques

tu ne peux pas descendre plus bas niveau ?
 
L'appli sur laquelle tu te bases utilise quelle lib pour lire ton fichier ? C'est du DirectX ? de l'OpenAL ?

alors quand je descend plus bas (je suppose que tu parles du remplissage buffer..) j'arrive dans du code obscur que je ne maitrise pas du tout..donc j'esperai pouvoir faire une manip à plus haut niveau..
 
void push_back(const _Ty& _Val)
  { // insert element at end
 
 #if _HAS_ITERATOR_DEBUGGING
  this->_Orphan_all();
 #endif /* _HAS_ITERATOR_DEBUGGING */
 
  if ((_Myoff + _Mysize) % _DEQUESIZ == 0
   && _Mapsize <= (_Mysize + _DEQUESIZ) / _DEQUESIZ)
   _Growmap(1);
  size_type _Newoff = _Myoff + _Mysize;
  size_type _Block = _Newoff / _DEQUESIZ;
  if (_Mapsize <= _Block)
   _Block -= _Mapsize;
  if (_Map[_Block] == 0)
   _Map[_Block] = this->_Alval.allocate(_DEQUESIZ);
  this->_Alval.construct(_Map[_Block] + _Newoff % _DEQUESIZ, _Val);
  ++_Mysize;
  }
 
 
et comment puis je savoir quelle lib j'utilise?? desolé pour mon ignorance :$

Je ne parle pas du remplissage de buffer, et là, tu me sors vraisemblablement du code de la STL qui n'a pas vraiment de rapport avec la choucroute.
 
Le programme que tu utilises est probablement lié avec une lib pour envoyer ses sons, tu peux regarder dans le projet les libs qui sont envoyées au linker
 
Vu qu'en plus, tu te bases sur un programme et pas même une surcouche à une lib audio, il faut vraiment que tu prennes le temps de regarder comment il fonctionne en-dessous. Etant donné que ce fonctionnement dépend de la lib utilisée, ca va être difficile de t'aider sans ca.

à priori si, j'utilise une surcouche audio.. j'ai mon programme auquel a été greffé qqchose récupéré sur le net : Cwaveiobase..  
ensuite quand je cherche les libs de mon projet, la seule chose que je trouve c'est framework SDK, je sais pas si ca répond à ta question.. je n'ai rien trouvé du type directX ou bien openAL..
et pour envoyer les sons, ca utilise une API windows avec ce genre de fonction : WINMMAPI MMRESULT WINAPI waveOutSetVolume( __in_opt HWAVEOUT hwo, __in DWORD dwVolume);
 
je patauge la..

ok, donc c'est du Win32 bête et méchant
visiblement, tu trouveras de la doc là : http://msdn.microsoft.com/en-us/library/aa909811.aspx
 
L'impression que ca donne, après avoir brièvement survolé quelques fonctions, c'est que tout ca est fait pour traiter des fichiers Wav (avec du riff, etc ...) et non pas de les manipuler (genre retirer un canal à la volée)
 
là, tes cannaux sont très probablement entrelacés, si tu veux jouer juste l'un des cannaux, il va falloir que tu le sépares de l'autre et que tu t'en fasses un wav que tu pourras ensuite réutiliser. Ce serait sans doute plus simple que tu sépares le fichier à la source, si tu en as la possibilité

win32 bête et méchant , benh fallait le savoir quand même.. je vais regarder un peu ton lien.
effectivement j'ai un wave, entrelacé, voie gauche/droite/gauche ..
le truc c'est que moi je recois mes waves en stéréo avec 2 voie et je peux pas changer ca. C'est pour ca je pensais faire un petit traitement quand on mets le fichier dans le buffer, genre tous les 8bits, je mets 8 bits à zéro et je dits que je suis sur un seul channel..comme ca je me retrouve avec un son stéréo.. mais pour ca je sais pas comment m'y prendre :s

si tu mets à 0 l'un des cannaux, tu devras toujours jouer les deux ca&nnaux, du coup, et, admettons, si tu vides le canal de droit, alors le canal de gauche ne viendra pas le remplacer par magie, tu n'auras que du son à gauche.
 
Eventuellement, tu pourrais dupliquer les données. Si tu fais ca, attention à la qualité de l'échantillonnage (4, 8, 16, 24 bits ? signés ou non ?)
 
Mais bon, c'est de la réparation avec du scotch

héhé pas si je force le canal en faisant croire que j'ai un buffer mono...
j'ai fait le test en forcant le nombre de canaux à 1.  
Et la en fait, il me lis les 2 bandes mixées entre elles (mon buffer) sur les deux enceintes..donc si j'arrive à mettre aucun son dans sur une voie, j'aurai donc mon son de la voie qui reste qui sera joué sur les 2 enceintes, tu me suit?
donc pour moi le truc à faire serait de mettre une partie du buffer à zéro..
c'est ptète pas joli ms ca devrait pouvoir marcher je pense..une idée sur comment faire ca par contre? je reste bloqué pour mettre à zéro une partie du buffer

et penser à changer le nombre de sample par seconde aussi, passer de 44100 à 88200 sinon je vais lire au ralenti
personne pour un conseil pour mettre le buffer à 0? au moment ou je le rempli, il n'y aurait pas moyen en faisant une boucle ou qqchose dans le genre?

Je ne suis pas convaincu que ton matériel acceptera de jouer du 88200
 
Et si tu es capable de modifier ton buffer, pourquoi ne pas simplement le mettre au bon format, à savoir, extraire le canal qui t'intéresse et en faire un autre buffer ?

benh j'ai testé le 88200 en debug et a priori ca passe, j'entend mon son..
oui pourquoi pas le coup d'extraire ce qui m'interesse..comment puis-je proceder pour faire ca? j'ai un peu de mal à jouer avec ce buffer..

il faut allouer un nouveau buffer de la bonne taille (taille de sample * nombre de samples * nb de canaux) et copier tes données dedans à la main
 
Edit : tu dis être débutant en C+, mais j'estime mal ton niveau ... Tu es familier avec l'allocation dynamique, avec les types standards genre std::vector ?

oui mais voila, je ne sait pas comment faire ca à la main, je ne comprend pas comment accéder à mon buffer en fait.. dès que je tente qqchose, ca plante mon appli.. je peux pas faire une simple boucle sur les elements que je souhaite avec qqchose du genre newbuffer[i] = phdr[i];
le souci c'est comment accéder aux données de mon buffer en fait
 
pour mon niveau en C++, disons que j'ai fait du C mais je n'ai jamais eu à utiliser l'allocation dynamique ou les tableaux dynamiques..mais à priori c'est plus simple en C++ qu'en C..j'ai une connaissance école en fait..

ok donc j'ai regardé un peu le siteduzéro, mauvaise manière de faire en C++, donc utiliser les std::vector.. tableau dynamique et non statique donc ce que je voulai faire n'est pas possible.. ca promet :s

possible mais pas recommandé..
et transformer ca pour y mettre un type vector ca va etre plus compliqué que ce que j'imaginai moi..

le siteduzéro n'est pas recommandable.
 
Bref, si tu es sur que tes données sont signées et en 16 bits, tu peux te faire un vector<short> buffer; faire un resize() ) la bonne taille (nb samples * nb canaux) et ensuite, lorsque tu as besoin de le transmettre à la couche bas niveau, tu peux donner l'adresse sur le premier élément : &buffer[0]
 

mais je mets comment dans mon buffer?
buffer = phdr->lpData ? ca passe pas ca..

tu copies à la main en parcourant le bufferet en lisant un sample sur deux avec une boucle for, ou si tu veux être vraiment c++, un std::foreach  
 
avec une simple boucle, ca doit donner quelque chose comme ca :
 

 
Edit : Et dans ton nouveau header que tu feras, il faudra que ton lpData pointe sur &newBuffer[0]
Fais bien attention que, si jamais ton vector est détruit, tes données seront libérées, donc il faut que la lecture de ton son soit terminée !

alors..
moi déja dans phdr->dwBufferLength  j'ai toujours 0..donc je suppose qu'en remplacant par m_headerbufferlen, ca revient à ce que tu veux faire.
ensuite pourquoi tout mettre en short? y a t'il une raison particulière a cela? car il me jette si je mets newbuffer dans lpdata car incompatible..donc je mets tout en char, plus besoin du reinterpre_cast et la il compile.
 
enfin bref j'arrive à avoir un buffer, avec des données dedans, je sais pas si ce sont les bonnes, je verrais..
 
j'ai ajouté ca comme tu me l'a dit..
phdr->lpData = &newBuffer[0];
  m_freeq.push(phdr);
 
et la mon programme plante

dans quel format sont tes samples ?
 
Edit : j'ai supposé que tes samples étaient en 16 bits signés, d'où l'exemple avec des shorts, mais tu adaptes. Il manquait un reinterpret_cast supplémentaire pour convertir de short* à son char* à lui, c'était ca le souci de compilation que tu as eu

benh à priori c'est du 16bits signés.
ca pause un souci si je mets tout en char ?  
 
j'ai ca au final
char *pCurrentBuffer = phdr->lpData  
int nbSamples = m_headerbufferlen / 4; // 2 canaux, 2 octets par sample  
newBuffer.reserve( nbSamples );
for( int i = 0; i < nbSamples; ++i )
{
newBuffer.push_back( pCurrentBuffer[ i * 2 ] );
}
phdr->lpData = &newBuffer[0];  
m_freeq.push(phdr);
 
mais ca plante

ben, ca ne veut plus rien dire ...
Tu dois manipuler des samples. Si on te dit que tes samples font 16 bits et que tu copies un octet sur deux, c'est juste complètement faux
 
Edit : et quand tu dis que ca plante, je parie que tu n'as pas tenu compte de ma remarque d'avant, à savoir, que le buffer doit avoir une durée de vie supérieure à celle du son ...

ok je vois ce que tu veux dire..je retenterai avec des shorts..
pour la durée de vie du buffer, non pour l'instant j'en est pas tenu compte, mais en même temps y a t'il un moyen pour eviter que le buffer soit killé? En fait dès que je sors de ma fonction c'est killé c'est bien cela, mais moi avec le push, je pensai que c'était bon non? une fois le push effectué, le buffer ne sert plus non?

tu lui donnes un pointeur sur un header et qui contient un pointeur sur des données. Je doute qu'il les duplique de son côté.
 
Et donc, oui, tu as raison, ton vecteur est détruit en fin de bloc où il a été déclaré. Il faut donc trouver le bon endroit où le mettre.
En théorie, si tu fais de la prog objet, il y a de bonnes chances que tu aies une clase pour représenter un son et le manipuler. Cette classe s'assurera de conserver la validité du buffer.

"tu lui donnes un pointeur sur un header et qui contient un pointeur sur des données. "  ??? tu peux m'expliquer stp..

je décrivais juste ce que tu fais actuellement pour lire un son, tu lui passes phdr qui est un pointeur sur sa structure de header, et cette structure contient un pointeur vers les données à traiter. Il y a probablement un moment où ces données vont être envoyées à du matériel dédié pour la lecture du son, mais tu ne peux pas faire de suppositions quant au moment où cette copie sera terminée (ni même si elle sera vraiment faite au final).
 

bon j'ai rententé avec ta méthode :  
vector< signed short > newBuffer;
signed short *pCurrentBuffer = reinterpret_cast<signed short*>( phdr->lpData );
int nbSamples = phdr->dwBufferLength / 4; // 2 canaux, 2 octets par sample  
for( int i = 0; i < nbSamples; ++i )
{
  newBuffer.push_back( pCurrentBuffer[ i * 2 ] );
}
phdr->lpData = reinterpret_cast<char*> (&newBuffer[0]);  
m_freeq.push(phdr);
 
donc voila, ca ca compile, après avoir mis en commentaire un truc dans le fichier vector, il me tappait une erreur mais je sais pas trop pourquoi. Par contre j'y suis allé en debug et mon buffer n'a pas l'air d'avoir changé des masses.  
quand je regarde après, au moment ou il y a la préparation du header, j'obtiens les mêmes valeurs qu'avant dans m_freeq ... je comprend pas!! pourtant ta méthode me semble plutot intelligente, je pensai comprendre mais bon ca veut pas.. donc soit c'est le push qui vas pas, soit c'est ailleurs, parce que dans phdr->lpdata, ya l'air d'y avoir moins de données quand même..

Ptite question je n'ai pas l'impression qu'avec ce la on recupère la partie souhaitée :  
déja on ne balayera pas la totalité du buffer, étant donné que celui ci fait "phdr->dwBufferLength / 4" et qu'on balaye de 0 à nbSamples non? il faudrait faire 2*nbSamples non? car 2 voies..
et encore d'après la doc wave : Each sample is contained in an integer i. donc la d'après ce que je comprends, j'aurai un sample sur 2 mais qui contiendra voie droite et voie gauche.. d'accord avec ca ou je me plante complètement?
e donc c'est plutot divisé par 2 et non par 4 car i est sur 2 octets car c'est un int...
car ca fait qqchose du genre LeftLow    LeftHigh   RightLow   RightHigh...
                                            0                          8                                 16
enfin je pense...d'accord avec ca ou pas?
 
 

 
si c'est du vector qui se trouve dans les headers standards de ton compilateur, tu n'as pas à le changer. Jamais. Si tu as une erreur de compilation, ce n'est pas dans ce fichier que tu la changes. Après, je ne sais pas si tu as un fichier vector à toi.
 

 
si tu regardes la boucle, tu noteras que je parcours n samples parce que, pour chaque voix, il y a n samples. Ensuite, quand je lis un sample, je lis à l'index i*2 parce que je prends un sample sur deux.
 

 
Le layout mémoire est très probablement ce que tu décirs. Tu dois donc aussi être d'accord que le fait que, si tu ne prends que les short (paquets de 16 bits, donc) de numéro pair (c'est ce que représente le i*2), tu devrais extraire une voix et non pas avoir des données des deux voix.
 
sur ton exemple, tu es bien d'accord que si j'ai un pointeur sur la première adresse et que je fais p[0], j'obtiens un short composé de LeftLow et LeftHigh et que si je fais p[1] j'obtiens un autre short composé de RightLow et RightHigh ?

du coup j'ai essayé tout autre chose en me disant que ca pourrait ptète coller aussi
 
vector< signed short > newBuffer;  
signed short *pCurrentBuffer = reinterpret_cast<signed short*>( phdr->lpData );  
for( int i = 0; i < m_headerbufferlen/2; ++i ) //2 canaux
{  
  pCurrentBuffer[ i ] = pCurrentBuffer[ i ] & 0xFFFF0000 //masque pour garder que le gauche
  newBuffer.push_back( pCurrentBuffer[ i * 2 ] );  
}  
phdr->lpData = reinterpret_cast<char*> (&newBuffer[0]);    
m_freeq.push(phdr);  
 
 
 
mais pareil, ca rempli le buffer, j'ai des choses dans m_freeq..et pis après ca plante..  
mais l'idée te semble t'elle bonne aussi?

j'utilise le vector de visual mais bon ca me faisait une erreur alors que j'avais enlevé toute reference à vector..donc pas le choix que modifier ca, j'irai voir ca après..
ensuite incomprehension du fait que pour toi, sample = 8bits d'une voie et pour moi, sample = 16bits des 2 voies..
d'accord avec ton p[0] et p[1]..

deux choses, d'une part, tu modifies le buffer source, ce qui n'est jamais une bonne idée (tu pourrais vouloir t'en resservir plus tard) et d'autre part, non, c'est complètement faux si tes samples font 16 bits. et même, ca n'aurait pas de sens dans le cadre de samples 8 bits
 
Ensuite, ton m_headerbufferlen est-il exprimé en octets ?  S'il est exprimé en octets, tu dois le diviser par 4, sinon, à nouveau, c'est faux ...
 
J'ai l'impression que tu fais des modifications au hasard. Utilise un debugger, trace ce que ton programme fait, mais arrête de tenter de faire quoi que ce soit tant que tu ne comprends pas ce qui se passe

mon m_headerbufferlen c'est un long.
j'essaye d'y aller au debugger mais je ne comprend pas tout non..
le coup du diviser par 4 je l'ai pas. mettons que m_headerbufferlen = 4000, nbSamples = 1000.  Je fais ma boucle au maximum, je vais arriver à 2*1000=2000.. il manque quand même les 2000 derniers, donc les 500derniers samples... j'ai l'impression que plus ca va, plus je patauge :s

Ce que je demande, ce n'est pas son type, mais l'unité dans laquelle est exprimée la taille du buffer. Ca peut être, au choix : nombre de samples, nombre de samples pour un canal ou nombre d'octets.
 

 
taille en octets == nb samples * nb canaux * taille de sample
 
on sait que taille de sample vaut 2 (octets), que nb canaux vaut 2 et j'ai supposé que m_headerbufferlen était la taille en octets
 
m_headerbufferlen  == nb samples * 2 * 2
 
or, ce qu'on veut, c'est le nombre de samples donc :
 
nb_samples = m_headerbufferlen / 4
 
Dans mon parcours du buffer source, si tu lis correctement, je remplis mon nouveau buffer avec le bon nombre de samples. Ces samples, vont bien venir du buffer source, mais je vais en prendre un sur deux (d'où le i * 2 en indexant la source)

ok, donc c'est m_headerbufferlen = m_wfx.nAvgBytesPerSec/20 * 2;  
et j'ai compris ton raisonnement.. enfin !
mais pas pour autant que ca marche .. mais je suis d'accord avec toi, et j'ai compris donc c'est deja pas mal.. pas habitué à jouer avec les cast..
et à priori c'est pas du au fait que le vector soit killé vu que j'ai fait un push avant, et je retrouve bien mes données plus loin..

pour en revenir à ton crash ... C'est quoi ton problème pour tracer ? Tu utilises quel environnement ? Visual Studio ?

oui visual 2010
en fait j'ai un accès violation..et il me pose dans un fichier assembleur.. à priori en remontant, le phdr ne serait pas bon à un moment et bim ca plante.. il pointe pas la ou il faudrait.

ca plante de ton côté ? dans un appel système ?
 
Tu t'es bien assuré que la durée de vie de ton buffer (dans le vector) était suffisante ?

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?