Re: 24-bit recording

Discussion:

(too old to reply)

Gordon Gidluck

2003-03-08 23:31:01 UTC

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
...

..
_______________________________________________
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

_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