[Audio] Overloads: Alc.CaptureSamples
Posted Sunday, 31 May, 2009 - 17:06 by the Fiddler| Project: | The Open Toolkit library |
| Version: | 0.9.8 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Inertia |
| Status: | closed (invalid) |
Jump to:
Description
Alc.CaptureSamples is a non-blocking call, which means that the pin on the buffer may be released before the unmanaged code stops accessing the buffer. This is dangerous as the GC may move the buffer at any time.
Comments
#1
How to proceed with this issue? Just comment them out?
Like I've said in another post, I believe the right way to handle pinning for Alc.CaptureSamples is using GCHandle instead of fixed-statements. This is sub-optimal for the GC, but since Alc.CaptureSamples is usually called at 50ms intervals (this is the rate at which OpenAL makes the data available) it is imho preferable to pin it once - for the application's lifetime - using GCHandle, instead of pinning it 20 times per second.
There is also no need to use more than 1 array per recording device. The only usage scenarios that make sense for the captured data are:
#3
So it fits better into "recent activity"
#4
That's a tough question. I think the best solution is to remove those overloads from trunk and mark them as deprecated in 0.9.8.
I'll open a separate issue on buffer management for AudioCapture.
Edit: or maybe not. I've been trying to think of a way to move buffer pinning inside AudioCapture but to no avail. Any ideas?
#5
I don't know how I managed to rename this topic...
#6
I had renamed it to "[Audio] Overloaded: Alc.CaptureSamples" first, deleted the post that made the change, then renamed it again to "[Audio] Overloads: Alc.CaptureSamples" in the hopes nobody would notice. -.-
Idk of any AL.Flush() or AL.Finish() we could use to make them safe. If you have any idea how to accomplish this, there's no problem keeping them.
The Alc.CaptureSamples overloads are so brand new, noone had the chance to use them yet (and you immediately filed this issue that they're not safe). Also the capture extension is something which very very few applications would use anyways. IMHO just nuke them and say sorry if someone has to change a line of code because of it. ;)
#7
It seems we might be reading the specs incorrectly: alcCaptureSamples will not block until the desired sampleCount is met (it is an error to request more samples than available), but it *will* block until the samples are copied from the internal ring-buffer to the specified buffer.
I haven't been able to get these overloads to return different data than the IntPtr version, so I am closing this bug as invalid. If you happen to hit a case where incorrect data is returned, please reopen this bug.