Circular Buffer using Virtual Memory

Hello,

I'm experimenting with audio decoding and playback using PortAudio at the mo. Initially I found that it isn't a good idea to decode the audio in the same thread as playback (duh :o), so I have split the application into two threads: one decodes the audio and the other copies blocks to PortAudio's buffer on callback.

Each time the playback thread copies decoded audio it signals the decoding thread via an Event. The decoding thread wakes up, decodes another block of audio and goes back to sleep.

Here's where it gets tasty: I don't intend to have a 50+ MB buffer holding the decoded audio, instead my ideal size is a one second buffer. Newly-decoded blocks overwrite blocks that have been sent for playback, thus creating a circular buffer.

I have tried a traditional implementation of a circular buffer, that typically involves one to two memcpy()s, depending on how close it is to the end of the buffer. This works well, but for one reason or another I keep hearing pops and clicks as both threads wrap around. It seems as if playback catches up with decoding too quickly. This would make sense, except that I've temporarily disabled the "decoding" element and am just reading raw samples from file into the buffer.

Reading around, I found out that it is possible to use Windows' virtual memory management to your advantage, effectively mapping the same block of physical memory over and over into consecutive regions of virtual memory. I could have a virtual region the same length as the file, but still only using one second's worth of physical memory. :cool:

This is the code that I devised to do this:-

Code:

---

// nSeconds is the length in seconds of the file, rounded up
hMap = CreateFileMapping(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE | SEC_RESERVE, 0, nSeconds * 327680, NULL); // create a map for the whole range
pSound->pSound = MapViewOfFileEx(hMap, FILE_MAP_WRITE, 0, 0, 0, NULL); // find a virtual address that would accommodate it
UnmapViewOfFile(pSound->pSound); // clear down
CloseHandle(hMap);
hMap = CreateFileMapping(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE | SEC_RESERVE, 0, 327680, NULL); // create a map for just the second-long buffer
for (pSound->pEnd=pSound->pSound;nSeconds>0;nSeconds--)
{
  MapViewOfFileEx(hMap, FILE_MAP_WRITE, 0, 0, 327680, pSound->pEnd); // map the address to the second-long buffer
  pSound->pEnd += 81920; // increment float pointer (327680 bytes)
}

VirtualAlloc(pSound->pSound, 327680, MEM_COMMIT, PAGE_READWRITE); // "bind" the second-long buffer to memory

---

This works brilliantly in the sense that I could dismantle all the pointer arithmetic, etc. and the clicks/pops ceased, but looking at the Task Manager, the memory usage of the process keeps increasing as time goes on. Is this just a count of virtual memory, or have I not done this properly? :confused:

Quote:

---

This works well, but for one reason or another I keep hearing pops and clicks as both threads wrap around.

---

O_o

If this is your problem...

Quote:

---

Reading around, I found out that it is possible to use Windows' virtual memory management to your advantage, effectively mapping the same block of physical memory over and over into consecutive regions of virtual memory.

---

... then that isn't a solution.

I'm cool with you learning the "Windows" "WinAPI", but if your cache, your circular buffer, is already implemented properly changing how the memory allocation mechanism isn't going to help.

Do yourself a favor, create a single, large buffer and attempt to use a cache of a single item, a circular buffer of size one, and see if you still get "pops and clicks".

By the by, I don't use this library, does your decode API automatically create/fix packets or write null samples to an overlarge buffer?

As for the "WinAPI" stuff, I can't help you really as I try to avoid it.

Soma

Quote:

---

Originally Posted by SMurf

Reading around, I found out that it is possible to use Windows' virtual memory management to your advantage, effectively mapping the same block of physical memory over and over into consecutive regions of virtual memory. I could have a virtual region the same length as the file, but still only using one second's worth of physical memory. :cool:

This works brilliantly in the sense that I could dismantle all the pointer arithmetic, etc. and the clicks/pops ceased, but looking at the Task Manager, the memory usage of the process keeps increasing as time goes on. Is this just a count of virtual memory, or have I not done this properly? :confused:

---

You don't have control over what virtual memory is mapped to what physical memory (that's the kernel's job)!
VirtualAlloc is not going to help you in the slightest in this regard.
If you need a circular buffer, then there are plenty of already working solutions which might be a good idea to test with, I think.

Aiiieee! I think I misunderstood what was meant by the example given on Wikipedia for this. In the above I thought that I could just map the same region n times to loop as long as required (not possible).
In fact, the key is thus:-

Quote:

---

Originally Posted by SMurf

I have tried a traditional implementation of a circular buffer, that typically involves one to two memcpy()s, depending on how close it is to the end of the buffer.

---

Using this technique correctly is supposed to make it possible to read/write using exactly one memcpy() call. You map the same region twice and perform the same pointer arithmetic as if it were a single buffer, but don't need to worry about reading/writing past the end any more.

This kind of stuff never works when I'm sober. :(

You can "walk" the memory with VirtualAlloc, but honestly, it's probably slower than just doing two memcpys.

Well after that brain fart and shaking my fist in the air at whoever wrote the Ogg Vorbis library API, I finally have clean, fast and low memory-using streaming audio playback. :cool: