RE: Streaming WAVE audio

You state DirectSound, but the example you give is standard windows
audio waveOut. My experience with (bad) noise on waveOut is usually due
to 1 of 3 things.

1) Mixing audio close to the current play position may cause
pops/static. When queuing a sound to play I try to mix at least 50ms
ahead of the play position, but on some hardware I found that I could go
as low as 10-15ms. This maybe due to DMA or inaccuracy of the returned
play position.

2) On some system there appears to be a minimum required buffer size,
e.g. at least 250ms. On systems like these I got silence at best, and
lock up at worst. I didn't spend a lot of time investigating this
because 250ms is pretty short buffer. I was shooting for 4/8/16k buffer
sizes at that time. In the end I don't think it matters.

3) Bad mixing code. We all make errors. First thing I check is
decompressing the audio. The doco on the ACM isn't the best. Matter of
fact we've noticed that buffered compression flat out fails on some
CODECs in Win98/ME with an error code not identified in the doco.
Furthermore I recommend not using the ACM to up/down sample as it
appears to perform point sampling(!) which can produce terrible audio.

My solution is based upon a hybrid approach. I allocate a single largish
(2-4seconds) buffer from which I segment into a number of WAVEHDRs. I
use 1 or 2 WAVEHDRs but the system doesn't care. Like the double buffer
approach you queue the headers and can setup a callback (that's what I
do). In the callback I mix audio and queue the header.

The nice thing about a single buffer is just that. A single buffer is
easy to manage and more cache friendly.

James

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
Brian Hook
Sent: Thursday, July 08, 2004 10:21 PM
To: [email protected]
Subject: RE: [GD-Windows] Streaming WAVE audio

I may actually win the award for oldest thread resurrection (this is
about 2.25 years old).

So I'm rewriting my streaming audio code and open sourcing it
(http://www.bookofhook.com/sal for those that are curious -- it's kind
of pre-alpha right now but seems to work for the most part on
DirectSound, OS X/CoreAudio, OSS/Linux, and ALSA/Linux).

When revisiting my streaming audio code, I realized I was using three
different buffers when in _theory_ I should be able to use one largish
buffer and just query the output position and write the necessary number
of bytes out to it when I'm done.

The key to this is that the buffer is marked as WHDR_BEGINLOOP |
WHDR_ENDLOOP.  I then query the output position in my mixing thread with
waveOutGetPosition().

This works on my system, but it seems to start failing on some systems
randomly depending on the output format (e.g. one user reported that
44KHz worked fine, but there was massive noise/distortion on 22KHz,
using the same executable I was using successfully).

So the question is: is there a definite known problem doing it this way
instead of multibuffering?  I can go back to multibuffering fairly
trivially and just do something like:

queue( buffer[0] );
queue( buffer[1] );

Then in my main audio thread:

while ( 1 )
{
   if ( buffer[ 0 ].is_done )
   {
      fill( buffer[ 0 ] );
      waveOutWrite( buffer[0] );
   }
   if ( buffer[ 1 ].is_done )
   {
      fill( buffer[ 1 ] );
      waveOutWrite( buffer[ 0 ] );
   }
   sleep( buffer_len/2);
}

You get the gist -- poll for completed buffers and then fill them up on
demand, relying on sleep + poll instead of an event system or callbacks
or a separate thread function.

Brian




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital
self defense, top technical experts, no vendor pitches, unmatched
networking opportunities. Visit www.blackhat.com
_______________________________________________
Gamedevlists-windows mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU5



----------------------------------------------------
Vivendi Universal Games- <<http://www.vugames.com>>:
The information transmitted is intended only for the
person or entity to which it is addressed and may
contain confidential and/or privileged material of
Vivendi Universal Games which is for the exclusive
use of the individual designated above as the
recipient. Any review, retransmission, dissemination
or other use of, or taking of any action in reliance
upon, this information by persons or entities other
than the intended recipient is prohibited. If you
received this in error, please contact immediately
the sender by returning e-mail and delete the
material from any computer. If you are not the
specified recipient, you are hereby notified that
all disclosure, reproduction, distribution or action
taken on the basis of this message is prohibited.


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Gamedevlists-windows mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU5