🚀 go-pugleaf

"Chris Croughton" <chris@keristor.net> wrote in message
news:slrncgs56p.j46.chris@ccserver.keris.net...
| Further to my last, the WAVEFORMATEX structure has values:
...
|   0x00056220    352800  nAvgBytesPerSec

Hiya Chris. I have also experimented with very high byte rates using BCB5. I
found that the Windows multimedia system is a bit slow at handling such high
rates, and data drop-outs are frequent. If you up the priority using :-

SetPriorityClass(Application->Handle,HIGH_PRIORITY_CLASS);
// or something like that

does that make a difference?
-- 
Mark Jacobs
DK Computing
http://www.dkcomputing.co.uk
markj atty critical dotty co dotty uk

On Tue, 3 Aug 2004 11:40:23 +0100, Mark Jacobs 
   <> wrote:

> "Chris Croughton" <chris@keristor.net> wrote in message
> news:slrncgs56p.j46.chris@ccserver.keris.net...
>| Further to my last, the WAVEFORMATEX structure has values:
> ...
>|   0x00056220    352800  nAvgBytesPerSec
> 
> Hiya Chris. I have also experimented with very high byte rates using BCB5. I
> found that the Windows multimedia system is a bit slow at handling such high
> rates, and data drop-outs are frequent. If you up the priority using :-
> 
> SetPriorityClass(Application->Handle,HIGH_PRIORITY_CLASS);
> // or something like that
> 
> does that make a difference?

Good thinking, I wondered about 100Hz (sounds like the system clock
frequency).  Unfortunately, no, it doesn't eliminate it.  It makes the
100Hz 'ticks' worse, if anything, and I still only get the right-hand
channel.  When I set it to 16 bits (with the format == 1, not extended)
it's fine (but at 16 bits).  As a dyslexic young friend of mine says,
I'm confussed...

It's not really a  very high rate, the sound card (and other software
using the same system and hardware) goes up to 24/96kHz quite happily.

Thanks for pointing me at that system call, it will be useful in other
places...

Chris C

Actually, I am in 2 minds whether it should be Application->Handle or
HInstance. Does using HInstance instead, help you?
-- 
Mark Jacobs
DK Computing
http://www.dkcomputing.co.uk
markj atty critical dotty co dotty uk

"Chris Croughton" <chris@keristor.net> wrote in message
news:slrncgvo3t.5n3.chris@ccserver.keris.net...
| > SetPriorityClass(Application->Handle,HIGH_PRIORITY_CLASS);
| Unfortunately, no, it doesn't eliminate it.  It makes the
| 100Hz 'ticks' worse, if anything, and I still only get the right-hand
| channel.  When I set it to 16 bits (with the format == 1, not extended)
| it's fine (but at 16 bits).  As a dyslexic young friend of mine says,
| I'm confussed...
|
| It's not really a  very high rate, the sound card (and other software
| using the same system and hardware) goes up to 24/96kHz quite happily.

Forget all that. This is from the MFC master Remy Lebeau :-

SetPriorityClass(GetCurrentProcess(),HIGH_PRIORITY_CLASS);
-- 
Mark Jacobs

"Mark Jacobs" <markj atty critical dotty co dotty uk> wrote in message
news:4110bf9b@newsgroups.borland.com...
...

On Wed, 4 Aug 2004 20:14:05 +0100, Mark Jacobs 
   <mark@losethisbitjacobsm.com> wrote:

> Forget all that. This is from the MFC master Remy Lebeau :-
> 
> SetPriorityClass(GetCurrentProcess(),HIGH_PRIORITY_CLASS);

Still no change (Application->HInstance doesn't exist, BTW).

The format has got to be wrong, somehow, because giving floating-point
(and apparently only 16 bits significant, at that) and only one channel
is not at all what I'd expect or want.  I can live with FP if I have to,
but not the missing channel...

Surely someone must have done it?  But there seems to be little in the
way of resources for learning about audio at all, and nothing that I can
find about 24 bit input...

Chris C

On Wed, 4 Aug 2004 22:53:25 +0100, Chris Croughton <chris@keristor.net>  
wrote:

> The format has got to be wrong, somehow, because giving floating-point
> (and apparently only 16 bits significant, at that) and only one channel
> is not at all what I'd expect or want.  I can live with FP if I have to,
> but not the missing channel...

I found that WAVEFORMATEX structures need to be naturally discovered on  
the PC using the ACM. Somehow, you have to discover the formats for 24-bit  
sound handling. Remember that 24-bit is 3-bytes per sample, and most  
compilers align structures to 4-byte boundaries - could that be the  
problem? The data buffer is simply a character array (char *) so the byte  
alignment doesn't make a difference in my apps. I have to interpret  
different bits per sample, using different algorithms. However, I did  
notice something peculiar when I went to 8-bit sampling (for VU meters  
etcetera). In the following code snippets, glbwvhdr is the pointer to the  
WAVEHDR structure that is ready and has been "unprepared" successfully.  
Here is my 8-bit code :-

   int  
lv=128-abs((int)glbwvhdr->lpData[0]),rv=128-abs((int)glbwvhdr->lpData[1]);
   if (glbwvhdr->lpData[0]<0) lv=-lv;
   if (glbwvhdr->lpData[1]<0) rv=-rv;
   zcDinMeter1->Value=lv*100/128; // Value is between 0 and 100
   zcDinMeter2->Value=rv*100/128;

Now compare that to my 16-bit code :-

   short *mybf=(short *)glbwvhdr->lpData;
   zcDinMeter1->Value=(int)mybf[0]*100*/32768; // Value is between -100 and  
100
   zcDinMeter2->Value=(int)mybf[1]*100*/32768;

Lord knows what 24-bit decode should look like, or why I have to muck  
about so much with 8-bit samples to get them right!?! But let me just say  
that your symptoms of having barely any signal in the right channel, is  
exactly what I got when I used the 16-bit algorithm (adapted to 8-bit) on  
the 8-bit samples. Perhaps if you use my 8-bit algorithm, but change 128  
to 8388608, and the buffer has to be re-interpreted. Try this :-

   int  
dtlv=(int)glbwvhdr->lpData[0]*256*256+(int)glbwvhdr->lpData[1]*256+(int)glbwvhdr->lpData[2];
   int  
dtrv=(int)glbwvhdr->lpData[3]*256*256+(int)glbwvhdr->lpData[4]*256+(int)glbwvhdr->lpData[5];
   int lv=8388608-abs(dtlv),rv=8388608-abs(dtrv);
   if (glbwvhdr->lpData[0]<0) lv=-lv;
   if (glbwvhdr->lpData[1]<0) rv=-rv;
   zcDinMeter1->Value=lv*100/8388608; // Value is between 0 and 100
   zcDinMeter2->Value=rv*100/8388608;

Does that work? If not, swap the bytes round backwards, so that the first  
2 lines look like this :-

   int  
dtlv=(int)glbwvhdr->lpData[2]*256*256+(int)glbwvhdr->lpData[1]*256+(int)glbwvhdr->lpData[0];
   int  
dtrv=(int)glbwvhdr->lpData[5]*256*256+(int)glbwvhdr->lpData[4]*256+(int)glbwvhdr->lpData[3];

HTH. Let us know how it goes. Cheers,
-- 
Mark Jacobs
DK Computing
http://www.dkcomputing.co.uk
markj atty critical dotty co dotty uk

On Thu, 05 Aug 2004 12:13:41 +0100, Mark Jacobs 
   <> wrote:

> I found that WAVEFORMATEX structures need to be naturally discovered on  
> the PC using the ACM.

That's the problem, the ACM doesn't seem to say anything about 24 bit
samples at all on my machine.

> Somehow, you have to discover the formats for 24-bit  
> sound handling. Remember that 24-bit is 3-bytes per sample, and most  
> compilers align structures to 4-byte boundaries - could that be the  
> problem? The data buffer is simply a character array (char *) so the byte  
> alignment doesn't make a difference in my apps. I have to interpret  
> different bits per sample, using different algorithms.

When I tried it with different sample sizes, for sizes up to 16 bits I
simply wrote the data out to a WAV file with no interpretation and that
seemed to work fine, si it seemed that what is returned is standard WAV
data.

For 24 bits, I've tried block alignments at 6 and 8 bytes (stereo, so 3
and 4 bytes per value) with no difference.

> However, I did  notice something peculiar when I went to 8-bit
> sampling (for VU meters  etcetera). In the following code snippets,
> glbwvhdr is the pointer to the  WAVEHDR structure that is ready and
> has been "unprepared" successfully.  Here is my 8-bit code :-

No surprise there, 8 bit data is encoded as and unsigned value, with 128
representing the zero point, just subtract 128 from each (unsigned) byte
and it works fine.  (Historical reasons: the early soundcards used 8
bit DACs which couldn't handle negative values, so the software wrote it
as an unsigned byte and the hardware either normalised it to the zero
point with a capacitative coupling which removed any DC offset, or some
just offset it down by half the FSD value with a resistor chain.)

