Author Topic: BASS 2.4.13 and WASAPI  (Read 370 times)

SoundMike

  • Posts: 338
BASS 2.4.13 and WASAPI
« on: 24 Jan '18 - 05:36 »
I had been putting off implementing the BASSWASAPI extension so I was pleased to see that as from 2.4.13 there's no need to as WASAPI support is built-in to the main BASS library! As there are still environments in which WASAPI is not available then it would be handy in my program if I could find out if BASS has selected WASAPI or DirectSound. Is there a way to do this? I tried checking BASS_CONFIG_DEV_BUFFER but in a test where I forced DirectSound to be used (on my Win10 machine) by setting the BASS_DEVICE_DSOUND flag in BASS_Init(), BASS_CONFIG_DEV_BUFFER returned 30, the same value it returned when not setting BASS_DEVICE_DSOUND. I was expecting it to return 0 when using BASS_DEVICE_DSOUND.

Ian @ un4seen

  • Administrator
  • Posts: 21017
Re: BASS 2.4.13 and WASAPI
« Reply #1 on: 24 Jan '18 - 13:45 »
The BASS_DEVICE_DSOUND flag will be applied automatically by BASS_Init when WASAPI is unavailable. You can detect when that happens by checking the BASS_INFO "initflags" parameter.

yps

  • Posts: 149
Re: BASS 2.4.13 and WASAPI
« Reply #2 on: 25 Jan '18 - 09:56 »
Another question about WASAPI in BASS 2.4.13 (which is actually cool because you don't have to manually use BASSWASAPI anymore):

From my experience, a very big advantage of WASAPI over DirectSound is that with WASAPI every sound card has its own unique GUID which never changes, even if you switch default devices in Windows or attach/remove USB soundcards; while with DirectSound, devices are addresed by their index, in some order that can change any time the user does any of the things mentioned above.

Can we access the GUIDs, and take advantaged of them, even when using WASAPI through the new unified interface in BASS?

Ian @ un4seen

  • Administrator
  • Posts: 21017
Re: BASS 2.4.13 and WASAPI
« Reply #3 on: 25 Jan '18 - 17:49 »
Are you referring to the endpoint ID? If so, that has actually always been available in the BASS_DEVICEINFO "driver" value on Vista and above, even before the WASAPI support was added.

An undocumented feature that may be of interest, is that the "Device Instance Id" or "Device Instance Path" string (depending on Windows version) is available too. Details on that can be found here:

   www.un4seen.com/forum/?topic=16124

yps

  • Posts: 149
Re: BASS 2.4.13 and WASAPI
« Reply #4 on: 25 Jan '18 - 20:19 »
I'm referring to the "id" member of BASS_WASAPI_DEVICEINFO.

But device Instance ID is actually pretty cool. Thanks for the hint!

Is BASSWASAPI now considered deprecated? Or will it be around for a while?

Guest

  • Guest
Re: BASS 2.4.13 and WASAPI
« Reply #5 on: 25 Jan '18 - 20:55 »
Quote
Is BASSWASAPI now considered deprecated? Or will it be around for a while?
you should tell the question to Microsoft.. LOL


yps

  • Posts: 149
Re: BASS 2.4.13 and WASAPI
« Reply #6 on: 25 Jan '18 - 21:06 »
BASSWASAPI. The BASS add-on. Not the Windows API.

Guest

  • Guest
Re: BASS 2.4.13 and WASAPI
« Reply #7 on: 25 Jan '18 - 21:52 »
BASSWASAPI. The BASS add-on. Not the Windows API.

BASSWASAPI is a wrapper of the Core Audio API from Microsoft.. which used first upto Win7
so why that should deprecated?

if the core not changed on the next Window System then it's works allways.
also again..

Quote
you should tell the question to Microsoft.. LOL


Falcosoft

  • Guest
Re: BASS 2.4.13 and WASAPI
« Reply #8 on: 25 Jan '18 - 22:05 »
BASSWASAPI is a wrapper of the Core Audio API from Microsoft.. which used first upto Win7
so why that should deprecated?

I don't think you understand the context of his question. The situation is from version 2.4.13 the core bass library (bass.dll) also supports WASAPI output.
So I think the question is related to whether the BASSWASAPI extension will be supported in the future or only the core Bass library with its internal WASAPI mode.

SoundMike

  • Posts: 338
Re: BASS 2.4.13 and WASAPI
« Reply #9 on: 26 Jan '18 - 07:27 »
Ian, in an environment where WASAPI is available, is there any reason to provide the user with the option to revert to DirectSound? For example, is there a possibility that there could be a longer latency with WASAPI due to buffering? If there's no reason to give the user the option to revert to DirectSound then I can just use the normal BASS_Init call and allow BASS to select WASAPI if available, else DirectSound.

Falcosoft

  • Guest
Re: BASS 2.4.13 and WASAPI
« Reply #10 on: 26 Jan '18 - 07:56 »
Since in Vista+ Directsound is only a layer above WASAPI lower latency of Directsound in any possible scenario is not likely. But there can be other reasons to give the option to select Directsound output for your users.
E.g. I have noticed that some of the software enhancements of my Realtek HD Audio is not available when Bass uses WASAPI mode. E.g. 'Speaker Fill' does nothing in WASAPI mode so stereo output always only uses the front left/right speakers while in Directsound mode stereo can be extended to 5.1 by Speaker Fill.

Ian @ un4seen

  • Administrator
  • Posts: 21017
Re: BASS 2.4.13 and WASAPI
« Reply #11 on: 26 Jan '18 - 17:49 »
I'm referring to the "id" member of BASS_WASAPI_DEVICEINFO.

OK. That is the device's endpoint ID, so you can indeed find what you want in the BASS_DEVICEINFO "driver" field.

Is BASSWASAPI now considered deprecated? Or will it be around for a while?

BASSWASAPI will still be needed for exclusive mode (BASS itself only uses shared mode).

SoundMike

  • Posts: 338
Re: BASS 2.4.13 and WASAPI
« Reply #12 on: 27 Jan '18 - 02:43 »
Thanks for the advice, Ian and Falcosoft. For my purposes it seems I can just work with the default settings, ie WASAPI if available, with BASS dropping back to DirectSound if it's not.