Discussion:
Re: 24-bit recording
(too old to reply)
Gordon Gidluck
2003-03-08 23:31:01 UTC
Permalink
Ross,
I picked up a snapshot of the Version 19 code last weekend. I am going
through V19 compile for Windows CE. Since last fall, V18 works fine for me
on any tests I have run; but I wish to move forward with the V19
implementation for 24-bit support.

I am working towards a recording application which will work with
specialized hardware soon to be released by Core Sound.
http://www.core-sound.com/HighResRecorderNews.html
The new hardware will support 24-bit digital I/O on Windows CE, and my
application will use portAudio to support recording to CF memory or internal
disk.

Here are a few notes for anyone working with CE and portAudio in the future:
These notes refer to embedded VC++ 3.0. Some of this is new, and some is a
rehash of issues I mentioned in October.

1) assert() function. I cannot include <assert.h>
There must be a way to do this.
fix: I commented out assert() lines.

2) timeGetTime() problem: not supported in CE.
fix: I used GetTickCount() which from MSDN docs appears to be very
similar.

3) GetEnvironmentVariable() problem: not supported on CE.
fix: In pa_win_wmme.c I return -1 from the GetEnvDefaultDeviceID()
function. I used this approach also for test examples in V18, and it seems
to have worked out ok.

4) StartStream() problem: no SetPriorityClass() function, nor
HIGH_PRIORITY_CLASS constant.
fix: commented out the code which tells of a paUnanticipatedHostError.
Did the same in V18.
Related to this, I will try to use the SetThreadPriority() function where
implemented.

5) You will have no stdout or stdin with CE. There are some possible
workarounds for this. My method is to create an ascii text file (ie. log)
for each module.
=============================

Comments (on V19) specific to pa_win_wmme.c
I am using the wmme code as a template because of CE's similarities to the
WIN32 API.

All of the compile errors generated in pa_win_wmme.c for me are resolved.
All that remain are warnings. I am getting a lot of warnings from EVC++
regarding
incompatible types, for example...

line #344 PA_MME_SET_LAST_WAVEIN_ERROR( mmresult );
'function' : incompatible types - from 'char [128]' to 'unsigned short *'

line #353 winMmeHostApi->allocations, strlen( wic.szPname ) + 1 +
sizeof(constInputMapperSuffix_) );
'function' : incompatible types - from 'unsigned short [32]' to 'const char
*'

Please advise. Should I be concerned about these?
Should I do any type casting or just let them go `as is` because they are
just warnings?
-----------------------
function: InitializeInputDeviceInfo()
function: InitializeOutputDeviceInfo()
Just FYI. these functions both have a unreferenced variable 'i'.
-----------------------
function: ProcessingThreadProc()
line #1665 DWORD timeout = stream->allBuffersDurationMs * 0.5;
conversion from 'double ' to 'unsigned long ', possible loss of data
-----------------------
function: ProcessingThreadProc()
line #1947/1948 Sleep( stream->bufferProcessor.framesPerHostBuffer *
stream->bufferProcessor.samplePeriod * .25 );
conversion from 'double ' to 'unsigned long ', possible loss of data
integral size mismatch in argument; conversion supplied

More to follow regarding pa_testrecord.c on V19.

Gordon Gidluck
www.gidluckmastering.com
Richard Dobson
2003-03-09 05:26:01 UTC
Permalink
These messages are almost certainly to do with Unicode support (Unicode uses
16bit per character). I know nothing about CE - maybe it only supports Unicode,
or you have a hidden #define UNICODE or #define _UNICODE somewhere.

Usually, replacing char types with TCHAR (and #including <tchar.h> )does the job
- this is defined as char or short according to whether UNICODE is defined.
Printf gets chanbged to wprintf (or whatever it is), etc.

Sooner or later, everyone (including me) will have to bite the bullet and
program all text for Unicode; and not only on Windows.


It never occurred to me that WinCE would not supply a console interface, stdio
etc. Something I will want to avoid then! Can you install Linux on those things?


Richard Dobson


Gordon Gidluck wrote:

...
Post by Gordon Gidluck
All of the compile errors generated in pa_win_wmme.c for me are resolved.
All that remain are warnings. I am getting a lot of warnings from EVC++
regarding
incompatible types, for example...
line #344 PA_MME_SET_LAST_WAVEIN_ERROR( mmresult );
'function' : incompatible types - from 'char [128]' to 'unsigned short *'
line #353 winMmeHostApi->allocations, strlen( wic.szPname ) + 1 +
sizeof(constInputMapperSuffix_) );
'function' : incompatible types - from 'unsigned short [32]' to 'const char
*'
Please advise. Should I be concerned about these?
Should I do any type casting or just let them go `as is` because they are
just warnings?
-----------------------
..
Gordon Gidluck
2003-03-09 13:24:01 UTC
Permalink
Thanks to all for the informative feedback I have been getting.
RE: Richard's question. I know the iPAQ's can run Linux, probably others. In
fact, one developer is working on a Linux version of recording software for
Core Sounds interface. There is a picture on the website. On the internet,
you can find information on how to install Linux on these machines.

P.S. Not all Pocket PC's have the stdin/stdout limitation. The H/PC, I think
has support for it.
-gg

----- Original Message -----
From: "Richard Dobson" <***@btconnect.com>
To: <***@music.columbia.edu>
Sent: Sunday, March 09, 2003 4:23 AM
Subject: Re: [Portaudio] Re: 24-bit recording
Post by Richard Dobson
These messages are almost certainly to do with Unicode support (Unicode uses
16bit per character). I know nothing about CE - maybe it only supports Unicode,
or you have a hidden #define UNICODE or #define _UNICODE somewhere.
Usually, replacing char types with TCHAR (and #including <tchar.h> )does the job
- this is defined as char or short according to whether UNICODE is defined.
Printf gets chanbged to wprintf (or whatever it is), etc.
Sooner or later, everyone (including me) will have to bite the bullet and
program all text for Unicode; and not only on Windows.
It never occurred to me that WinCE would not supply a console interface, stdio
etc. Something I will want to avoid then! Can you install Linux on those things?
Richard Dobson
...
Post by Gordon Gidluck
All of the compile errors generated in pa_win_wmme.c for me are resolved.
All that remain are warnings. I am getting a lot of warnings from EVC++
regarding
incompatible types, for example...
line #344 PA_MME_SET_LAST_WAVEIN_ERROR( mmresult );
'function' : incompatible types - from 'char [128]' to 'unsigned short *'
line #353 winMmeHostApi->allocations, strlen( wic.szPname ) + 1 +
sizeof(constInputMapperSuffix_) );
'function' : incompatible types - from 'unsigned short [32]' to 'const char
*'
Please advise. Should I be concerned about these?
Should I do any type casting or just let them go `as is` because they are
just warnings?
-----------------------
..
_______________________________________________
Portaudio mailing list
http://music.columbia.edu/mailman/listinfo/portaudio
Russell Borogove
2003-03-09 13:28:01 UTC
Permalink
[Accidentally sent this directly to Gordon; some
other people might care about some of the info.]
Post by Gordon Gidluck
These notes refer to embedded VC++ 3.0. Some of this is new, and some is a
rehash of issues I mentioned in October.
1) assert() function. I cannot include <assert.h>
There must be a way to do this.
fix: I commented out assert() lines.
If WinCE/EVC++ supplies _ASSERTE or _ASSERT (as does
VC++6/Win32), I recommend you use that.
Post by Gordon Gidluck
2) timeGetTime() problem: not supported in CE.
fix: I used GetTickCount() which from MSDN docs appears to be very
similar.
GetTickCount() and timeGetTime() both nominally report
"milliseconds since some arbitrary timebase", but on
desktop Windows, GetTickCount() is generally less
accurate, updated every 10 or 55 ms depending on the
exact platform. You might want to check the granularity
of GetTickCount() on CE, and look for a solution based
on QueryPerformanceCounter() if GetTickCount() sucks.
Post by Gordon Gidluck
These messages are almost certainly to do with Unicode
support (Unicode uses 16bit per character). I know
nothing about CE - maybe it only supports Unicode,
or you have a hidden #define UNICODE or #define
_UNICODE somewhere.
I'm guessing the CE OS functions are all requiring Unicode/
wide-char text, though it's been a while since I touched
CE[1]. Win32 provides both ANSI and Unicode interfaces for
most functions, and that doubling-up accounts for a non-
negligible portion of the OS bloat; small wonder if they
ripped it out of a small-footprint version of the OS.

