Prev: ruas in the same console
Next: [C++ Builder] Hide application from activities list
From: Larry on 13 Jan 2010 04:25
Hi,

I have a single question about the audio buffer in the waveform api's
WAVEHDR structure, given the following code:

// Define WAVEHDR Structure:
//
// 3 buffers, 4096 bytes long each:
//
// DWORD dwNumBuffers = 3;
// DWORD dwBufferLength = 4096;

WAVEHDR *buff = new WAVEHDR[dwNumBuffers];
for (int i = 0; i<(int)dwNumBuffers; i++)
{
ZeroMemory(&buff[i], sizeof(buff[i]));

buff[i].lpData = (LPSTR) malloc(dwBufferLength);
buff[i].dwBufferLength = dwBufferLength;
buff[i].dwBytesRecorded = 0;
buff[i].dwUser = 0;
buff[i].dwFlags = 0;
buff[i].dwLoops = 0;

// ... pass the buffer to the system ...
}

why is it not just using:

buff[i].lpData = (unsigned char*) malloc(dwBufferLength);

to deal with the binary data? wouldn't 0-255 range better?

thanks

From: ScottMcP [MVP] on 13 Jan 2010 11:42
On Jan 13, 4:25 am, "Larry" <dontmewit...(a)got.it> wrote:
> why is it not just using:
>
>  buff[i].lpData          = (unsigned char*) malloc(dwBufferLength);
>
> to deal with the binary data? wouldn't 0-255 range better?
>
> thanks

It doesn't make any difference. For a buffer for WAV data the
pointer's type is going to be wrong no matter what it is, since the
data comes in many formats. (And none of them use a 0-255 range.)
For the operations that will be performed on WAV data neither char* or
unsigned char* is right: It is necessary to cast the pointer to
whatever is really stored in the buffer.
From: Bob Masta on 14 Jan 2010 08:45
On Wed, 13 Jan 2010 08:42:58 -0800 (PST),
"ScottMcP [MVP]" <scottmcp(a)mvps.org> wrote:

>On Jan 13, 4:25=A0am, "Larry" <dontmewit...(a)got.it> wrote:
>> why is it not just using:
>>
>> =A0buff[i].lpData =A0 =A0 =A0 =A0 =A0=3D (unsigned char*) malloc(dwBuffer=
>Length);
>>
>> to deal with the binary data? wouldn't 0-255 range better?
>>
>> thanks
>
>It doesn't make any difference. For a buffer for WAV data the
>pointer's type is going to be wrong no matter what it is, since the
>data comes in many formats. (And none of them use a 0-255 range.)
>For the operations that will be performed on WAV data neither char* or
>unsigned char* is right: It is necessary to cast the pointer to
>whatever is really stored in the buffer.

Not to pick nits, but 8-bit PCM WAV is always
unsigned bytes (0-255, with 128 being the
effective waveform "0" value.) Not much call for
8-bit WAVs these days, but the format is still
used with modems.

Best regards,


Bob Masta

DAQARTA v5.00
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
Frequency Counter, FREE Signal Generator
Pitch Track, Pitch-to-MIDI
DaqMusic - FREE MUSIC, Forever!
(Some assembly required)
Science (and fun!) with your sound card!
From: ScottMcP [MVP] on 14 Jan 2010 09:43
On Jan 14, 8:45 am, N0S...(a)daqarta.com (Bob Masta) wrote:
> Not to pick nits, but 8-bit PCM WAV is always
> unsigned bytes (0-255, with 128 being the
> effective waveform "0" value.)  Not much call for
> 8-bit WAVs these days, but the format is still
> used with modems.

Also not to pick nits with your nit, but 8-bit PCM WAV is not
unsigned, it is one's complement signed bytes. Since there is no such
type supported by the language or CPU, the lpData pointer type is
wrong for that data format too :(

From: Richard Russell on 14 Jan 2010 17:29
On Jan 14, 2:43 pm, "ScottMcP [MVP]" <scott...(a)mvps.org> wrote:
> Also not to pick nits with your nit, but 8-bit PCM WAV is not
> unsigned, it is one's complement signed bytes.

Are you absolutely sure about that? In 8-bit one's complement
notation both 00000000 and 11111111 represent the value zero, and I
didn't think that was true for WAV data. I've always known the
encoding described by Bob (where 00000000 is the most negative value,
10000000 is zero and 11111111 the most positive value) as 'offset
binary'. Wikipedia seems to think it should be called 'excess-128'.

Richard.
http://www.rtrussell.co.uk/
 |  Next  |  Last
Pages: 1 2
Prev: ruas in the same console
Next: [C++ Builder] Hide application from activities list