I'm more familiar with openAL, but the process should be similar between the two API's. The process should go something like this:

have 2 buffers (double buffered) for music

decompress the ogg into the first buffer
loop:
use the DMA to feed the buffer to the soundcard (done through directsound?)
while the sound is playing, decompress the ogg into the other buffer
use a callback for when the first buffer is empty to swap buffers
wash, rinse, repeat


I think that directsound may have this process encapsulated in a function already. Look through the SDK documentation at the directsound functions and see if it does.


Cheers,




----------------------------------
Halfway down the trail to hell...

[edited by - scourage on January 6, 2004 7:03:21 AM]

quote:Original post by Scourage

have 2 buffers (double buffered) for music

decompress the ogg into the first buffer
loop:
use the DMA to feed the buffer to the soundcard (done through directsound?)
while the sound is playing, decompress the ogg into the other buffer
use a callback for when the first buffer is empty to swap buffers
wash, rinse, repeat

i wrote a similar system of my own, 2 buffers, both filled, when one is near the end, start the other and stop the current one, then load it with the next ogg chunk

however, i do get some skipping at the time of the flip, any suggestions on how i can fix it?


Cartman''s definition of sexual harrasement:
"When you are trying to have intercourse with a lady friend, and some other guy comes up and tickles your balls from behind"

(watch South Park, it rocks)

Can''t you use Notifications? Make a notification event halfway -1 and at the last byte in the buffer. The notifications then wakeup a WaitOnSingleEvent() function in a thread where you load the data and return and so on and so on.

Very convenient.

Is this approach perhaps illegal with ogg/vorbis? (I have no idea what those things are!

Brian

that is how mine works. using dsound event notifiers, i notified at the end, got skipping and pushed the notifier about 1kb before the end, the skip was minimized, but still exists.

ceasar4,
I don''t have that problem but I use more than one notification event and watch my timing. (In fact I use several notifications.) But in addition you also have to be VERY careful and make sure you initialize the position of the cursor in the buffer such that when you get your notification that your write position is far enough ahead that it does not conflict with the sending of any data. Even with events, the time it takes for your thread to get that event and load the next data buffer is not gauranteed! The good ''ol days of DOS interrupts are gone.

That was an important issue for my application since I had to try to minimize latency; I wanted my send and capture data to be as close to the actual sending and receiving of the audio signal as possible, which meant getting as close to the hardware read (playback) and write (capture) positions as I could get away with.

As I recall what I did was divide my buffer into N sections of ''x'' bytes. Before starting ''->Play()'' I zeroed the buffer and then I loaded my first hunk of data starting about 15 ms from the beginning of the buffer. My write pointer is then shifted about 15ms ahead of the hardware readpointer. I set the current read position to zero and call ->Play(). When the notification is received, I load the x bytes of data, but the load is started at my write pointer which is shifted by 15ms with respect to the notification points. I read somewhere that that time should be safe for all DirectSound systems. It seems to work on those few systems I have tried. Since this signal is a tone-encoded synchronous digital signal, I can''t have any glitches or the timing will be screwed up at the receiver!

I think the current latency limit is to be at least 15 ms ahead of the current read cursor (for playback). If your writing of the data (the Lock() junk) interferes with the reading by the hardware you will get an instance of crap. That also means there is no way to fill the entire buffer every notification (unless the hardware read is exactly the same speed as your hardware write and timed just right); you have to have at least 2 notifications.

Hope this long tedious story is of help in your case. If not, oh well, you got to read about my trials and tribulations.

Brian

sounds to me that you are using a single buffer to do all that, and all that extra monitoring does have a toll on the CPU. but your idea to slightly rewind the ogg file by a couple milliseconds, is great and i will try to incorporate it into my ogg class


Cartman''s definition of sexual harrasement:
"When you are trying to have intercourse with a lady friend, and some other guy comes up and tickles your balls from behind"

(watch South Park, it rocks)