As Richard says, the TCHAR type will solve most of that,
but you'll have to give some thought as to where the text
data is coming from and where it's going, to ensure that
it's the right width when it gets there.

-RB

[1] Besides, that was on the most non-standard instance
of CE that ever existed. (Hint: most implementations of
WinCE provide a GDI but not a DirectX graphic interface;
this one had DirectX but no GDI).
Russell Borogove
2003-03-09 16:10:01 UTC
Permalink
Thanks Russell for the responses. All of this is very helpful.
I think _ASSERT only works for MFC applications. I did not mention it, but
my program does not use MFC classes. _ASSERTE is not in the CE API. I was
hoping to try to use the ANSI assert() function.
_ASSERT doesn't require MFC, but I wouldn't be surprised
if it's not in CE. Under MSVC it's declared in <crtdbg.h>

-R
Ross Bencina
2003-03-09 23:42:02 UTC
Permalink
Post by Russell Borogove
Thanks Russell for the responses. All of this is very helpful.
I think _ASSERT only works for MFC applications. I did not mention it, but
my program does not use MFC classes. _ASSERTE is not in the CE API. I was
hoping to try to use the ANSI assert() function.
_ASSERT doesn't require MFC, but I wouldn't be surprised
if it's not in CE. Under MSVC it's declared in <crtdbg.h>
One problem with using _ASSERT is that we're using assert() in the common
(portable) code - using _ASSERT there just doesn't make sense at all.

Ross.
Russell Borogove
2003-03-09 23:54:02 UTC
Permalink
Post by Ross Bencina
Post by Russell Borogove
_ASSERT doesn't require MFC, but I wouldn't be surprised
if it's not in CE. Under MSVC it's declared in <crtdbg.h>
One problem with using _ASSERT is that we're using assert() in the common
(portable) code - using _ASSERT there just doesn't make sense at all.
I thought the context of the discussion was getting it
to work on CE without regard to back-portability; if
not, then yes, _ASSERT isn't useful. :)

-R
Ross Bencina
2003-03-10 00:14:01 UTC
Permalink
Post by Gordon Gidluck
Ross,
I picked up a snapshot of the Version 19 code last weekend. I am going
through V19 compile for Windows CE. Since last fall, V18 works fine for me
on any tests I have run; but I wish to move forward with the V19
implementation for 24-bit support.
Hi Gordon

There are a couple of critical fixmes in
pa_win_wmme.c:CalculateBufferSettings() (buffer sizes are hardwired at lines
733 and 764) - I'll make them my first priority and check something into CVS
in the next day or two.

I'm not sure how you want to proceed with the CE patches - my preference
would be to work to minimise the number of changes necessary between the
Win32 and WinCE versions, and then add appropriate #ifdefs to the Win32
sources. Are you already happy that the changes you have listed are all
that's needed to get pa_win_wmme.c working with WinCE? What precompiler
symbol is available on WinCE to differentiate from Win32?
Post by Gordon Gidluck
These notes refer to embedded VC++ 3.0. Some of this is new, and some is a
rehash of issues I mentioned in October.
1) assert() function. I cannot include <assert.h>
There must be a way to do this.
fix: I commented out assert() lines.
I don't know enough about wince to know why assert isn't there. Perhaps you
can make a replacement out of ASSERT:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceoem/htm/
_wcepb_assert.asp
Post by Gordon Gidluck
2) timeGetTime() problem: not supported in CE.
fix: I used GetTickCount() which from MSDN docs appears to be very
similar.
I would recommend using something with higher precision that GetTickCount()
if you can - this will only be critical if you are making use of buffer
timestamps though.
Post by Gordon Gidluck
3) GetEnvironmentVariable() problem: not supported on CE.
fix: In pa_win_wmme.c I return -1 from the GetEnvDefaultDeviceID()
function. I used this approach also for test examples in V18, and it seems
to have worked out ok.
Sounds reasonable to me.
Post by Gordon Gidluck
4) StartStream() problem: no SetPriorityClass() function, nor
HIGH_PRIORITY_CLASS constant.
fix: commented out the code which tells of a paUnanticipatedHostError.
Did the same in V18.
Related to this, I will try to use the SetThreadPriority() function where
implemented.
I think we should probably review whether SetPriorityClass() should be
called by default anyway. At the moment it can be disabled using the
PaWinMmeNoHighPriorityProcessClass host API specific flag.
Post by Gordon Gidluck
5) You will have no stdout or stdin with CE. There are some possible
workarounds for this. My method is to create an ascii text file (ie. log)
for each module.
Sounds reasonable, although I'm wondering where you needed to use
stdin/stdout? was it just for running the tests?
Post by Gordon Gidluck
=============================
Comments (on V19) specific to pa_win_wmme.c
I am using the wmme code as a template because of CE's similarities to the
WIN32 API.
All of the compile errors generated in pa_win_wmme.c for me are resolved.
All that remain are warnings. I am getting a lot of warnings from EVC++
regarding
incompatible types, for example...
line #344 PA_MME_SET_LAST_WAVEIN_ERROR( mmresult );
'function' : incompatible types - from 'char [128]' to 'unsigned short *'
line #353 winMmeHostApi->allocations, strlen( wic.szPname ) + 1 +
sizeof(constInputMapperSuffix_) );
'function' : incompatible types - from 'unsigned short [32]' to 'const char
*'
Please advise. Should I be concerned about these?
Should I do any type casting or just let them go `as is` because they are
just warnings?
As Richard noted, this looks like a unicode issue - I would be concerned,
unless you have the option of not compiling with unicode support, in which
case we can leave it until someone needs it and update the code then - it
does raise questions about how PortAudio will support unicode in the future
though.
Post by Gordon Gidluck
-----------------------
function: InitializeInputDeviceInfo()
function: InitializeOutputDeviceInfo()
Just FYI. these functions both have a unreferenced variable 'i'.
i is actually used in some code that is ifdefed out, on line 445:
/* If channel max is goofy, then query for max channels. PLB20020228
* This doesn't seem to help. Disable code for now. Remove it later.
*/
Phil - can this code go?
Post by Gordon Gidluck
-----------------------
function: ProcessingThreadProc()
line #1665 DWORD timeout = stream->allBuffersDurationMs * 0.5;
conversion from 'double ' to 'unsigned long ', possible loss of data
-----------------------
function: ProcessingThreadProc()
line #1947/1948 Sleep( stream->bufferProcessor.framesPerHostBuffer *
stream->bufferProcessor.samplePeriod * .25 );
conversion from 'double ' to 'unsigned long ', possible loss of data
integral size mismatch in argument; conversion supplied
Thanks, I've made a note of these, but I want to inspect the code further
before fixing them.

Best wishes,

