map buffer

I personally think, that GL3 style of map buffer on alBuffer and
my idea of dataBuffer do the same thing a non copy buffer data setting,
but map buffer also provides general way to update data on already created
buffer, whereas the sole purposes of dataBuffer is to initialize alBuffer.

I actually think, that map buffer should be used for my dataBuffer, because
it will make dataBuffer as thread-safe as possible.

As of now you can access data in my dataBuffer with
	ALVoid *ALDataBufferGetData(ALdataBuffer buffer)

which means, that multiple threads can work with the data and more importantly,
there is no grantee, that the work with the data is done by the time you are
giving the dataBuffer to the alBuffer.

therefore replacing:
	ALVoid *ALDataBufferGetData(ALdataBuffer buffer);
 	ALsizei alDataBufferGetSize(const ALdataBuffer buffer);

with:

	ALVoid *ALDataBufferMapData(ALdataBuffer buffer, ALsizei *size)
	// size return size of the writable data

	void ALDataBufferUnmapData(ALdataBuffer buffer)

this will make it as thread safe as possible, because ALDataBufferMapData
will have to grantee that it's the only active mapping (most likely with
spin-lock).

alBufferDataFromBuffer call will use ALDataBufferMapData
during the buffer processing and dataBuffer will have its size set to 0 and
data pointer returned by ALDataBufferMapData to NULL before unmapping, or
destroying the dataBuffer all together, I personally tend to think, that
destruction of the buffer itself is more desirable, because GiveData clearly
states, that you will no longer hold the dataBuffer after its over and users
will not have to make alDataBufferDelete() call, but thats up to debate.


So imho dataBuffer with map/unmap is very robust way of initializing the
alBuffer, whereas map/unmap directly on alBuffer will have either stop the
buffer from playing or fail if the buffer is in use or count on users, to
don't modify the currently accessed memory, which are all problems caused by
the fact, that it is not a alBuffer data initialization method, but a method to
directly manipulate alBuffer internal data, which will always make it tempting
to misuse it for streaming.

Whereas streaming use of dataBuffer is absolutely safe, eg. if user for some
reason wants to have a big 200mb buffer instead of using classical
alSourceQueueBuffers and does not really care when the sound is ready for
playing. It is possible to slowly write the data into the dataBuffer via
map/unmap and some global offset, that is held by the app and once the
dataBuffer is ready give it to alBuffer.


I personally don't really see why would anyone wanted to do this, because play
as soon as possible is usually what you want and for that very safe
alSourceQueueBuffers or less safe alBufferSubDataSOFT (if I understand it
correctly app has to make sure it does write into memory used by alSources).




extra thoughts:


map/unmap does not prohibit from multithreaded data loading:

	ptr = ALDataBufferMapData(...)
	// give N threads N data segment from the ptr
	// join threads
	ALDataBufferUnmapData(...)

I am not sure what uses this has.


dataBUffer with map/unmap can actually be used for memory transform to
other memory than RAM, this would require some device flags for
alDataBufferCreate and I don't see any real use for it as of now.



I looked up the mesa implementation of openCL and they also just return new
object in clCreateBuffer.

https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/clover/api/memory.cpp