C / C++ / MFC

25-Jul-10 9:30

hello guys....im new to this. I have a mic attached to my PC. Now following code should show appropriate message but it does't.

/////// some declarations
const int NUMPTS = 8000 * 10;
int sampleRate = 8000;
short int waveIn[NUMPTS];
HWAVEIN hWaveIn;
WAVEHDR WaveInHdr;
MMRESULT result = 0;

// waveInProc function....
void CALLBACK waveInProc(HWAVEIN hwi,UINT msg, DWORD dwInstance, DWORD dwArg1, DWORD dwArg2) {
	
	switch(msg) {
		case WIM_OPEN:
			MessageBox(NULL,"Device Opened Successfuly","Device Opened",NULL);
			break;
		case WIM_DATA:
			MessageBox(NULL,"Data Recieving","data",NULL);
			break;
		case WIM_CLOSE:
			MessageBox(NULL,"Device Closed Successfuly","Device Closed",NULL);
			break;
		default:
			break;
	}
}

void CwaveFileDlg::OnOpenDev() //button using which the input device is opened
{
	CFile file;
	CFileException cfe;
	TCHAR* filename = "d:\\file.wav";
	WAVEFORMATEX pFormat;//assume that values are set correctly

	if (!file.Open(filename,CFile::modeCreate|CFile::modeReadWrite,&cfe))
		MessageBox("File could't be opened","",cfe.m_cause);

	result = waveInOpen(&hWaveIn,WAVE_MAPPER,&pFormat,(DWORD_PTR) waveInProc,(DWORD_PTR) this,(DWORD)WAVE_FORMAT_DIRECT);
}

what can be the reason??

Luc Pattyn25-Jul-10 9:37

25-Jul-10 9:37

I suggest you improve the observability by adding:
- a MessageBox showing the result of waveInOpen()
- a MessageBox showing the value of msg in your switch default.

Chances are that will tell you what is really going on.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.

AmbiguousName25-Jul-10 9:54

25-Jul-10 9:54

1) I had a MessageBox for waveInOpen for both cases (true and false against MMSYSERR_NOERROR) but removed them for making it look less complicated. swicth default message can be added but only if goes in the switch (specifically....waveInProc), but there is an error b4 that. When I debug, it shows 32 against the MMRESULT variable (result).

Luc Pattyn25-Jul-10 10:00

25-Jul-10 10:00

if you have an error number or message, you should take it from there.
32 probably is WAVERR_BADFORMAT, so your data is bad.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.

AmbiguousName25-Jul-10 10:03

25-Jul-10 10:03

well im new to this, and this is getting me little confused. I am not using any data, it is just the mic attached to PC (input device), so which data is bad??

Luc Pattyn25-Jul-10 10:09

25-Jul-10 10:09

The line I suspect most is:

WAVEFORMATEX pFormat;//assume that values are set correctly

Why would the values be correct (and why do you remove debug statements) while the lot isn't working yet?
I'm not familiar with all this, but from what I see, you either didn't read the documentation or made some mistake. You have two choices: locate the problem yourself, or accurately provide actual code and symptoms.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.

AmbiguousName25-Jul-10 10:15

25-Jul-10 10:15

There is nothing to hide...following are the lines after the suspected line

pFormat.wFormatTag = WAVE_FORMAT_PCM;			//simple, uncompressed format
pFormat.nChannels = 1;					//1 = mono; 2 = stereo
pFormat.nSamplesPerSec = 8000;
pFormat.nAvgBytesPerSec = 16000;
pFormat.nBlockAlign = 1;
pFormat.wBitsPerSample = 16;
pFormat.cbSize = 0;