Ross.
Gordon Gidluck
2003-03-10 09:26:02 UTC
Permalink
Ross,
Thanks for looking into this. Responses are embedded.
Post by Ross Bencina
There are a couple of critical fixmes in
pa_win_wmme.c:CalculateBufferSettings() (buffer sizes are hardwired at lines
733 and 764) - I'll make them my first priority and check something into CVS
in the next day or two.
Thanks.
Post by Ross Bencina
I'm not sure how you want to proceed with the CE patches - my preference
would be to work to minimise the number of changes necessary between the
Win32 and WinCE versions, and then add appropriate #ifdefs to the Win32
sources. Are you already happy that the changes you have listed are all
that's needed to get pa_win_wmme.c working with WinCE? What precompiler
symbol is available on WinCE to differentiate from Win32?
#ifdef WIN32_PLATFORM_PSPC
This will work for the Pocket PC.

RE: to get pa_win_wmme.c working?
Yes, I think I have now identified the major issues involved.
Post by Ross Bencina
Post by Gordon Gidluck
Here are a few notes for anyone working with CE and portAudio in the
These notes refer to embedded VC++ 3.0. Some of this is new, and some is a
rehash of issues I mentioned in October.
1) assert() function. I cannot include <assert.h>
There must be a way to do this.
fix: I commented out assert() lines.
I don't know enough about wince to know why assert isn't there. Perhaps you
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceoem/htm/
_wcepb_assert.asp
I will look more into this. (FYI) There seems to be some attempt to remove
assertion code out of the final releases. I will try to implement the ANSI
code as is or make the implementation work with a minimum amount of coding
effort. Defining _DEBUG at a certain time allows use of an ASSERT macro. I
will use it as a last resort.
Post by Ross Bencina
Post by Gordon Gidluck
2) timeGetTime() problem: not supported in CE.
fix: I used GetTickCount() which from MSDN docs appears to be very
similar.
I would recommend using something with higher precision that
GetTickCount()
Post by Ross Bencina
if you can - this will only be critical if you are making use of buffer
timestamps though.
Ok.
Post by Ross Bencina
Post by Gordon Gidluck
3) GetEnvironmentVariable() problem: not supported on CE.
fix: In pa_win_wmme.c I return -1 from the GetEnvDefaultDeviceID()
function. I used this approach also for test examples in V18, and it seems
to have worked out ok.
Sounds reasonable to me.
Maybe I could wrap the WIN32_PLATFORM_PSPC define around anything like this.
Post by Ross Bencina
Post by Gordon Gidluck
4) StartStream() problem: no SetPriorityClass() function, nor
HIGH_PRIORITY_CLASS constant.
fix: commented out the code which tells of a
paUnanticipatedHostError.
Post by Ross Bencina
Post by Gordon Gidluck
Did the same in V18.
Related to this, I will try to use the SetThreadPriority() function
where
Post by Gordon Gidluck
implemented.
I think we should probably review whether SetPriorityClass() should be
called by default anyway. At the moment it can be disabled using the
PaWinMmeNoHighPriorityProcessClass host API specific flag.
I will do that.
Post by Ross Bencina
Post by Gordon Gidluck
5) You will have no stdout or stdin with CE. There are some possible
workarounds for this. My method is to create an ascii text file (ie. log)
for each module.
Sounds reasonable, although I'm wondering where you needed to use
stdin/stdout? was it just for running the tests?
Yes. Really I just insert code into modules where I need to figure out
what's happening. Like for instance, why the initialization code is not
happening. A slower way to work though, but it works.
Post by Ross Bencina
Post by Gordon Gidluck
=============================
Comments (on V19) specific to pa_win_wmme.c
I am using the wmme code as a template because of CE's similarities to the
WIN32 API.
All of the compile errors generated in pa_win_wmme.c for me are resolved.
All that remain are warnings. I am getting a lot of warnings from EVC++
regarding
incompatible types, for example...
line #344 PA_MME_SET_LAST_WAVEIN_ERROR( mmresult );
'function' : incompatible types - from 'char [128]' to 'unsigned short *'
line #353 winMmeHostApi->allocations, strlen( wic.szPname ) + 1 +
sizeof(constInputMapperSuffix_) );
'function' : incompatible types - from 'unsigned short [32]' to 'const
char
Post by Gordon Gidluck
*'
Please advise. Should I be concerned about these?
Should I do any type casting or just let them go `as is` because they are
just warnings?
As Richard noted, this looks like a unicode issue - I would be concerned,
unless you have the option of not compiling with unicode support, in which
case we can leave it until someone needs it and update the code then - it
does raise questions about how PortAudio will support unicode in the future
though.
I was able to make V18 work for the patest_recording code without dealing
with the unicode issue in depth. For other reasons I need to keep UNICODE
defined. I think it also would be smart to have future support for UNICODE
in portaudio, but this is perhaps too big of an issue at this time.
Post by Ross Bencina
Post by Gordon Gidluck
-----------------------
function: InitializeInputDeviceInfo()
function: InitializeOutputDeviceInfo()
Just FYI. these functions both have a unreferenced variable 'i'.
/* If channel max is goofy, then query for max channels. PLB20020228
* This doesn't seem to help. Disable code for now. Remove it later.
*/
Phil - can this code go?
Post by Gordon Gidluck
-----------------------
function: ProcessingThreadProc()
line #1665 DWORD timeout = stream->allBuffersDurationMs * 0.5;
conversion from 'double ' to 'unsigned long ', possible loss of data
-----------------------
function: ProcessingThreadProc()
line #1947/1948 Sleep( stream->bufferProcessor.framesPerHostBuffer *
stream->bufferProcessor.samplePeriod * .25 );
conversion from 'double ' to 'unsigned long ', possible loss of data
integral size mismatch in argument; conversion supplied
Thanks, I've made a note of these, but I want to inspect the code further
before fixing them.
Best wishes,
Ross.
Thanks again. I am having some runtime issue in the Pa_Initialization()
section. Could it have to do with the broken code? Error number -9999.
Unanticipated host error.

Gordon
Ross Bencina
2003-03-11 02:29:01 UTC
Permalink
Hi Gordon
Post by Gordon Gidluck
#ifdef WIN32_PLATFORM_PSPC
This will work for the Pocket PC.
RE: to get pa_win_wmme.c working?
Yes, I think I have now identified the major issues involved.
Post by Ross Bencina
Post by Gordon Gidluck
3) GetEnvironmentVariable() problem: not supported on CE.
fix: In pa_win_wmme.c I return -1 from the GetEnvDefaultDeviceID()
function. I used this approach also for test examples in V18, and it
seems
Post by Ross Bencina
Post by Gordon Gidluck
to have worked out ok.
Sounds reasonable to me.
Maybe I could wrap the WIN32_PLATFORM_PSPC define around anything like this.
That's probably the best approach at this stage - I'm happy to merge your
changes into the CVS version so long as they are isolated with ifdefs like
this. Sounds like it's safe to go ahead and do this now, so I will based on
your previous email.
Post by Gordon Gidluck
I was able to make V18 work for the patest_recording code without dealing
with the unicode issue in depth. For other reasons I need to keep UNICODE
defined. I think it also would be smart to have future support for UNICODE
in portaudio, but this is perhaps too big of an issue at this time.
I think full suport for UNICODE in V19 is not going to happen unless someone
who is knowledgable about UNICODE wants to step up and offer advice. My
suggestion for now would be to maintain the single-byte character interface
for the PortAudio API, and convert any multi-byte strings to single byte
before assigning them (in the code which you have identified for example.)
Post by Gordon Gidluck
Thanks again. I am having some runtime issue in the Pa_Initialization()
section. Could it have to do with the broken code? Error number -9999.
Unanticipated host error.
There's nothing that I know of, you will need to trace the error I think.
Are you able to run a source-level debugger from a remote machine?

Best wishes,

Ross.
Gordon Gidluck
2003-03-15 16:06:01 UTC
Permalink
Ross and portaudio list,
Windows CE and V19 of portaudio. Having an initialization problem. I
followed it through to the InitializeInputDeviceInfo() function. This code
is quite a bit different from the V18 implementation, which works for me,
but this section is giving me some problem in the initialization. V18 will
record and play a sine wave for me on an iPAQ 3635.

