|
You're welcome. 
|
|
|
|
|
Hello , I wanted to re-ask my previos question , since I made some progress. And I want to clear some stuff in my head.
1. BUFFERING "STEREO" STREAMS : I use the code below . Generally 8000 bytes passed to callback function.
Since my each sampleis 16bit , that is about 4000 samples for each call. So I defined CHANNEL_SIZE as 2048 which is approriatefor total sample count. I made it 2048 as power of 2 because I will implement FFT .
What do you think about that buffering approach ?
.................................................
#define CHANNEL_SIZE 2048
double leftChannel[CHANNEL_SIZE] ;
double rightChannel[CHANNEL_SIZE] ;
..................................................................
STDMETHODIMP BufferCB( double SampleTime, BYTE * pBuffer, long BufferSize )
{
unsigned int nSampleCount = BufferSize/2 ;
short* pStream = (short *) pBuffer ;
for( i = 0;i<nSampleCount/2 ; i++)
{
leftChannel[i] = ((double)(*pStream)) ;
pStream++ ;
rightChannel[i] = ((double)(*pStream)) ;
pStream++ ;
}
}
2. MULTITHREADING : Can you compare using sample grabber and creating threads for signal processing for performance (especially CPU usage ) ? In my first approach , I created thread for FFT since my FFT task didnt include changing samples , it was just about spectral analysis.
3. DATA FORMATS, CONVERSIONS : I get my each sample as 16 bit. When I looked some DXSDK9 audio samples , they declare "signed" shorts for samples. So I am confused about declaring sample variables as signed , since they can store negative values.
Also I have question marks about getting double or float values from shorts , and replacing shorts with new floats or doubles after making some signal processing. I can understand dividing short values by 32768(2^16 / 2 ). But what about "vice-versa" ?
Thank you very much for reading,
BEST REGARDS,
Akin Ocal
|
|
|
|
|
I added MS ParamEqu filter ( which is a DMO ) into my graph using IDMOWrapper interface.
I want to manipulate parameters of it ( gain,bandwidth,center freq) programatically in my code.
When I searched for this , I found IMediaParams Interface ( http://msdn2.microsoft.com/en-us/library/ms785964(VS.85).aspx)
But I am not sure that it will solve my problem.
If you experienced changing parameters of a DMO fitler programatically , can you give me advices about that ?
For example I didnt understand "envelope" concept. Also sample code for using that interface would be very good.
Best Regards
|
|
|
|
|
Can you do a LoadLibrary in a DLL I seem to be having problems ???
|
|
|
|
|
Yes. But don't try to do so in your DllMain function. See here[^] for details.
Steve
|
|
|
|
|
Still no go
I put the code in the same source but in a function which I exported and imported in my main() .exe
|
|
|
|
|
|
Okay
The function is init_image at the bottom
I call it from my main() exe
This all started when I wanted to see what thread('s) came in on the THREAD_ATTACH so decided to play around with StacKwalk in imagehlp.dll etc.....
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
i = 4;
break;
case DLL_PROCESS_DETACH:
i = 3;
break;
case DLL_THREAD_ATTACH:
threadhndl = 0;
DuplicateHandle( GetCurrentProcess(), // Source Process Handle.
GetCurrentThread(), // Source Handle to dup.
GetCurrentProcess(), // Target Process Handle.
&threadhndl, // Target Handle pointer.
0, // Options flag.
TRUE, // Inheritable flag
DUPLICATE_SAME_ACCESS );// Options
processhndl = 0;
DuplicateHandle( GetCurrentProcess(), // Source Process Handle.
GetCurrentProcess(), // Source Handle to dup.
GetCurrentProcess(), // Target Process Handle.
&processhndl, // Target Handle pointer.
0, // Options flag.
TRUE, // Inheritable flag
DUPLICATE_SAME_ACCESS );// Options
memset( &c, '\0', sizeof c );
c.ContextFlags = CONTEXT_FULL;
GetThreadContext(threadhndl, &c);
s.AddrPC.Offset = c.Eip;
s.AddrPC.Mode = AddrModeFlat;
s.AddrFrame.Offset = c.Ebp;
s.AddrFrame.Mode = AddrModeFlat;
while(1)
pSW(imageType, processhndl, threadhndl, &s, &c, NULL, NULL, NULL, NULL );
// while(1)
// StackWalk(IMAGE_FILE_MACHINE_I386,
// processhndl,
// threadhndl,
// &s,
// &c,NULL,NULL,NULL,NULL);
break;
case DLL_THREAD_DETACH:
i = 2;
break;
return false;
}
return TRUE;
}
__declspec(dllexport) void init_image(void)
{
imageType = IMAGE_FILE_MACHINE_I386;
pSW = NULL;
hImagehlpDll = NULL;
hImagehlpDll = LoadLibrary((LPCWSTR) "imagehlp.dll" );
pSW = (tSW) GetProcAddress( hImagehlpDll, "StackWalk" );
return;
}
Thankx
|
|
|
|
|
Is that an infinite while loop inside your DLL_THREAD_ATTACH case?
|
|
|
|
|
Yes; just wanted to Walk thru the stack
When I load imagehlp.dll in my main exe it works (the LoadLibray) however not in the export'ed function (that lives in
the DLL source)
in order to get all the variables LoadLibrary (handle) and ProcAddress to the DLL I would have to export it thought it
would be simpler to have all the code in the same source as the DLL where In THREAD_ATTACH I would see what thread
attach'ed to the DLL via StackWalk and other imagehlp functions
Thankx again
|
|
|
|
|
Does this fix it?
hImagehlpDll = LoadLibrary((LPCWSTR)L"imagehlp.dll" );
Note the 'L' notation for wide string.
|
|
|
|
|
|
ForNow wrote: hImagehlpDll = NULL;
Is hImagehlpDll a pointer?
ForNow wrote: hImagehlpDll = LoadLibrary((LPCWSTR) "imagehlp.dll" );
Does hImagehlpDll have a non-NULL value? Why the cast? Use L or _T() instead for your string literals.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
ForNow wrote: I seem to be having problems ???
Are we supposed to guess what these problems are?
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Sorry dont know Where that thread came from
I did a LoadLibrary in my main executable for imagehlp and it worked... however what I was hoping to see is in my DLL when I get the thread_attach message is to identify the thread
Some one suggested the use of StackWalk so.....
Orignally I did the LoadLibrary in DLLmain but I was quickly told that was a big no no ... As the OS namely Windows hold locks while processing DLLmain as it is shared code among .exe and DLL and I would cause a deadlock
So.. I put the code for this (the LoadLibrary and GetProc in a exported function in the same source as my DLL
My main .exe imported this function and I called the function in a another DLL that was "implicity loaded" (hope that is right term as opposed to Dynamic Loaded e.g. LoadLibrary) in my main .exe a few lines after my startup code from my main .exe
I think calling a exported function from a DLL which does a LoadLibrary maybe the problem
Dont Know
Thankx again
|
|
|
|
|
Sorry the Value returned from LoadLibrary was NULL
|
|
|
|
|
So why are you then not calling GetLastError() to find out why?
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I got a x7e ERROR_MOD_NOT_FOUND
But thats not it
When I do the load in the main its okay When I call the exported function init_image it fails
int main(int ac,char *av[])
{
int rc = 0;
HINSTANCE hImagehlpDll;
hImagehlpDll = LoadLibrary((LPCWSTR) "imagehlp.dll" ); <--- Okay
init_image();
code in DLL source
__decspec(dllexport) void init_image(void)
{
DWORD myerror;
DWORD DWfLAGS = FORMAT_MESSAGE_FROM_SYSTEM || FORMAT_MESSAGE_ALLOCATE_BUFFER;
DWORD size = 100;
char mybuffer[100];
LPTSTR error_ptr;
imageType = IMAGE_FILE_MACHINE_I386;
pSW = NULL;
hImagehlpDll = NULL;
hImagehlpDll = LoadLibrary((LPCWSTR) "imagehlp.dll" ); <--- fails here
myerror = GetLastError();
// FormatMessage(dwFlags,NULL,myerror,NULL,error_ptr,size,NULL);
pSW = (tSW) GetProcAddress( hImagehlpDll, "StackWalk" );
return;
}
|
|
|
|
|
What does wide L mean ????
|
|
|
|
|
ForNow wrote: What does wide L mean ????
The L is not wide, but the string it precedes is.
Use the L prefix to denote a wide-character character literal or a wide-character string literal.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Thankx Can I buy you lunch one day
Honestly one of the things I noticed with this problem coming from a MainFrame
Background is (using MainFrame Sercvices) When you want to use one of the Authorized
Assembler services IBM always prefaces the discription of the macro by requirements
Such as must be Authorized state or No Locks Held
There is no such documentation on Windows API's
|
|
|
|
|
ForNow wrote: There is no such documentation on Windows API's
Are you referring to MSDN?
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I was refering in MSDN if they are are any requirements when using an API
shuch as no Locks held etc....
I guess I found out they are certin things I cann't do in DLLMain
Thankx again
|
|
|
|
|
A few questions regarding use of the inline key word
1) Do you use it?
2) How do you decide when to use it?
3) Do you ever actually measure the benifit of using it?
4) Can using it ever degrade performance?
5) Can the effect of using it vary on different hardware or operating systems?
|
|
|
|
|
Josh Gray wrote: 1) Do you use it?
Yeah.
Josh Gray wrote: 2) How do you decide when to use it?
When the overhead of a function call is comparable to the overhead of the function itself. For example, a simple accessor function.
Josh Gray wrote:
3) Do you ever actually measure the benifit of using it?
Very rarely.
Josh Gray wrote: 4) Can using it ever degrade performance?
I guess it's possible. If you inlined a frequently called large function you would increase the size of the EXE. Remember that the compiler has the last say however: it doesn't have to inline a function you've marked as inline if it decides it's not worth it.
Steve
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