I wanna make it clear that it is logical error (that audio input device is't opening), not the syntax error (if I have made things complicated).

Luc Pattyn25-Jul-10 10:32

25-Jul-10 10:32

I don't think your values satisfy the documented requirements:

nBlockAlign (not OK)

Block alignment, in bytes. The block alignment is the minimum atomic unit of data for the wFormatTag format type. If wFormatTag is WAVE_FORMAT_PCM, nBlockAlign should be equal to the product of nChannels and wBitsPerSample divided by 8 (bits per byte).

nAvgBytesPerSec (OK)

Required average data-transfer rate, in bytes per second, for the format tag. If wFormatTag is WAVE_FORMAT_PCM, nAvgBytesPerSec should be equal to the product of nSamplesPerSec and nBlockAlign.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.

AmbiguousName25-Jul-10 10:47

funny crash, do you know why?

25-Jul-10 10:47

thanx....thanx alot. I hope I"ll b able to do something better now, while discussing this, I tried all the error options returned by waveInOpen and it was WAVERR_BADFORMAT. lets hope kim clijster wins the US Open once again... Smile | :)

includeh1025-Jul-10 8:53

includeh10

25-Jul-10 8:53

My app crashed, I did find probrlm point.
to simplify code, I add a line inside crashed function for testing:

BYTE*pp=new BYTE[iSize];

iSize is an int,
if iSize is 1016, the line is OK.
if iSize is 1017, the line crashes, that is, the pointer can't be allocated, or pp is NULL.

My PC has 2G memory, so memory should be OK.

Do you know why?
virus? VC problem? Project settings?

Luc Pattyn25-Jul-10 9:40

25-Jul-10 9:40

maybe the statement is executed many times before it crashes your app, as memory is really running low?
you should show actual code to get effective help!

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.

elchupathingy25-Jul-10 10:29

elchupathingy

25-Jul-10 10:29

If that memory is not free'd then you have introduced a memory leak and as stated above me this could very well be the reason for the crash in that its running out of memory, but more code would help greatly.

Sauro Viti25-Jul-10 10:42

Sauro Viti

25-Jul-10 10:42

includeh10 wrote:
My PC has 2G memory, so memory should be OK.

Be aware that each executable file has an header that hold information about the heap commit size and heap reserve size (see /HEAP (Set Heap Size)[^]); the reserve size has the meaning of the maximum stack size that your executable can use, and its default is 1 MB.

If you are allocating more than 1 MB (both in a single shot or with multiple allocations), you can get a similar problem; it doesn't matter if your system is equipped with 2 GB.

«_Superman_»25-Jul-10 18:45

«_Superman_»

25-Jul-10 18:45

Put the new inside a try/catch block which should give you some more information regarding the crash.

try
{
    BYTE*pp=new BYTE[iSize];
}
catch (exception& e)
{
    cout << e.what();
}

«_Superman_»

I love work. It gives me something to do between weekends.

Microsoft MVP (Visual C++)

Polymorphism in C

ThatsAlok25-Jul-10 20:09

ThatsAlok

25-Jul-10 20:09

«_Superman_» wrote:
try
{ BYTE*pp=new BYTE[iSize];}catch (exception& e){ cout << e.what();}

It one the correct way to resolve problem, but still there are some exception which can't be handlled by exception block too.

cheers,
Alok Gupta
VC Forum Q&A :- I/IV
Support CRY- Child Relief and You

Aescleal25-Jul-10 21:26

Aescleal

25-Jul-10 21:26

Seeing as the man said the pointer was sometimes 0 when it came back from new he's using an antique compiler which doesn't follow the standard (e.g. VC++6). Catching anything isn't going to help here.

Cheers,

Ash

shortcut for going to function definition

Alan Balkany26-Jul-10 5:13

Alan Balkany

26-Jul-10 5:13

It could be a symptom of another memory problem elsewhere. Enable memory testing and rerun your program.

It could also be (as someone else suggested) a memory leak being repeatedly executed. If so, this one is easy to fix: make the bb variable static and initially NULL. Then if it's not NULL, free it before assigning the new buffer to it.

AmbiguousName24-Jul-10 22:49