I noticed a behavioural difference between mojoal and macos's openal, and I think it suggests a bug.

Basically you can delete buffers while they are still attached to a source. In mojoal, you don't get an error on delete and when you attach new buffers to the source to play a new sound, you get a brief blip of the previously buffered audio.

In comparison to macos's openal: when you attempt to delete a buffer that is still attached, you will get an "Invalid Operation" error.

Attached is source for testing this bug. Create two different raw audio files called tone_880.raw and tone_440.raw (different so you can hear the previous buffer play a bit), and comment/uncomment out #define AL_CLEAR_BUFFER_ON_STOP to trigger the bug.

openal_test.cpp.tar.gz

Tested using mojoal 8af8cd366257e3b9d734f635f7d17d67fc4d48f7

Hello. I'm not an expert in OpenAL, but using your library I found that calling alGetSourcef with AL_SEC_OFFSET returns only second-precise values, although according to specs it should be supporting fractional values too.

It looks like this small change is enough to fix it.

PS. _alGetSourceiv already converting the result value to int here, so that should stay correct: https://github.com/icculus/mojoAL/blob/44bb6799215238986d12ffa1d85ee49f24a2ccad/mojoal.c#L3742

Hello,

This implements ALC_FREQUENCY in alcGetIntegerv so that user can do:

ALCint sampleRate = -1;
alcGetIntegerv(device, ALC_FREQUENCY, 1, &sampleRate);

I would have done the same for ALC_REFRESH and ALC_SYNC but they are not actually implemented yet (L2119 "use these variables at some point")

Please let me know if anything is incorrect or missing.

Best

Hi,

I am trying to figure out how to set to use a specific audio driver and how to force automatic audio driver selection.

The problem is SDL_AudioInit is not ref counted, so I can't pre-open it and let MojoAL use the driver I set simply because this will cause a failure. See https://github.com/libsdl-org/SDL/issues/5841

Hello.

According to the OpenAL specs found here, documentation for AL_SEC_OFFSET (page 39) sais:

The position is relative to the beginning of all the queued buffers for the source, and any queued buffers traversed by a set call will be marked as processed.

At the same time mojoAL resets the source offset after each processed buffer: https://github.com/icculus/mojoAL/blob/42035035b4e5debb6fe30e475683da2c30e51326/mojoal.c#L1455

Is that a mistake?

This is similar to #9 - when calling alSourcei(source, AL_SAMPLE_OFFSET, value), the code tries to access a field of src->buffer when src->buffer is null: https://github.com/icculus/mojoAL/blob/main/mojoal.c#L4238

There is a codepath which bails early if it knows the source is streaming, but in my case the source's type is AL_UNDETERMINED at that point.

Side note: my source is in the AL_UNDETERMINED state because it unexpectedly hadn't queued any buffers, because of a weird chain of events leading back to alGetSourceiv(source, AL_BUFFERS_QUEUED, ...) returning the wrong value: https://github.com/icculus/mojoAL/blob/main/mojoal.c#L3976-L3977

Two small things: The first commit fixes building with VS2008, which needs mojoal.c to be compiled in C++ mode. So no implicit void* -> any* casts. For the include location change in the 2nd commit refer to https://github.com/AquariaOSE/Aquaria/pull/78#issuecomment-1067494664 Imho, it's also easier for users to just plop the two .h files into some include dir rather than require them to be available under some AL/-subdir...

It's possible to experience a null-pointer exception when trying to retrieve some of the Source properties, such as AL_SEC_OFFSET, and similar, from the Source that has no buffers attached.

As seen here: https://github.com/icculus/mojoAL/blob/main/mojoal.c#L4211 in a non-streaming case mojoAl accesses a buffer in order to find out offset, but does not test if the buffer pointer is valid.

There is an EFX extension for lowpass

https://github.com/kcat/openal-soft/blob/master/include/AL/efx.h

There are extensions for reverb and other extensions that are quite complex, so not sure about following efx extensions, but at least having some way to do a lowpass filter would be nice.

In source_get_offset() , when the source's type is AL_STREAMING, the mojoAL is summing up all the queued and processed buffers lengths to the current buffer's offset (as per OpenAL's specs):

https://github.com/icculus/mojoAL/blob/102126d3ed3a979728c4dde170bf242ad9d9daa6/mojoal.c#L4205-L4213

As may be seen from the code, this is done simply by multiplying the current buffer's len by the number of processed buffers (buffer_queue_processed.num_items); this assumes that all the buffers have the same length.

This however may not be the case. For instance, in the practical case I had, I've been looping a sound file, and the ending piece of much smaller size could be followed by a larger buffer with data from another beginning. In such case the reported offset was larger than expected, as the already processed smaller piece was assumed to be as large as the currently playing one.

Overall I have not found any mention that the buffers must all be of same size when queued into the source, neither in documentation nor the code. Could be I'm missing a rule here? One comment in mojoAL even states: you can legally queue or set a NULL buffer. assuming it also allows for the 0 length buffer to be queued.

I suppose, that if if having varied buffers is legal, then fixing this may be a matter of tracking a processed length, which is added to when another buffer is processed, and subtracted from when a processed buffer is unqueued.

Since recently there have been a discussion about possibly having a stereo panning extension, I thought to ask if it's theoretically acceptable to have a "playback speed" extension? I mean the effect which can be achieved by resampling with higher or lower rate (frequency).

It is of course possible to do this before passing sound data into openal, but with data buffering this results in delayed effect whenever the speed changes (also requires to do extra calculations externally).

Attempt to fix #12

This is probably wrong somewhere and incorrect. Probably the most useful thing is the example.

I copied the testposition example to create a testpanning example with a red rectangle, moving the red rectangle to right or left modifies the panning to either right or left.

Here's a cool song that is stereo: https://opengameart.org/content/love-song-instrumental

Hi,

We have been looking into panning sounds. In OpenAL, it looks like it's only possible to do so using mono sounds.

For stereo sounds, it seems there's an alternative way discussed here : https://github.com/kcat/openal-soft/issues/194

But we had some trouble actually following the suggested workaround when using MojoAL. This is discussed a bit here: https://github.com/adventuregamestudio/ags/issues/1637

Would an extension to provide a way to do so in MonoAL be acceptable?

In our program we calculate full playback offset by adding number of samples from every processed buffer. We calculate samples as buffer_samples = (buffer_size * 8) / (buffer_bits * buffer_channels); where buffer values are retrieved using alGetBufferi with AL_SIZE, AL_BITS and AL_CHANNELS respectively.

Recently I've met an issue where this resulted in a wrong number of samples, and found out that this is because mojoAL internally stores samples as float32 in the generated buffer. If we pass a 16-bit sound data into alBufferData (AL_FORMAT_STEREO16 / AL_FORMAT_MONO16), Buffer still reports original input bitness as 16, but at the same time it has samples stores as 32-bit, therefore less samples fit into the same buffer size. This makes it impossible to calculate number samples correctly without "secret knowledge" about mojoAL's implementation, where we have to always use 32 as "buffer bits".

I must admit that I'm not very experienced with OpenAL yet, so still unsure whether this is a valid bug, or we are using a method we are not supposed to.