When the API function waveInGetCaps() is called, I am getting an error here.
A value of 6 is being returned. FYI, when waveInGetCaps is called
deviceIndex is 0 and inputWinMmeId is -1 (WAVE_MAPPER). Should deviceIndex
not be an integer > 0? Any ideas? Comments?

Also, I'm note real sure about PaUtilHostApiInitializer in
pa_win_hostapis.c. Should I be commenting out the reference to
Pa_skeleton_Initialize? Is this just for testing?

Thanks!

Gordon

----- Original Message -----
From: "Gordon Gidluck" <***@alltel.net>
To: "Ross Bencina" <***@iprimus.com.au>; "Portaudio List"
<***@music.columbia.edu>
Sent: Monday, March 10, 2003 8:24 AM
Subject: Re: [Portaudio] Re: 24-bit recording
Post by Gordon Gidluck
Ross,
Thanks for looking into this. Responses are embedded.
Post by Ross Bencina
There are a couple of critical fixmes in
pa_win_wmme.c:CalculateBufferSettings() (buffer sizes are hardwired at
lines
Post by Ross Bencina
733 and 764) - I'll make them my first priority and check something into
CVS
Post by Ross Bencina
in the next day or two.
Thanks.
Post by Ross Bencina
I'm not sure how you want to proceed with the CE patches - my preference
would be to work to minimise the number of changes necessary between the
Win32 and WinCE versions, and then add appropriate #ifdefs to the Win32
sources. Are you already happy that the changes you have listed are all
that's needed to get pa_win_wmme.c working with WinCE? What precompiler
symbol is available on WinCE to differentiate from Win32?
#ifdef WIN32_PLATFORM_PSPC
This will work for the Pocket PC.
RE: to get pa_win_wmme.c working?
Yes, I think I have now identified the major issues involved.
Post by Ross Bencina
Post by Gordon Gidluck
Here are a few notes for anyone working with CE and portAudio in the
These notes refer to embedded VC++ 3.0. Some of this is new, and some
is
Post by Gordon Gidluck
a
Post by Ross Bencina
Post by Gordon Gidluck
rehash of issues I mentioned in October.
1) assert() function. I cannot include <assert.h>
There must be a way to do this.
fix: I commented out assert() lines.
I don't know enough about wince to know why assert isn't there. Perhaps
you
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceoem/htm/
Post by Gordon Gidluck
_wcepb_assert.asp
I will look more into this. (FYI) There seems to be some attempt to remove
assertion code out of the final releases. I will try to implement the ANSI
code as is or make the implementation work with a minimum amount of coding
effort. Defining _DEBUG at a certain time allows use of an ASSERT macro. I
will use it as a last resort.
Post by Ross Bencina
Post by Gordon Gidluck
2) timeGetTime() problem: not supported in CE.
fix: I used GetTickCount() which from MSDN docs appears to be very
similar.
I would recommend using something with higher precision that
GetTickCount()
Post by Ross Bencina
if you can - this will only be critical if you are making use of buffer
timestamps though.
Ok.
Post by Ross Bencina
Post by Gordon Gidluck
3) GetEnvironmentVariable() problem: not supported on CE.
fix: In pa_win_wmme.c I return -1 from the GetEnvDefaultDeviceID()
function. I used this approach also for test examples in V18, and it
seems
Post by Ross Bencina
Post by Gordon Gidluck
to have worked out ok.
Sounds reasonable to me.
Maybe I could wrap the WIN32_PLATFORM_PSPC define around anything like
this.
Post by Gordon Gidluck
Post by Ross Bencina
Post by Gordon Gidluck
4) StartStream() problem: no SetPriorityClass() function, nor
HIGH_PRIORITY_CLASS constant.
fix: commented out the code which tells of a
paUnanticipatedHostError.
Post by Ross Bencina
Post by Gordon Gidluck
Did the same in V18.
Related to this, I will try to use the SetThreadPriority() function
where
Post by Gordon Gidluck
implemented.
I think we should probably review whether SetPriorityClass() should be
called by default anyway. At the moment it can be disabled using the
PaWinMmeNoHighPriorityProcessClass host API specific flag.
I will do that.
Post by Ross Bencina
Post by Gordon Gidluck
5) You will have no stdout or stdin with CE. There are some possible
workarounds for this. My method is to create an ascii text file (ie.
log)
Post by Ross Bencina
Post by Gordon Gidluck
for each module.
Sounds reasonable, although I'm wondering where you needed to use
stdin/stdout? was it just for running the tests?
Yes. Really I just insert code into modules where I need to figure out
what's happening. Like for instance, why the initialization code is not
happening. A slower way to work though, but it works.
Post by Ross Bencina
Post by Gordon Gidluck
=============================
Comments (on V19) specific to pa_win_wmme.c
I am using the wmme code as a template because of CE's similarities to
the
Post by Ross Bencina
Post by Gordon Gidluck
WIN32 API.
All of the compile errors generated in pa_win_wmme.c for me are
resolved.
Post by Ross Bencina
Post by Gordon Gidluck
All that remain are warnings. I am getting a lot of warnings from
EVC++
Post by Gordon Gidluck
Post by Ross Bencina
Post by Gordon Gidluck
regarding
incompatible types, for example...
line #344 PA_MME_SET_LAST_WAVEIN_ERROR( mmresult );
'function' : incompatible types - from 'char [128]' to 'unsigned short
*'
Post by Ross Bencina
Post by Gordon Gidluck
line #353 winMmeHostApi->allocations, strlen( wic.szPname ) + 1 +
sizeof(constInputMapperSuffix_) );
'function' : incompatible types - from 'unsigned short [32]' to 'const
char
Post by Gordon Gidluck
*'
Please advise. Should I be concerned about these?
Should I do any type casting or just let them go `as is` because they
are
Post by Ross Bencina
Post by Gordon Gidluck
just warnings?
As Richard noted, this looks like a unicode issue - I would be
concerned,
Post by Gordon Gidluck
Post by Ross Bencina
unless you have the option of not compiling with unicode support, in
which
Post by Gordon Gidluck
Post by Ross Bencina
case we can leave it until someone needs it and update the code then -
it
Post by Gordon Gidluck
Post by Ross Bencina
does raise questions about how PortAudio will support unicode in the
future
Post by Ross Bencina
though.
I was able to make V18 work for the patest_recording code without dealing
with the unicode issue in depth. For other reasons I need to keep UNICODE
defined. I think it also would be smart to have future support for UNICODE
in portaudio, but this is perhaps too big of an issue at this time.
Post by Ross Bencina
Post by Gordon Gidluck
-----------------------
function: InitializeInputDeviceInfo()
function: InitializeOutputDeviceInfo()
Just FYI. these functions both have a unreferenced variable 'i'.
/* If channel max is goofy, then query for max channels. PLB20020228
* This doesn't seem to help. Disable code for now. Remove it
later.
Post by Ross Bencina
*/
Phil - can this code go?
Post by Gordon Gidluck
-----------------------
function: ProcessingThreadProc()
line #1665 DWORD timeout = stream->allBuffersDurationMs * 0.5;
conversion from 'double ' to 'unsigned long ', possible loss of data
-----------------------
function: ProcessingThreadProc()
line #1947/1948 Sleep( stream->bufferProcessor.framesPerHostBuffer *
stream->bufferProcessor.samplePeriod * .25 );
conversion from 'double ' to 'unsigned long ', possible loss of data
integral size mismatch in argument; conversion supplied
Thanks, I've made a note of these, but I want to inspect the code
further
Post by Gordon Gidluck
Post by Ross Bencina
before fixing them.
Best wishes,
Ross.
Thanks again. I am having some runtime issue in the Pa_Initialization()
section. Could it have to do with the broken code? Error number -9999.
Unanticipated host error.
Gordon
Ross Bencina
2003-03-17 15:49:02 UTC
Permalink
Hi Gordon
Post by Gordon Gidluck
Ross and portaudio list,
Windows CE and V19 of portaudio. Having an initialization problem. I
followed it through to the InitializeInputDeviceInfo() function. This code
is quite a bit different from the V18 implementation, which works for me,
but this section is giving me some problem in the initialization. V18 will
record and play a sine wave for me on an iPAQ 3635.
When the API function waveInGetCaps() is called, I am getting an error here.
A value of 6 is being returned. FYI, when waveInGetCaps is called
deviceIndex is 0 and inputWinMmeId is -1 (WAVE_MAPPER). Should deviceIndex
not be an integer > 0? Any ideas? Comments?
The deviceIndex is an integer >= 0, but inputWinMmeId can be WAVE_MAPPER
(-1). PortAudio automatically adds the WAVE_MAPPER to the device list for
input and/or output when the device count is > 0. In mmsystem.h, error 6 is
MMSYSERR_NODRIVER, which I presume means that Windows CE doesn't provide a
wave mapper.