Unfortunately, I can't try it again and produce files at the moment
because my Win2k machine seems to have developed a fault (it comes up
with a BSoD telling me about configuration errors, page tables
uninitialised, page faults ate weird (and nonexistent) memory addresses,
etc., I think it's very sick and needs surgery).

>    int  
> lv=128-abs((int)glbwvhdr->lpData[0]),rv=128-abs((int)glbwvhdr->lpData[1]);
>    if (glbwvhdr->lpData[0]<0) lv=-lv;
>    if (glbwvhdr->lpData[1]<0) rv=-rv;

I don't understand why the business with abs() and then inverting it
again.  What's wrong with:

  int lv = (int)((unsigned char)glbwvhdr->lpData[0]) - 128;
  int rv = (int)((unsigned char)glbwvhdr->lpData[1]) - 128;

(I think that lpData is an (unsigned char *) anyway, but I'm making sure
by casting it.)  Your code gives the same values, except that you treat
0x80 as +128 instead of -128.

A shorter (but more obscure) way of doing it is to do:

  int lv = (signed char)(glbwvhdr->lpData[0] ^ 128);

>    zcDinMeter1->Value=lv*100/128; // Value is between 0 and 100
>    zcDinMeter2->Value=rv*100/128;
> 
> Now compare that to my 16-bit code :-
> 
>    short *mybf=(short *)glbwvhdr->lpData;
>    zcDinMeter1->Value=(int)mybf[0]*100*/32768; // Value is between -100 and  
> 100
>    zcDinMeter2->Value=(int)mybf[1]*100*/32768;

Since you know that the endianness is the same, you can do that.

> Lord knows what 24-bit decode should look like, or why I have to muck  
> about so much with 8-bit samples to get them right!?!

Well, with WAV files 24 bit samples are

  long lv = sample[0] + sample[1]*256 + sample[2]*65536;

(and then the same for the right channel, divide by 8388608.0 to get it
as a float with range (-1,+1]).  That works with 24 bit 'unpacked'
formats produced by (and understood by) n-Track, CoolEdit and Creative's
WaveEditor (or whatever it calls itself in the Audigy incarnation).
There are also 32 bit float formats, which I think are the standard IEEE
floating point ones but I haven't seen any examples yet.

> But let me just say  
> that your symptoms of having barely any signal in the right channel, is  
> exactly what I got when I used the 16-bit algorithm (adapted to 8-bit) on  
> the 8-bit samples. Perhaps if you use my 8-bit algorithm, but change 128  
> to 8388608, and the buffer has to be re-interpreted. Try this :-

No, the values I'm seeing are definitely IEEE floats, they make sense if
I just do

  float *fptr = (float*)lpData;
  long lv = (long)(fptr[0] * 8388608);
  long rv = (long)(fptr[1] * 8388608);

Except that the lv (left channel) is always zero, and the right channel
always has the bottom byte set to zero (i.e. the float value is
(float)(short) conversion).

>    int  
> dtlv=(int)glbwvhdr->lpData[0]*256*256+(int)glbwvhdr->lpData[1]*256+(int)glbwvhdr->lpData[2];
>    int  
> dtrv=(int)glbwvhdr->lpData[3]*256*256+(int)glbwvhdr->lpData[4]*256+(int)glbwvhdr->lpData[5];
>    int lv=8388608-abs(dtlv),rv=8388608-abs(dtrv);
>    if (glbwvhdr->lpData[0]<0) lv=-lv;
>    if (glbwvhdr->lpData[1]<0) rv=-rv;
>    zcDinMeter1->Value=lv*100/8388608; // Value is between 0 and 100
>    zcDinMeter2->Value=rv*100/8388608;
> 
> Does that work? If not, swap the bytes round backwards, so that the first  
> 2 lines look like this :-
> 
>    int  
> dtlv=(int)glbwvhdr->lpData[2]*256*256+(int)glbwvhdr->lpData[1]*256+(int)glbwvhdr->lpData[0];
>    int  
> dtrv=(int)glbwvhdr->lpData[5]*256*256+(int)glbwvhdr->lpData[4]*256+(int)glbwvhdr->lpData[3];

Yup, those were the first I tried (actually, I dumped them to a WAV file
and used my linux WAV file utilities to swap the bytes round and
interpret them as floating point).  The results were, to put it mildly,
painful <g>.  Eventually I tried treating them as floats, just for the
halibut, and that worked (for single channel).

I suspect that you're right, and the FORMATEX values I'm using are
incorrect and are specifying mono 16 bit input represented as floats or
something silly...

Chris C

On Fri, 6 Aug 2004 13:56:49 +0100, Chris Croughton <chris@keristor.net>  
wrote:

> int lv = (int)((unsigned char)glbwvhdr->lpData[0]) - 128;
> int rv = (int)((unsigned char)glbwvhdr->lpData[1]) - 128;

Durrr, Clyde... Yup, I'm an idiot sometimes.

> I suspect that you're right, and the FORMATEX values I'm using are
> incorrect and are specifying mono 16 bit input represented as floats or
> something silly...

I'll cast around and see if I come up with anything about 24-bit and  
32-bit sound sampling. I'll post back here if I come up with something.  
Cheers,
-- 
Mark Jacobs
http://www.jacobsm.com

On Fri, 06 Aug 2004 14:38:30 +0100, Mark Jacobs 
   <mark@jacobsm.com> wrote:

> On Fri, 6 Aug 2004 13:56:49 +0100, Chris Croughton <chris@keristor.net>  
> wrote:
> 
>> int lv = (int)((unsigned char)glbwvhdr->lpData[0]) - 128;
>> int rv = (int)((unsigned char)glbwvhdr->lpData[1]) - 128;
> 
> Durrr, Clyde... Yup, I'm an idiot sometimes.

Aren't we all?  My favourite is writing something like:

  for (i = 0; i < 10; i++);
    printf("%d\n", i);

and wondering why only the value "10" gets printed <g>.  (OK, it's
usually a little more complicated than that, but the error is the same
-- using an editor with auto-indentation helps a lot...)

>> I suspect that you're right, and the FORMATEX values I'm using are
>> incorrect and are specifying mono 16 bit input represented as floats or
>> something silly...
> 
> I'll cast around and see if I come up with anything about 24-bit and  
> 32-bit sound sampling. I'll post back here if I come up with something.  

Thanks.   BTW, my Win2k machine worked again this evening.  Definitely a
hardware fault...

Chris C

On Fri, 6 Aug 2004 22:12:36 +0100, Chris Croughton <chris@keristor.net>  
wrote:

>> I'll cast around and see if I come up with anything about 24-bit and
>> 32-bit sound sampling. I'll post back here if I come up with something.
> Thanks.

Try some of the links thrown up by  
http://www.google.com/search?num=100&q=waveformatex+24-bit

-- 
Mark Jacobs
DK Computing
http://www.dkcomputing.co.uk
markj atty critical dotty co dotty uk

On Mon, 16 Aug 2004 15:00:47 +0100, Mark Jacobs 
   <> wrote:

> On Fri, 6 Aug 2004 22:12:36 +0100, Chris Croughton <chris@keristor.net>  
> wrote:
> 
>>> I'll cast around and see if I come up with anything about 24-bit and
>>> 32-bit sound sampling. I'll post back here if I come up with something.
>> Thanks.
> 
> Try some of the links thrown up by  
> http://www.google.com/search?num=100&q=waveformatex+24-bit

The one you sent me in email (http://www.ambisonic.net/mulchaud.html),
which hadn't shown up on my previous Google searches, gave me a clue,
when I inspected the structures in hex and looked at the GUID in the
structure.

It's Borland's fault!  When I compiled with MSVC++, the GUID was in a
different place, and it worked.

Specifically, BC++ 6 pads structures within structures.  The
WAVEFORMATPCMEX has the definition:

  {
    WAVEFORMATEX Format;
    union {
      WORD wValidBitsPerSample;       /* bits of precision  */
      WORD wSamplesPerBlock;          /* valid if wBitsPerSample==0 */
      WORD wReserved;                 /* If neither applies, set to zero. */
    } Samples;
    DWORD  dwChannelMask;         /* which channels are present in stream */
    GUID SubFormat;
  };

Where WAVEFORMATEX has length 18.  MSVC notices that this ends on a word
boundary, and so puts the next element immediately afterwards (packing
them).  BC++ pads the WAVEFORMATEX structure to a DWORD boundary, thus
putting the Samples member 2 bytes further on, then dwChannelMask on the
next DWORD boundary, so the GUID ends up 4 bytes further on than it
should be.  The surprising thing is that it even opened and attempted to
input data at all!

I've now rewritten the structure as a single entity, and it now works!
No glitches, clean 24-bit input...  The structure I'm using is:

  struct MyWAVEFORMATPCMEX
  {
      WORD    wFormatTag;      // format type
      WORD    nChannels;       // number of channels (i.e. mono, stereo...)
      DWORD   nSamplesPerSec;  // sample rate
      DWORD   nAvgBytesPerSec; // for buffer estimation
      WORD    nBlockAlign;     // block size of data
      WORD    wBitsPerSample;  // Number of bits per sample of mono data
      WORD    cbSize;          // The count in bytes of the size of
                               // extra information (after cbSize)
      union {
          WORD wValidBitsPerSample;     // bits of precision 
          WORD wSamplesPerBlock;        // valid if wBitsPerSample==0
          WORD wReserved;               // If neither applies, set to zero.
      } Samples;
      DWORD   dwChannelMask;    // which channels are present in stream 
      GUID    SubFormat;
  };

However, I'm sure BC++ has a way to indicate that structures are packed
and not padded to 4-byte boundaries, but I can't find it.  The Borland
versions of ksmedia.h, mmreg.h, etc. seem to be straight clones of the
ones in the MSVC headers, and as such they are basically broken.  (Oh,
the GUID variables are missing as well, because they are in an MS
library which of course won't link.)

Thanks for the help, anyway.  When I have this code working in a decent
form (like, commented and decently structured) I'll be putting it on my
web site for anyone to use...

Chris C

On Mon, 16 Aug 2004 19:37:34 +0100, Chris Croughton <chris@keristor.net>  
wrote:

> I'm sure BC++ has a way to indicate that structures are packed
> and not padded to 4-byte boundaries, but I can't find it.

It certainly has. If you look under Project, Options, Advanced Compiler,  
Data Alignment Radiogroup, and select Word boundaries (2-byte), it should  
work in the same way MSVC works. The Borland default is Double Word  
alignment (4-byte).

-- 
Mark Jacobs
http://www.jacobsm.com

Hi,

> It certainly has. If you look under Project, Options, Advanced 
> Compiler,  Data Alignment Radiogroup, and select Word boundaries 
> (2-byte), it should  work in the same way MSVC works. The Borland 
> default is Double Word  alignment (4-byte).

Just a remark: I did that (but with byte-alignment) in another context 
some time ago and got lots of errors: Parts of the VCL seemed to be 
"unhappy" with this setting. I needed Byte-Alignment - Maybe there is no 
such problem with word-alignment.

But there is also a way, to set the alignment only for special parts of 
the sourcecode. I don't exectly remember how it is done, but there is 
some metacommand to achieve this.

Best regards
Michael Kutscher

On Tue, 17 Aug 2004 09:00:48 +0100, Mark Jacobs 
   <mark@jacobsm.com> wrote:

> On Mon, 16 Aug 2004 19:37:34 +0100, Chris Croughton <chris@keristor.net>  
> wrote:
> 
>> I'm sure BC++ has a way to indicate that structures are packed
>> and not padded to 4-byte boundaries, but I can't find it.
> 
> It certainly has. If you look under Project, Options, Advanced Compiler,  
> Data Alignment Radiogroup, and select Word boundaries (2-byte), it should  
> work in the same way MSVC works. The Borland default is Double Word  
> alignment (4-byte).

That causes problems with Borland libraries which expect the DW
alignment, there needs to be a local switch to do it for specific
structures (#pragma pack does that, I found it eventually).  

I've found it.  Header files pshpack1.h and poppack.h have

#pragma option push -b -a8 -pc -A- /*P_O_Push*/

at the start and

#pragma option pop

at the end, so all of the manipulations of the pack option in the middle
have no effect!  The Microsoft SDK  ones don't have those lines (and are
otherwise identical).  (The same applies to pshpack{2,4,8}.h)

As I surmised, a Borland bug (although not the one I thought, the
packing options do work).

I see no way round it other than editing those files on every system (or
using my redefined structure)...

Note: this applies to BCB 6 only.  The free command-line-only BC++ 5.5
tools do not have this bug, the files are identical to the MS SDK ones
(except that the latter have a couple of extra tests of defined()
identifiers for _lint and _M_I86).

Is there a specific group for reporting such bugs?

Chris C

On Tue, 17 Aug 2004 10:23:33 +0200, Michael Kutscher 
   <spam.ignore@pc-coach.de> wrote:

> Just a remark: I did that (but with byte-alignment) in another context 
> some time ago and got lots of errors: Parts of the VCL seemed to be 
> "unhappy" with this setting. I needed Byte-Alignment - Maybe there is no 
> such problem with word-alignment.

I think that the Windows API may be word or byte aligned, but some of
the Borland libraries are using the default I believe.

> But there is also a way, to set the alignment only for special parts of 
> the sourcecode. I don't exectly remember how it is done, but there is 
> some metacommand to achieve this.

#pragma pack (or #pragma option pack) lets you set, push and pop the
option values round the bits of code you need to specify.  There is also
an option to set it for an identifier explicitly, but not much
explanation of how and when to use it.

Chris C