[openal] OpenAL Soft 1.19.0 released!

[Ian Reed]

"decrease or increase the source's pitch by the same relative amount 
(converting to/from semitones)"

Unfortunately I don't know how to convert to/from semitones.
That could be a great pair of functions in the low level API.

I just adjust the pitch value on the OpenAL source, which only adjusts 
frequency, affecting the speed/length.
It would be nice if OpenAL provided a way to affect the pitch on the 
direct sound.

I'm using a C# wrapper, and it actually does call the attribute pitch, 
though it also affects speed/length:
enum ALSourcef {
... Pitch = 4099 ...
}

Thanks for the answers to my other questions.

So the mhr files are built into the dlls now right?
The last version I used had them as separate files that needed to be 
referenced on disk.

Not sure why, but when I hit reply to this message my email client 
(Thunderbird) only replies to you directly, not to the email list.
Not sure if that is a mailing list setting or a problem with my email 
client, but I assume it is preferred to have responses always go to the 
list by default.


On 9/7/2018 1:09 PM, Chris Robinson wrote:
> On 09/07/2018 08:51 AM, Ian Reed wrote:
>> Pretty awesome! Thanks for your hard work on this.
>>
>> I see you added pitch and frequency shifting for EFX.
>> Will that shift pitch for the direct sound, or only reverb?
>
> It only shifts the send path the effect is connected to, not the 
> direct sound. It also unfortunately only works in mono currently.
>
>> I can adjust the pitch of a source without EFX, but that just alters 
>> the frequency without preserving the duration.
>> Does the new pitch shifting effect retain the original duration of 
>> the sound?
>
> Yes, it just raises and lowers the pitch without changing the speed or 
> length of the sound. You can actually increase or decrease the pitch 
> shifter's pitch by some amount, decrease or increase the source's 
> pitch by the same relative amount (converting to/from semitones), and 
> the source will play at a different speed while maintaining the 
> original pitch.
>
>> With your discerning ear, how does the 24-bit dual-ear HRTF data set 
>> compare with the data set OpenAL Soft used in the past?
>> Any thoughts on how it compares with the HRTF in Google Resonance, 
>> Oculus, or SteamAudio?
>> What does "dual-ear" mean in this context?
>
> The difference with the new 24-bit data set should be rather minor. 
> The original source data is 16-bit so this should only really help 
> with avoiding yet another layer of 16-bit dither noise in the mix. 
> However, with a higher quality HRTF data source, it would help avoid 
> audible quantization noise.
>
> I can't really say how it compares to the others, since it's highly 
> dependent on both the data set, and how the data set "fits" to the 
> person listening (a given data set may sound really good for one 
> person, and not so good for another). The default set OpenAL Soft 
> includes possibly isn't the best, but it should be fairly good for 
> most people.
>
> "Dual-ear" means the left and right ear responses can be different, 
> instead of being perfect mirrors of each other. Though I suppose 
> "side" may be more accurate terminology than "ear". Since the human 
> head isn't perfectly symmetrical, the left and right responses 
> shouldn't be exactly the same, and that allows data sets to have 
> slight variations.
>
> I should note that the default data set with OpenAL Soft isn't 
> dual-ear. The source was only single-ear (or really, two sets of 
> single-ear; one for large pinnae, one for small).
>
>> Downloading the Windows binaries, I see that there are 3 HRTF def 
>> files, with CIAIR.def being the largest.
>> Which is best to use, and where do I need to place the file?
>
> The HRTF def files are for the makehrtf utility, which can create 
> external HRTF data sets for OpenAL Soft (mhr files). The CIAIR.def 
> file would be used if you have the original CIAIR data set source, and 
> want to make mhr files from them. You don't need to be concerned with 
> them if you're not creating mhr files.
>
>> When I run openal-info32.exe I see:
>> Max auxiliary sends: 2
>> Didn't that used to be 4?
>
> Yes, I realized the EFX spec actually says the default should be 2. 
> You need to request more through alcCreateContext's attribute list if 
> you want more. It makes more sense this way, since an app that doesn't 
> know about EFX (or is only expecting simple effect processing) isn't 
> likely to explicitly request auxiliary sends, so it doesn't make sense 
> to give more than necessary and waste processing time with unused 
> sends (each send does incur a per-source cost, so it shouldn't be 
> higher than you need).
>
>> If you moved away from LGPL, what license would you use?
>
> That's still an open question. Ideally it'd be something that 
> encourages reciprocating back any changes, but doesn't require it in 
> cases where NDAs and stuff may apply. Same for keeping the library 
> open and/or replaceable, encouraging it but not requiring where it 
> wouldn't be possible.
>
> I may just go with something simple like MIT or BSD, but I'd like to 
> see what other options are available.