The V18 code doesn't try to call waveInGetDevCaps until you call
Pa_GetDeviceInfo, so in V18 only a call to Pa_GetDeviceInfo for device 0
will fail, whereas in the existing version of V19, Pa_Initialize pre-loads
all device info structures, calling waveInGetDevCaps, which is failing when
trying to retrieve information about the wavemapper.

I've just checked a patch to pa_win_wmme.c into CVS which should fix this
problem - PortAudio still scans for the wavemappers, but just skips devices
that return an error from waveInGetDevCaps (and waveOutGetDevCaps) rather
than totally halting the initialization process. Let me know if this fixes
your problem.

I've also #ifdeffed out code for GetEnvironmentVariable and
SetPriorityClass with WIN32_PLATFORM_PSPC as per your previous email.
Post by Gordon Gidluck
Also, I'm note real sure about PaUtilHostApiInitializer in
pa_win_hostapis.c. Should I be commenting out the reference to
Pa_skeleton_Initialize? Is this just for testing?
Pa_skeleton is a starting point for new implementations, it's included in
PaUtilHostApiInitializer for testing, you can safely remove it.

btw. I've had a quick look at the unicode situation. I think the best thing
to do for the moment is to retain char* in the PortAudio API and internally
convert the w_char* returned by the API functions into char*. I've started
to do this in pa_win_mme.c, but I don't actually understand unicode well
enough to know what the best approach to converting unicode to ASCII char*s
is - does anyone else?

Best wishes

Ross.
Post by Gordon Gidluck
Thanks!
Gordon
----- Original Message -----
Sent: Monday, March 10, 2003 8:24 AM
Subject: Re: [Portaudio] Re: 24-bit recording
Post by Gordon Gidluck
Ross,
Thanks for looking into this. Responses are embedded.
Post by Ross Bencina
There are a couple of critical fixmes in
pa_win_wmme.c:CalculateBufferSettings() (buffer sizes are hardwired at
lines
Post by Ross Bencina
733 and 764) - I'll make them my first priority and check something into
CVS
Post by Ross Bencina
in the next day or two.
Thanks.
Post by Ross Bencina
I'm not sure how you want to proceed with the CE patches - my preference
would be to work to minimise the number of changes necessary between the
Win32 and WinCE versions, and then add appropriate #ifdefs to the Win32
sources. Are you already happy that the changes you have listed are all
that's needed to get pa_win_wmme.c working with WinCE? What precompiler
symbol is available on WinCE to differentiate from Win32?
#ifdef WIN32_PLATFORM_PSPC
This will work for the Pocket PC.
RE: to get pa_win_wmme.c working?
Yes, I think I have now identified the major issues involved.
Post by Ross Bencina
Post by Gordon Gidluck
Here are a few notes for anyone working with CE and portAudio in the
These notes refer to embedded VC++ 3.0. Some of this is new, and some
is
Post by Gordon Gidluck
a
Post by Ross Bencina
Post by Gordon Gidluck
rehash of issues I mentioned in October.
1) assert() function. I cannot include <assert.h>
There must be a way to do this.
fix: I commented out assert() lines.
I don't know enough about wince to know why assert isn't there. Perhaps
you
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceoem/htm/
Post by Gordon Gidluck
Post by Gordon Gidluck
_wcepb_assert.asp
I will look more into this. (FYI) There seems to be some attempt to remove
assertion code out of the final releases. I will try to implement the ANSI
code as is or make the implementation work with a minimum amount of coding
effort. Defining _DEBUG at a certain time allows use of an ASSERT macro. I
will use it as a last resort.
Post by Ross Bencina
Post by Gordon Gidluck
2) timeGetTime() problem: not supported in CE.
fix: I used GetTickCount() which from MSDN docs appears to be very
similar.
I would recommend using something with higher precision that
GetTickCount()
Post by Ross Bencina
if you can - this will only be critical if you are making use of buffer
timestamps though.
Ok.
Post by Ross Bencina
Post by Gordon Gidluck
3) GetEnvironmentVariable() problem: not supported on CE.
fix: In pa_win_wmme.c I return -1 from the
GetEnvDefaultDeviceID()
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
Post by Gordon Gidluck
function. I used this approach also for test examples in V18, and it
seems
Post by Ross Bencina
Post by Gordon Gidluck
to have worked out ok.
Sounds reasonable to me.
Maybe I could wrap the WIN32_PLATFORM_PSPC define around anything like
this.
Post by Gordon Gidluck
Post by Ross Bencina
Post by Gordon Gidluck
4) StartStream() problem: no SetPriorityClass() function, nor
HIGH_PRIORITY_CLASS constant.
fix: commented out the code which tells of a
paUnanticipatedHostError.
Post by Ross Bencina
Post by Gordon Gidluck
Did the same in V18.
Related to this, I will try to use the SetThreadPriority() function
where
Post by Gordon Gidluck
implemented.
I think we should probably review whether SetPriorityClass() should be
called by default anyway. At the moment it can be disabled using the
PaWinMmeNoHighPriorityProcessClass host API specific flag.
I will do that.
Post by Ross Bencina
Post by Gordon Gidluck
5) You will have no stdout or stdin with CE. There are some possible
workarounds for this. My method is to create an ascii text file (ie.
log)
Post by Ross Bencina
Post by Gordon Gidluck
for each module.
Sounds reasonable, although I'm wondering where you needed to use
stdin/stdout? was it just for running the tests?
Yes. Really I just insert code into modules where I need to figure out
what's happening. Like for instance, why the initialization code is not
happening. A slower way to work though, but it works.
Post by Ross Bencina
Post by Gordon Gidluck
=============================
Comments (on V19) specific to pa_win_wmme.c
I am using the wmme code as a template because of CE's similarities to
the
Post by Ross Bencina
Post by Gordon Gidluck
WIN32 API.
All of the compile errors generated in pa_win_wmme.c for me are
resolved.
Post by Ross Bencina
Post by Gordon Gidluck
All that remain are warnings. I am getting a lot of warnings from
EVC++
Post by Gordon Gidluck
Post by Ross Bencina
Post by Gordon Gidluck
regarding
incompatible types, for example...
line #344 PA_MME_SET_LAST_WAVEIN_ERROR( mmresult );
'function' : incompatible types - from 'char [128]' to 'unsigned short
*'
Post by Ross Bencina
Post by Gordon Gidluck
line #353 winMmeHostApi->allocations, strlen( wic.szPname ) + 1 +
sizeof(constInputMapperSuffix_) );
'function' : incompatible types - from 'unsigned short [32]' to 'const
char
Post by Gordon Gidluck
*'
Please advise. Should I be concerned about these?
Should I do any type casting or just let them go `as is` because they
are
Post by Ross Bencina
Post by Gordon Gidluck
just warnings?
As Richard noted, this looks like a unicode issue - I would be
concerned,
Post by Gordon Gidluck
Post by Ross Bencina
unless you have the option of not compiling with unicode support, in
which
Post by Gordon Gidluck
Post by Ross Bencina
case we can leave it until someone needs it and update the code then -
it
Post by Gordon Gidluck
Post by Ross Bencina
does raise questions about how PortAudio will support unicode in the
future
Post by Ross Bencina
though.
I was able to make V18 work for the patest_recording code without dealing
with the unicode issue in depth. For other reasons I need to keep UNICODE
defined. I think it also would be smart to have future support for UNICODE
in portaudio, but this is perhaps too big of an issue at this time.
Post by Ross Bencina
Post by Gordon Gidluck
-----------------------
function: InitializeInputDeviceInfo()
function: InitializeOutputDeviceInfo()
Just FYI. these functions both have a unreferenced variable 'i'.
/* If channel max is goofy, then query for max channels. PLB20020228
* This doesn't seem to help. Disable code for now. Remove it
later.
Post by Ross Bencina
*/
Phil - can this code go?
Post by Gordon Gidluck
-----------------------
function: ProcessingThreadProc()
line #1665 DWORD timeout = stream->allBuffersDurationMs * 0.5;
conversion from 'double ' to 'unsigned long ', possible loss of data
-----------------------
function: ProcessingThreadProc()
line #1947/1948 Sleep( stream->bufferProcessor.framesPerHostBuffer *
stream->bufferProcessor.samplePeriod * .25 );
conversion from 'double ' to 'unsigned long ', possible loss of data
integral size mismatch in argument; conversion supplied
Thanks, I've made a note of these, but I want to inspect the code
further
Post by Gordon Gidluck
Post by Ross Bencina
before fixing them.
Best wishes,
Ross.
Thanks again. I am having some runtime issue in the Pa_Initialization()
section. Could it have to do with the broken code? Error number -9999.
Unanticipated host error.
Gordon
Gordon Gidluck
2003-03-16 17:07:02 UTC
Permalink
Think I found the source of some of my woes here. I am using patest_record.c
from the V19 development. The function Pa_OpenStream in pa_front.c (I am
using) only has 8 parameters whereas the call in patest_record.c has 16.

