From chris.kcat at gmail.com Fri Jan 13 03:03:43 2017 From: chris.kcat at gmail.com (Chris Robinson) Date: Fri, 13 Jan 2017 00:03:43 -0800 Subject: [openal] alsoft-config updating to Qt5 Message-ID: <2c18b6a6-7602-4ae2-68be-948cdbc8d22a@gmail.com> Hi guys. Just so you're aware, mostly packagers and people who build it themselves, OpenAL Soft's alsoft-config utility will start using Qt5 by default. If the Qt5 dev packages aren't found, it will automatically try to use Qt4.8. Additionally, there's a cmake option to use Qt4.8 even if Qt5 is available (ALSOFT_NO_QT5). Please let me know if this causes any problems. Thanks! From christian.hoene at symonics.com Sun Jan 22 07:53:27 2017 From: christian.hoene at symonics.com (Christian Hoene) Date: Sun, 22 Jan 2017 13:53:27 +0100 Subject: [openal] Support SOFA in OpenAL? In-Reply-To: <1069526115.209198.1482054989002.JavaMail.open-xchange@app08.ox.hosteurope.de> References: <026f01d25865$3217fde0$9647f9a0$@symonics.com> <49279070-05ff-deec-8ecc-420f556d317e@gmail.com> <1069526115.209198.1482054989002.JavaMail.open-xchange@app08.ox.hosteurope.de> Message-ID: <004301d274ae$86c6c230$94544690$@symonics.com> Hi Chris, the new libmysofa version 0.4 has been released. It includes the normalization, efficient filter lookup, and filter interpolation. https://github.com/choene/libmysofa With the new version of libmysofa, it would be even easier to support SOFA in OpenAL-Soft, because you do not need the netcdf libraries, you do not have to implement new HRTF lookup and interpolation algorithm, and a you not new storage format for OpenAL. The more I think, the less sense it makes to continue the approach I have started in https://github.com/choene/openal-soft (with the vanilla NETCDF and SOFA libraries and extending OpenAL to support SOFA), but to use libmysofa everytime OpenAL-Soft needs a new set of FIR filters... With best regards, Christian Hoene -----Ursprüngliche Nachricht----- Von: Christian Hoene [mailto:christian.hoene at symonics.com] Gesendet: Sonntag, 18. Dezember 2016 10:56 An: Chris Robinson Betreff: Re: Support SOFA in OpenAL? > I'm not sure. The idea of makehrtf is to ensure the HRTF data is in a > convenient layout that's both small and quick to load, and ensures the > data is laid out in a way that OpenAL Soft can use it. As far as I can > tell, SOFA files have quite a few parameters, and data can be > expressed in a few different ways, so would require some processing > and a bunch of verification just to load one for the device. Having > makehrtf convert SOFA files to OpenAL Soft's format gives an > opportunity to alert the user that a dataset won't work, to provide > options for how to use it, or to do the more heavy processing once so it loads quicker at run-time. Yes, the makehrtf format is more compact and faster to read than SOFA. My main intention is to enable OpenAL do have the HRTF even at run-time. > > > 2) Does somebody still need the SOFA reader based on NetCDF and HDF5 > > in makehrtf? Shall this be continued? > > Again, I'm not sure. Considering SOFA files use the NetCDF format, > libnetcdf/libhdf5 would be the appropriate way to read them. But > having a small, self-contained C library to load SOFA files would be > ideal. It depends on how thoroughly a C library handles all the format > features and quirks possible of SOFA files (not just existing ones, > but most or all of what the standard allows for), and how cleanly it > deals with the unexpected. We are working closely together with the HDF group to ensure. Soon, we will have a first common blog entry about libmysofa. You can compare libhdf5 and libmysofa with Adobe PDFs. libhdf5 is Acrobat and libmysofa is Acroread. > > > 3) May I kick out the proprietary file HRTF format of OpenAL? Who > > will need this anyhow? > > As much as I'd like to drop OpenAL Soft's mhr format and just load > SOFA files directly, I think the preprocessing is still necessary to > ensure correctness, load quickly, and be alterable for the users' > needs (resampling a 44.1khz IR to 48khz or vice-versa, changing the > minimum-phase cutoff length, etc). > > I think a middle-ground would be to better integrate makehrtf with > alsoft-config. So for example, in the GUI you would switch to the HRTF > tab and click an Import Dataset... button, which brings up a dialog to > select an input file (.def or .sofa) and set various options for it > (sample rate, diffuse-field equalization, etc), then proceeding would > invoke makehrtf and save the output in the appropriate user directory > for OpenAL Soft to automatically see it. This makes sense. Then you can change HRTF dynamically... Expect to get many small patched in the next weeks ;-) Best Christian From chris.kcat at gmail.com Sun Jan 22 13:06:22 2017 From: chris.kcat at gmail.com (Chris Robinson) Date: Sun, 22 Jan 2017 10:06:22 -0800 Subject: [openal] Support SOFA in OpenAL? In-Reply-To: <004301d274ae$86c6c230$94544690$@symonics.com> References: <026f01d25865$3217fde0$9647f9a0$@symonics.com> <49279070-05ff-deec-8ecc-420f556d317e@gmail.com> <1069526115.209198.1482054989002.JavaMail.open-xchange@app08.ox.hosteurope.de> <004301d274ae$86c6c230$94544690$@symonics.com> Message-ID: On 01/22/2017 04:53 AM, Christian Hoene wrote: > Hi Chris, > > the new libmysofa version 0.4 has been released. It includes the > normalization, efficient filter lookup, and filter interpolation. > https://github.com/choene/libmysofa > > With the new version of libmysofa, it would be even easier to support > SOFA in OpenAL-Soft, because you do not need the netcdf libraries, > you do not have to implement new HRTF lookup and interpolation > algorithm, and a you not new storage format for OpenAL. > > The more I think, the less sense it makes to continue the approach I > have started in https://github.com/choene/openal-soft (with the > vanilla NETCDF and SOFA libraries and extending OpenAL to support > SOFA), but to use libmysofa everytime OpenAL-Soft needs a new set of > FIR filters... I'm not keen on using libmysofa to handle the HRTFs in the OpenAL Soft library itself. OpenAL Soft handles more than just SOFA files, and the SOFA storage layout doesn't seem to be designed for efficient run-time access (relatively speaking). I feel OpenAL Soft's needs and internal design for handling HRTF is a bit too specialized to have a simplified loader do the work, and would rather just use it in the makehrtf utility to get at the information stored in the file. From chris.kcat at gmail.com Sun Jan 22 13:48:19 2017 From: chris.kcat at gmail.com (Chris Robinson) Date: Sun, 22 Jan 2017 10:48:19 -0800 Subject: [openal] Support SOFA in OpenAL? In-Reply-To: References: <026f01d25865$3217fde0$9647f9a0$@symonics.com> <49279070-05ff-deec-8ecc-420f556d317e@gmail.com> <1069526115.209198.1482054989002.JavaMail.open-xchange@app08.ox.hosteurope.de> <004301d274ae$86c6c230$94544690$@symonics.com> Message-ID: <5a3aa0ef-7c61-986b-ad61-8cefdb9a97f5@gmail.com> On 01/22/2017 10:06 AM, Chris Robinson wrote: > I'm not keen on using libmysofa to handle the HRTFs in the OpenAL Soft > library itself. OpenAL Soft handles more than just SOFA files, and the > SOFA storage layout doesn't seem to be designed for efficient run-time > access (relatively speaking). I feel OpenAL Soft's needs and internal > design for handling HRTF is a bit too specialized to have a simplified > loader do the work, and would rather just use it in the makehrtf utility > to get at the information stored in the file. I noticed too that there's a requirement for libresample now, which is running into the dependency problems that made libsofa not very attractive in the first place. It may be better to just look at what the sofalizer VLC plugin does to load sofa files directly with netcdf in C. From christian.hoene at symonics.com Sun Jan 22 14:11:17 2017 From: christian.hoene at symonics.com (Christian Hoene) Date: Sun, 22 Jan 2017 20:11:17 +0100 Subject: [openal] Support SOFA in OpenAL? In-Reply-To: References: <026f01d25865$3217fde0$9647f9a0$@symonics.com> <49279070-05ff-deec-8ecc-420f556d317e@gmail.com> <1069526115.209198.1482054989002.JavaMail.open-xchange@app08.ox.hosteurope.de> <004301d274ae$86c6c230$94544690$@symonics.com> Message-ID: <000001d274e3$4fbfe520$ef3faf60$@symonics.com> Hi Chris, no problem at all. It is your project. Based on your wishes, I made a pull request for the vanilla SOFA reader, which extends makehrtf. In the core, only a bare minimal number of changes have been made. With best regards, Christian Hoene -----Ursprüngliche Nachricht----- Von: Chris Robinson [mailto:chris.kcat at gmail.com] Gesendet: Sonntag, 22. Januar 2017 19:06 An: 'openal mailing list' Cc: Christian Hoene Betreff: Re: AW: Support SOFA in OpenAL? On 01/22/2017 04:53 AM, Christian Hoene wrote: > Hi Chris, > > the new libmysofa version 0.4 has been released. It includes the > normalization, efficient filter lookup, and filter interpolation. > https://github.com/choene/libmysofa > > With the new version of libmysofa, it would be even easier to support > SOFA in OpenAL-Soft, because you do not need the netcdf libraries, you > do not have to implement new HRTF lookup and interpolation algorithm, > and a you not new storage format for OpenAL. > > The more I think, the less sense it makes to continue the approach I > have started in https://github.com/choene/openal-soft (with the > vanilla NETCDF and SOFA libraries and extending OpenAL to support > SOFA), but to use libmysofa everytime OpenAL-Soft needs a new set of > FIR filters... I'm not keen on using libmysofa to handle the HRTFs in the OpenAL Soft library itself. OpenAL Soft handles more than just SOFA files, and the SOFA storage layout doesn't seem to be designed for efficient run-time access (relatively speaking). I feel OpenAL Soft's needs and internal design for handling HRTF is a bit too specialized to have a simplified loader do the work, and would rather just use it in the makehrtf utility to get at the information stored in the file. From christian.hoene at symonics.com Sun Jan 22 14:13:03 2017 From: christian.hoene at symonics.com (Christian Hoene) Date: Sun, 22 Jan 2017 20:13:03 +0100 Subject: [openal] Support SOFA in OpenAL? In-Reply-To: <5a3aa0ef-7c61-986b-ad61-8cefdb9a97f5@gmail.com> References: <026f01d25865$3217fde0$9647f9a0$@symonics.com> <49279070-05ff-deec-8ecc-420f556d317e@gmail.com> <1069526115.209198.1482054989002.JavaMail.open-xchange@app08.ox.hosteurope.de> <004301d274ae$86c6c230$94544690$@symonics.com> <5a3aa0ef-7c61-986b-ad61-8cefdb9a97f5@gmail.com> Message-ID: <000201d274e3$8e2010b0$aa603210$@symonics.com> Hi Chris, > I noticed too that there's a requirement for libresample now, which is running into the dependency problems that made libsofa not very attractive in the first place. I am not religious on this topic. Instead of the libresample, which other library would you recommend? Or shall I do a copy and paste from the speex code? Best, Christian From chris.kcat at gmail.com Sun Jan 22 14:27:54 2017 From: chris.kcat at gmail.com (Chris Robinson) Date: Sun, 22 Jan 2017 11:27:54 -0800 Subject: [openal] Support SOFA in OpenAL? In-Reply-To: <000201d274e3$8e2010b0$aa603210$@symonics.com> References: <026f01d25865$3217fde0$9647f9a0$@symonics.com> <49279070-05ff-deec-8ecc-420f556d317e@gmail.com> <1069526115.209198.1482054989002.JavaMail.open-xchange@app08.ox.hosteurope.de> <004301d274ae$86c6c230$94544690$@symonics.com> <5a3aa0ef-7c61-986b-ad61-8cefdb9a97f5@gmail.com> <000201d274e3$8e2010b0$aa603210$@symonics.com> Message-ID: <206ca4e8-cc8f-f47c-55b3-e5598105b1b1@gmail.com> On 01/22/2017 11:13 AM, Christian Hoene wrote: > Hi Chris, > >> I noticed too that there's a requirement for libresample now, which >> is running into the dependency problems that made libsofa not very >> attractive in the first place. > > I am not religious on this topic. Instead of the libresample, which > other library would you recommend? Or shall I do a copy and paste > from the speex code? For OpenAL Soft's purposes, it doesn't need libmysofa to do any resampling at all. The makehrtf utility has its own high-quality resampler. From metalcaedes at gmail.com Mon Jan 23 20:49:03 2017 From: metalcaedes at gmail.com (Daniel Gibson) Date: Tue, 24 Jan 2017 02:49:03 +0100 Subject: [openal] Support SOFA in OpenAL? In-Reply-To: <000201d274e3$8e2010b0$aa603210$@symonics.com> References: <026f01d25865$3217fde0$9647f9a0$@symonics.com> <49279070-05ff-deec-8ecc-420f556d317e@gmail.com> <1069526115.209198.1482054989002.JavaMail.open-xchange@app08.ox.hosteurope.de> <004301d274ae$86c6c230$94544690$@symonics.com> <5a3aa0ef-7c61-986b-ad61-8cefdb9a97f5@gmail.com> <000201d274e3$8e2010b0$aa603210$@symonics.com> Message-ID: <8fd183a6-f98f-f22d-9ad8-765db5c51811@gmail.com> Hi, libSDL2 currently gets new resampling code written from scratch, it's under zlib license. See https://hg.libsdl.org/SDL/file/tip/src/audio/SDL_audiocvt.c No idea if this is better than the speex code, but it might be worth a look if you want to reuse existing resampling code. Cheers, Daniel On 22.01.2017 20:13, Christian Hoene wrote: > Hi Chris, > >> I noticed too that there's a requirement for libresample now, which is running into the dependency problems that made libsofa not very attractive in the first place. > > I am not religious on this topic. Instead of the libresample, which other library would you recommend? Or shall I do a copy and paste from the speex code? > > Best, > > Christian > > > _______________________________________________ > openal mailing list > openal at openal.org > http://openal.org/mailman/listinfo/openal > From zakalawe at mac.com Sat Jan 28 11:45:50 2017 From: zakalawe at mac.com (James Turner) Date: Sat, 28 Jan 2017 16:45:50 +0000 Subject: [openal] Building OpenAL-Soft 1.17.2 on Windows Message-ID: <98AA2FF0-8122-4149-AF7E-A0D2831AE096@mac.com> Hi, I’m trying to build OpenAL-Soft 1.17.2 in standard configuration on windows 10 + VS2015. CMake informs me that the DirectSound backend is missing because DSound isn’t found, but all googling I have done suggests that the DirectX SDk was rolled into the main Windows SDK long ago, which I think I have as part of my VS2015 install. I couldn’t find any FAQ or Windows-specific build instructions about this, can someone explain the correct CMake setting or installable so DSound is found? Kind regards, James From chris.kcat at gmail.com Sat Jan 28 16:43:30 2017 From: chris.kcat at gmail.com (Chris Robinson) Date: Sat, 28 Jan 2017 13:43:30 -0800 Subject: [openal] Building OpenAL-Soft 1.17.2 on Windows In-Reply-To: <98AA2FF0-8122-4149-AF7E-A0D2831AE096@mac.com> References: <98AA2FF0-8122-4149-AF7E-A0D2831AE096@mac.com> Message-ID: <2ec49cc4-58d4-1780-c19f-79e0a883ede2@gmail.com> On 01/28/2017 08:45 AM, James Turner wrote: > I’m trying to build OpenAL-Soft 1.17.2 in standard configuration on > windows 10 + VS2015. CMake informs me that the DirectSound backend is > missing because DSound isn’t found, but all googling I have done > suggests that the DirectX SDk was rolled into the main Windows SDK > long ago, which I think I have as part of my VS2015 install. Hi. Are the dsound headers and import libs present on the system? Where are dsound.h and dsound.lib for you? If worse comes to worse, you can use cmake-gui or whatever to manually set the DSOUND_INCLUDE_DIR and DSOUND_LIBRARY variables to the appropriate values (the path where dsound.h is, and the full path+filename for dsound.lib, respectively). Alternatively, you should be able to use the prebuilt binaries: http://openal-soft.org/openal-binaries/openal-soft-1.17.2-bin.zip which has OpenAL Soft's headers, import libs, and DLLs already made and with proper support for the various Windows audio backends. From zakalawe at mac.com Sat Jan 28 17:44:39 2017 From: zakalawe at mac.com (James Turner) Date: Sat, 28 Jan 2017 22:44:39 +0000 Subject: [openal] Building OpenAL-Soft 1.17.2 on Windows In-Reply-To: <2ec49cc4-58d4-1780-c19f-79e0a883ede2@gmail.com> References: <98AA2FF0-8122-4149-AF7E-A0D2831AE096@mac.com> <2ec49cc4-58d4-1780-c19f-79e0a883ede2@gmail.com> Message-ID: <5830D56D-5257-4B6E-A372-B6704AF2986B@mac.com> > On 28 Jan 2017, at 21:43, Chris Robinson wrote: > > Are the dsound headers and import libs present on the system? Where are dsound.h and dsound.lib for you? That’s exactly the question I am seeking the answer to - the information I can find on MSDN suggests they should be, but I can’t find them, but I also can’t find any docs (in OpenAL or otherwise) on the recommended way to get the header / import libs, since DirectX was rolled into the Windows SDK. Kind regards, James From neolit123 at gmail.com Sat Jan 28 18:23:12 2017 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Sun, 29 Jan 2017 01:23:12 +0200 Subject: [openal] Building OpenAL-Soft 1.17.2 on Windows In-Reply-To: <5830D56D-5257-4B6E-A372-B6704AF2986B@mac.com> References: <98AA2FF0-8122-4149-AF7E-A0D2831AE096@mac.com> <2ec49cc4-58d4-1780-c19f-79e0a883ede2@gmail.com> <5830D56D-5257-4B6E-A372-B6704AF2986B@mac.com> Message-ID: On 29 January 2017 at 00:44, James Turner wrote: > >> On 28 Jan 2017, at 21:43, Chris Robinson wrote: >> >> Are the dsound headers and import libs present on the system? Where are dsound.h and dsound.lib for you? > > That’s exactly the question I am seeking the answer to - the information I can find on MSDN suggests they should be, but I can’t find them, but I also can’t find any docs (in OpenAL or otherwise) on the recommended way to get the header / import libs, since DirectX was rolled into the Windows SDK. > you should install the Windows SDK from the setup tool. once you have that there should be something like: :\\Windows Kits\\Include\\um\DSound.h :\\Windows Kits\\Lib\\um\\DSound.lib ..but i haven't tried that on VS2015. i could also try sending a message to Windows support to see if they respond. lubomir -- From neolit123 at gmail.com Sat Jan 28 18:24:00 2017 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Sun, 29 Jan 2017 01:24:00 +0200 Subject: [openal] Building OpenAL-Soft 1.17.2 on Windows In-Reply-To: References: <98AA2FF0-8122-4149-AF7E-A0D2831AE096@mac.com> <2ec49cc4-58d4-1780-c19f-79e0a883ede2@gmail.com> <5830D56D-5257-4B6E-A372-B6704AF2986B@mac.com> Message-ID: On 29 January 2017 at 01:23, Lubomir I. Ivanov wrote: > > ..but i haven't tried that on VS2015. i could also try sending a > message to Windows support to see if they respond. > *you could also try lubomir --