It would appear that the pa_front.c code is older (v 1.1.2.36) whereas the
other is (v 1.2.2.2). Is there a newer version of pa_front.c available?

I downloaded my initial snapshot from the file pa_snapshot_v19.tar.gz. I
guess that what may have happened is that as I was trying to find functions
to compile the source with, I may have included older versions if I did not
find a new source in the download.

How do I proceed? Should I only be using sources which say (v 1.2.xx.xx)? If
some code is not already written should I fallback to V18 until later? I was
hoping to move ahead with V19, as it is way more advanced. Importantly, am I
overlooking something obvious here?

Gordon Gidluck
www.gidluckmastering.com

----- Original Message -----
From: "Gordon Gidluck" <***@alltel.net>
To: "Ross Bencina" <***@iprimus.com.au>; "Portaudio List"
<***@music.columbia.edu>
Sent: Saturday, March 15, 2003 3:04 PM
Subject: Re: [Portaudio] Re: 24-bit recording
Post by Gordon Gidluck
Ross and portaudio list,
Windows CE and V19 of portaudio. Having an initialization problem. I
followed it through to the InitializeInputDeviceInfo() function. This code
is quite a bit different from the V18 implementation, which works for me,
but this section is giving me some problem in the initialization. V18 will
record and play a sine wave for me on an iPAQ 3635.
When the API function waveInGetCaps() is called, I am getting an error
here.
Post by Gordon Gidluck
A value of 6 is being returned. FYI, when waveInGetCaps is called
deviceIndex is 0 and inputWinMmeId is -1 (WAVE_MAPPER). Should deviceIndex
not be an integer > 0? Any ideas? Comments?
Also, I'm note real sure about PaUtilHostApiInitializer in
pa_win_hostapis.c. Should I be commenting out the reference to
Pa_skeleton_Initialize? Is this just for testing?
Thanks!
Gordon
----- Original Message -----
Sent: Monday, March 10, 2003 8:24 AM
Subject: Re: [Portaudio] Re: 24-bit recording
Post by Gordon Gidluck
Ross,
Thanks for looking into this. Responses are embedded.
Post by Ross Bencina
There are a couple of critical fixmes in
pa_win_wmme.c:CalculateBufferSettings() (buffer sizes are hardwired at
lines
Post by Ross Bencina
733 and 764) - I'll make them my first priority and check something
into
Post by Gordon Gidluck
Post by Gordon Gidluck
CVS
Post by Ross Bencina
in the next day or two.
Thanks.
Post by Ross Bencina
I'm not sure how you want to proceed with the CE patches - my
preference
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
would be to work to minimise the number of changes necessary between
the
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
Win32 and WinCE versions, and then add appropriate #ifdefs to the
Win32
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
sources. Are you already happy that the changes you have listed are
all
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
that's needed to get pa_win_wmme.c working with WinCE? What
precompiler
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
symbol is available on WinCE to differentiate from Win32?
#ifdef WIN32_PLATFORM_PSPC
This will work for the Pocket PC.
RE: to get pa_win_wmme.c working?
Yes, I think I have now identified the major issues involved.
Post by Ross Bencina
Post by Gordon Gidluck
Here are a few notes for anyone working with CE and portAudio in the
These notes refer to embedded VC++ 3.0. Some of this is new, and
some
Post by Gordon Gidluck
is
Post by Gordon Gidluck
a
Post by Ross Bencina
Post by Gordon Gidluck
rehash of issues I mentioned in October.
1) assert() function. I cannot include <assert.h>
There must be a way to do this.
fix: I commented out assert() lines.
I don't know enough about wince to know why assert isn't there.
Perhaps
Post by Gordon Gidluck
Post by Gordon Gidluck
you
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceoem/htm/
Post by Gordon Gidluck
Post by Gordon Gidluck
_wcepb_assert.asp
I will look more into this. (FYI) There seems to be some attempt to
remove
Post by Gordon Gidluck
Post by Gordon Gidluck
assertion code out of the final releases. I will try to implement the
ANSI
Post by Gordon Gidluck
Post by Gordon Gidluck
code as is or make the implementation work with a minimum amount of
coding
Post by Gordon Gidluck
Post by Gordon Gidluck
effort. Defining _DEBUG at a certain time allows use of an ASSERT macro.
I
Post by Gordon Gidluck
Post by Gordon Gidluck
will use it as a last resort.
Post by Ross Bencina
Post by Gordon Gidluck
2) timeGetTime() problem: not supported in CE.
fix: I used GetTickCount() which from MSDN docs appears to be
very
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
Post by Gordon Gidluck
similar.
I would recommend using something with higher precision that
GetTickCount()
Post by Ross Bencina
if you can - this will only be critical if you are making use of
buffer
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
timestamps though.
Ok.
Post by Ross Bencina
Post by Gordon Gidluck
3) GetEnvironmentVariable() problem: not supported on CE.
fix: In pa_win_wmme.c I return -1 from the
GetEnvDefaultDeviceID()
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
Post by Gordon Gidluck
function. I used this approach also for test examples in V18, and it
seems
Post by Ross Bencina
Post by Gordon Gidluck
to have worked out ok.
Sounds reasonable to me.
Maybe I could wrap the WIN32_PLATFORM_PSPC define around anything like
this.
Post by Gordon Gidluck
Post by Ross Bencina
Post by Gordon Gidluck
4) StartStream() problem: no SetPriorityClass() function, nor
HIGH_PRIORITY_CLASS constant.
fix: commented out the code which tells of a
paUnanticipatedHostError.
Post by Ross Bencina
Post by Gordon Gidluck
Did the same in V18.
Related to this, I will try to use the SetThreadPriority()
function
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
where
Post by Gordon Gidluck
implemented.
I think we should probably review whether SetPriorityClass() should be
called by default anyway. At the moment it can be disabled using the
PaWinMmeNoHighPriorityProcessClass host API specific flag.
I will do that.
Post by Ross Bencina
Post by Gordon Gidluck
5) You will have no stdout or stdin with CE. There are some possible
workarounds for this. My method is to create an ascii text file (ie.
log)
Post by Ross Bencina
Post by Gordon Gidluck
for each module.
Sounds reasonable, although I'm wondering where you needed to use
stdin/stdout? was it just for running the tests?
Yes. Really I just insert code into modules where I need to figure out
what's happening. Like for instance, why the initialization code is not
happening. A slower way to work though, but it works.
Post by Ross Bencina
Post by Gordon Gidluck
=============================
Comments (on V19) specific to pa_win_wmme.c
I am using the wmme code as a template because of CE's similarities
to
Post by Gordon Gidluck
Post by Gordon Gidluck
the
Post by Ross Bencina
Post by Gordon Gidluck
WIN32 API.
All of the compile errors generated in pa_win_wmme.c for me are
resolved.
Post by Ross Bencina
Post by Gordon Gidluck
All that remain are warnings. I am getting a lot of warnings from
EVC++
Post by Gordon Gidluck
Post by Ross Bencina
Post by Gordon Gidluck
regarding
incompatible types, for example...
line #344 PA_MME_SET_LAST_WAVEIN_ERROR( mmresult );
'function' : incompatible types - from 'char [128]' to 'unsigned
short
Post by Gordon Gidluck
Post by Gordon Gidluck
*'
Post by Ross Bencina
Post by Gordon Gidluck
line #353 winMmeHostApi->allocations, strlen( wic.szPname ) + 1 +
sizeof(constInputMapperSuffix_) );
'function' : incompatible types - from 'unsigned short [32]' to
'const
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
char
Post by Gordon Gidluck
*'
Please advise. Should I be concerned about these?
Should I do any type casting or just let them go `as is` because
they
Post by Gordon Gidluck
Post by Gordon Gidluck
are
Post by Ross Bencina
Post by Gordon Gidluck
just warnings?
As Richard noted, this looks like a unicode issue - I would be
concerned,
Post by Gordon Gidluck
Post by Ross Bencina
unless you have the option of not compiling with unicode support, in
which
Post by Gordon Gidluck
Post by Ross Bencina
case we can leave it until someone needs it and update the code then -
it
Post by Gordon Gidluck
Post by Ross Bencina
does raise questions about how PortAudio will support unicode in the
future
Post by Ross Bencina
though.
I was able to make V18 work for the patest_recording code without
dealing
Post by Gordon Gidluck
Post by Gordon Gidluck
with the unicode issue in depth. For other reasons I need to keep
UNICODE
Post by Gordon Gidluck
Post by Gordon Gidluck
defined. I think it also would be smart to have future support for
UNICODE
Post by Gordon Gidluck
Post by Gordon Gidluck
in portaudio, but this is perhaps too big of an issue at this time.
Post by Ross Bencina
Post by Gordon Gidluck
-----------------------
function: InitializeInputDeviceInfo()
function: InitializeOutputDeviceInfo()
Just FYI. these functions both have a unreferenced variable 'i'.
/* If channel max is goofy, then query for max channels.
PLB20020228
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
* This doesn't seem to help. Disable code for now. Remove it
later.
Post by Ross Bencina
*/
Phil - can this code go?
Post by Gordon Gidluck
-----------------------
function: ProcessingThreadProc()
line #1665 DWORD timeout = stream->allBuffersDurationMs * 0.5;
conversion from 'double ' to 'unsigned long ', possible loss of data
-----------------------
function: ProcessingThreadProc()
line #1947/1948 Sleep( stream->bufferProcessor.framesPerHostBuffer *
stream->bufferProcessor.samplePeriod * .25 );
conversion from 'double ' to 'unsigned long ', possible loss of data
integral size mismatch in argument; conversion supplied
Thanks, I've made a note of these, but I want to inspect the code
further
Post by Gordon Gidluck
Post by Ross Bencina
before fixing them.
Best wishes,
Ross.
Thanks again. I am having some runtime issue in the Pa_Initialization()
section. Could it have to do with the broken code? Error number -9999.
Unanticipated host error.
Gordon
Ross Bencina
2003-03-16 22:46:01 UTC
Permalink
Hi Gordon
Post by Gordon Gidluck
Think I found the source of some of my woes here. I am using
patest_record.c
Post by Gordon Gidluck
from the V19 development. The function Pa_OpenStream in pa_front.c (I am
using) only has 8 parameters whereas the call in patest_record.c has 16.
I am surprised that your compiler compiled successfully then.
Post by Gordon Gidluck
It would appear that the pa_front.c code is older (v 1.1.2.36) whereas the
other is (v 1.2.2.2). Is there a newer version of pa_front.c available?
Hi Gordon

At the moment it's always best to assume that portaudio.h and pa_front.c are
up to date compared to the tests.

Pa_OpenStream now has fewer parameters because it uses the
PaStreamParameters structure to pass information about the input and output
streams. I don't think many of the tests have been updated to support this.
This is documented in portaudio.h - If you install doxygen you can run
Post by Gordon Gidluck
doxygen config.doxy
In the root PortAudio directory which generates easy to read documentation
in docs/doxygen_html
Post by Gordon Gidluck
I downloaded my initial snapshot from the file pa_snapshot_v19.tar.gz. I
guess that what may have happened is that as I was trying to find functions
to compile the source with, I may have included older versions if I did not
find a new source in the download.
If you want to stay current with v19-devel I strongly suggest that you
install WinCVS and update your tree regularly - WinCVS will also draw graphs
showing revision history, which would have answered your question above.

Ross.
Post by Gordon Gidluck
Gordon Gidluck
www.gidluckmastering.com
----- Original Message -----
Sent: Saturday, March 15, 2003 3:04 PM
Subject: Re: [Portaudio] Re: 24-bit recording
Post by Gordon Gidluck
Ross and portaudio list,
Windows CE and V19 of portaudio. Having an initialization problem. I
followed it through to the InitializeInputDeviceInfo() function. This code
is quite a bit different from the V18 implementation, which works for me,
but this section is giving me some problem in the initialization. V18 will
record and play a sine wave for me on an iPAQ 3635.
When the API function waveInGetCaps() is called, I am getting an error
here.
Post by Gordon Gidluck
A value of 6 is being returned. FYI, when waveInGetCaps is called
deviceIndex is 0 and inputWinMmeId is -1 (WAVE_MAPPER). Should deviceIndex
not be an integer > 0? Any ideas? Comments?
Also, I'm note real sure about PaUtilHostApiInitializer in
pa_win_hostapis.c. Should I be commenting out the reference to
Pa_skeleton_Initialize? Is this just for testing?
Thanks!
Gordon
----- Original Message -----
Sent: Monday, March 10, 2003 8:24 AM
Subject: Re: [Portaudio] Re: 24-bit recording
Post by Gordon Gidluck
Ross,
Thanks for looking into this. Responses are embedded.
Post by Ross Bencina
There are a couple of critical fixmes in
pa_win_wmme.c:CalculateBufferSettings() (buffer sizes are hardwired at
lines
Post by Ross Bencina
733 and 764) - I'll make them my first priority and check something
into
Post by Gordon Gidluck
Post by Gordon Gidluck
CVS
Post by Ross Bencina
in the next day or two.
Thanks.
Post by Ross Bencina
I'm not sure how you want to proceed with the CE patches - my
preference
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
would be to work to minimise the number of changes necessary between
the
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
Win32 and WinCE versions, and then add appropriate #ifdefs to the
Win32
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
sources. Are you already happy that the changes you have listed are
all
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
that's needed to get pa_win_wmme.c working with WinCE? What
precompiler
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
symbol is available on WinCE to differentiate from Win32?
#ifdef WIN32_PLATFORM_PSPC
This will work for the Pocket PC.
RE: to get pa_win_wmme.c working?
Yes, I think I have now identified the major issues involved.
Post by Ross Bencina
Post by Gordon Gidluck
Here are a few notes for anyone working with CE and portAudio in the
These notes refer to embedded VC++ 3.0. Some of this is new, and
some
Post by Gordon Gidluck
is
Post by Gordon Gidluck
a
Post by Ross Bencina
Post by Gordon Gidluck
rehash of issues I mentioned in October.
1) assert() function. I cannot include <assert.h>
There must be a way to do this.
fix: I commented out assert() lines.
I don't know enough about wince to know why assert isn't there.
Perhaps
Post by Gordon Gidluck
Post by Gordon Gidluck
you
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceoem/htm/
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Gordon Gidluck
_wcepb_assert.asp
I will look more into this. (FYI) There seems to be some attempt to
remove
Post by Gordon Gidluck
Post by Gordon Gidluck
assertion code out of the final releases. I will try to implement the
ANSI
Post by Gordon Gidluck
Post by Gordon Gidluck
code as is or make the implementation work with a minimum amount of
coding
Post by Gordon Gidluck
Post by Gordon Gidluck
effort. Defining _DEBUG at a certain time allows use of an ASSERT macro.
I
Post by Gordon Gidluck
Post by Gordon Gidluck
will use it as a last resort.
Post by Ross Bencina
Post by Gordon Gidluck
2) timeGetTime() problem: not supported in CE.
fix: I used GetTickCount() which from MSDN docs appears to be
very
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
Post by Gordon Gidluck
similar.
I would recommend using something with higher precision that
GetTickCount()
Post by Ross Bencina
if you can - this will only be critical if you are making use of
buffer
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
timestamps though.
Ok.
Post by Ross Bencina
Post by Gordon Gidluck
3) GetEnvironmentVariable() problem: not supported on CE.
fix: In pa_win_wmme.c I return -1 from the
GetEnvDefaultDeviceID()
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
Post by Gordon Gidluck
function. I used this approach also for test examples in V18, and it
seems
Post by Ross Bencina
Post by Gordon Gidluck
to have worked out ok.
Sounds reasonable to me.
Maybe I could wrap the WIN32_PLATFORM_PSPC define around anything like
this.
Post by Gordon Gidluck
Post by Ross Bencina
Post by Gordon Gidluck
4) StartStream() problem: no SetPriorityClass() function, nor
HIGH_PRIORITY_CLASS constant.
fix: commented out the code which tells of a
paUnanticipatedHostError.
Post by Ross Bencina
Post by Gordon Gidluck
Did the same in V18.
Related to this, I will try to use the SetThreadPriority()
function
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
where
Post by Gordon Gidluck
implemented.
I think we should probably review whether SetPriorityClass() should be
called by default anyway. At the moment it can be disabled using the
PaWinMmeNoHighPriorityProcessClass host API specific flag.
I will do that.
Post by Ross Bencina
Post by Gordon Gidluck
5) You will have no stdout or stdin with CE. There are some possible
workarounds for this. My method is to create an ascii text file (ie.
log)
Post by Ross Bencina
Post by Gordon Gidluck
for each module.
Sounds reasonable, although I'm wondering where you needed to use
stdin/stdout? was it just for running the tests?
Yes. Really I just insert code into modules where I need to figure out
what's happening. Like for instance, why the initialization code is not
happening. A slower way to work though, but it works.
Post by Ross Bencina
Post by Gordon Gidluck
=============================
Comments (on V19) specific to pa_win_wmme.c
I am using the wmme code as a template because of CE's
similarities
Post by Gordon Gidluck
to
Post by Gordon Gidluck
Post by Gordon Gidluck
the
Post by Ross Bencina
Post by Gordon Gidluck
WIN32 API.
All of the compile errors generated in pa_win_wmme.c for me are
resolved.
Post by Ross Bencina
Post by Gordon Gidluck
All that remain are warnings. I am getting a lot of warnings from
EVC++
Post by Gordon Gidluck
Post by Ross Bencina
Post by Gordon Gidluck
regarding
incompatible types, for example...
line #344 PA_MME_SET_LAST_WAVEIN_ERROR( mmresult );
'function' : incompatible types - from 'char [128]' to 'unsigned
short
Post by Gordon Gidluck
Post by Gordon Gidluck
*'
Post by Ross Bencina
Post by Gordon Gidluck
line #353 winMmeHostApi->allocations, strlen( wic.szPname ) + 1 +
sizeof(constInputMapperSuffix_) );
'function' : incompatible types - from 'unsigned short [32]' to
'const
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
char
Post by Gordon Gidluck
*'
Please advise. Should I be concerned about these?
Should I do any type casting or just let them go `as is` because
they
Post by Gordon Gidluck
Post by Gordon Gidluck
are
Post by Ross Bencina
Post by Gordon Gidluck
just warnings?
As Richard noted, this looks like a unicode issue - I would be
concerned,
Post by Gordon Gidluck
Post by Ross Bencina
unless you have the option of not compiling with unicode support, in
which
Post by Gordon Gidluck
Post by Ross Bencina
case we can leave it until someone needs it and update the code then -
it
Post by Gordon Gidluck
Post by Ross Bencina
does raise questions about how PortAudio will support unicode in the
future
Post by Ross Bencina
though.
I was able to make V18 work for the patest_recording code without
dealing
Post by Gordon Gidluck
Post by Gordon Gidluck
with the unicode issue in depth. For other reasons I need to keep
UNICODE
Post by Gordon Gidluck
Post by Gordon Gidluck
defined. I think it also would be smart to have future support for
UNICODE
Post by Gordon Gidluck
Post by Gordon Gidluck
in portaudio, but this is perhaps too big of an issue at this time.
Post by Ross Bencina
Post by Gordon Gidluck
-----------------------
function: InitializeInputDeviceInfo()
function: InitializeOutputDeviceInfo()
Just FYI. these functions both have a unreferenced variable 'i'.
/* If channel max is goofy, then query for max channels.
PLB20020228
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Ross Bencina
* This doesn't seem to help. Disable code for now. Remove it
later.
Post by Ross Bencina
*/
Phil - can this code go?
Post by Gordon Gidluck
-----------------------
function: ProcessingThreadProc()
line #1665 DWORD timeout = stream->allBuffersDurationMs * 0.5;
conversion from 'double ' to 'unsigned long ', possible loss of data
-----------------------
function: ProcessingThreadProc()
line #1947/1948 Sleep( stream->bufferProcessor.framesPerHostBuffer *
stream->bufferProcessor.samplePeriod * .25 );
conversion from 'double ' to 'unsigned long ', possible loss of data
integral size mismatch in argument; conversion supplied
Thanks, I've made a note of these, but I want to inspect the code
further
Post by Gordon Gidluck
Post by Ross Bencina
before fixing them.
Best wishes,
Ross.
Thanks again. I am having some runtime issue in the
Pa_Initialization()
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Gordon Gidluck
section. Could it have to do with the broken code? Error
number -9999.
Post by Gordon Gidluck
Post by Gordon Gidluck
Post by Gordon Gidluck
Unanticipated host error.
Gordon
Continue reading on narkive:
Loading...