Topic: BASS_CONFIG_DEV_DEFAULT for input devices

[saga]

BASS_CONFIG_DEV_DEFAULT is very handy when having to work with multiple audio devices, and it would be great to have a similar option for input devices. Is there a particular reason why it's only available for output devices, or could another option be added to have a default input device as well?

[Ian @ un4seen]

I'll check something can be arranged for the next BASS release.

[saga]

Now that BASS_CONFIG_DEV_DEFAULT is enabled by default, would it be possible to look into this again?

[Ian @ un4seen]

Oops, I forgot about this. It'll have to be the next version now

The main issue will be handling default device changes mid-recording, eg. if the new device has a different sample format than the old one. BASS doesn't currently allow recording with more channels than the device has (except mono to stereo), which would be a problem if you happened to be recording 4 channels from a device and then switched to another device with only 2 channels.

I suppose BASS could simply end a recording if the sample format (rate or channel count) does change between devices, which is what currently happens anyway when a device's format changes mid-recording. Would that work for you?

[saga]

I think that would be fine (assuming this would trigger a BASS_SYNC_DEV_FORMAT). Most of the time the recording format would probably stay the same anyway in our use case (we currently only record in mono), so as long as the recording continues to run in the general case (when no format change happens), it should work.

Edit: I don't think I ever manually tested enforced device format changes, but now I did by changing the format of a recording device in the advanced settings in the Windows control panel from 48000 Hz to 44100 Hz. Reading the manual, I thought this should trigger a BASS_SYNC_DEV_FORMAT callback, but our BASS_SYNC_DEV_FAIL callback is invoked instead. Is this intentional?

[Ian @ un4seen]

Yeah, a device format change will currently end any recordings on the device and trigger BASS_SYNC_DEV_FAIL syncs. BASS_SYNC_DEV_FORMAT syncs currently only apply to playback devices and don't indicate a problem (output continues in the new format).

I will hopefully be able to look into adding a "Default" recording device next week.

[saga]

Do you think it would be feasible for BASS to provide a parameter to the BASS_SYNC_DEV_FAIL callback that would indicate whether it is safe to simply try reopening the device (e.g. because the format changed) or if the device was completely lost? e.g. param=1 could indicate that the device still exists but needs to be reopened. Essentially what I want to avoid is trying to reopen the device when BASS already knows that the device is gone and that it's going to fail. But I understand that this might not be possible on all platforms.

[Ian @ un4seen]

What happens is that WASAPI invalidates (AUDCLNT_E_DEVICE_INVALIDATED) any IAudioClient instances when the device's format changes. The same thing happens if the device is disconnected/disabled. So it isn't immediately obvious what happened. In the case of a playback device, BASS will try to reinitialize and continue playback, triggering BASS_SYNC_DEV_FORMAT syncs if successful (and the format changed) or BASS_SYNC_DEV_FAIL syncs if unsuccessful. In the case of a recording device, BASS doesn't try to reinitialize, so it goes straight to triggering BASS_SYNC_DEV_FAIL syncs.

In your case, perhaps you could call BASS_RecordGetDeviceInfo to check whether the device has the BASS_DEVICE_ENABLED flag set before deciding whether to try reinitializing? That flag will be unset if the device is disconnected/disabled.

[saga]

Thanks for the explanation. I think for the sake of simplicity I'll just try reopening the device then without verifying first.

[saga]

Bumping this, before it falls through the cracks again...

[Ian @ un4seen]

Sorry about the lengthy delay! I'll give it priority this week and hopefully get back to you with something to try finally.

[Ian @ un4seen]

Here's something for you to try:

   www.un4seen.com/stuff/bass.zip

It adds a BASS_CONFIG_REC_DEFAULT option to enable a "Default" recording device (disabled by default), which should be done before any device enumeration is. It also adds support for continuing recording when the device's sample rate changes (with any device), and triggering BASS_SYNC_DEVICE_FORMAT syncs in that case. Let me know if you encounter any problems. One thing to note is that no input controls (eg. BASS_RecordSetInput) are currently available when using the "Default" device. Both new features also only apply when using WASAPI recording, not DirectSound (the "Default" device is still available but it won't follow device changes).

[saga]

Thank you! So far, all my tests have been successful and the feature is working just as expected. As the default audio device option is also available on macOS, do you think that extending this new feature to macOS is also possible?

[Ian @ un4seen]

Good to hear that it's working well so far. I haven't looked into macOS support yet, but I imagine that should be possible. I'll look into it next week.

[Ian @ un4seen]

Here's a macOS update for you to try:

   www.un4seen.com/stuff/bass-osx.zip

It should add the same stuff as the Windows update above. It hasn't been tested much yet, so please report how you get on with it.

[saga]

Thanks again! I'll test it in the following days and let you know if there are any issues (very basic tests have been successful so far). I've been using the Windows build for a while and everything is still going smoothly there.

[saga]

So far both versions are working well for us. Tangentially related, we did find something on Windows that could be potentially confusing to users, and I wonder if BASS could be improved here: Apparently Windows 10 introduced app-specific default devices at some point (type "Sound Settings" into the start menu, then scroll down in that settings panel and choose "App volume and device preferences"). There, you can choose specific input and output devices for each application. As one would expect, using the new default device option follows that choice, but BASS_(Record)GetInfo doesn't reflect the app-specific defaults (just the system defaults), so in our UI we show that a completely different device is the current default device. Could you look into this and check if it's possible for BASS to retrieve the app-specific default devices in addition to system defaults?

[Ian @ un4seen]

So far both versions are working well for us.

Great! Let me know if that changes.

Tangentially related, we did find something on Windows that could be potentially confusing to users, and I wonder if BASS could be improved here: Apparently Windows 10 introduced app-specific default devices at some point (type "Sound Settings" into the start menu, then scroll down in that settings panel and choose "App volume and device preferences"). There, you can choose specific input and output devices for each application. As one would expect, using the new default device option follows that choice, but BASS_(Record)GetInfo doesn't reflect the app-specific defaults (just the system defaults), so in our UI we show that a completely different device is the current default device. Could you look into this and check if it's possible for BASS to retrieve the app-specific default devices in addition to system defaults?

Interesting. I'll look into it.

[David_AVD]

Is BASS_CONFIG_REC_DEFAULT implemented in the public release yet? If so, how is it used?

[Ian @ un4seen]

It is in the public beta:

   www.un4seen.com/stuff/bass.zip
   www.un4seen.com/stuff/bass-osx.zip

It isn't currently enabled by default, so you first need to enable it via the BASS_CONFIG_REC_DEFAULT (73) option:

Code: [Select]

BASS_SetConfig(BASS_CONFIG_REC_DEFAULT, 1); // enable "Default" device

Some more info is in the post above where it was introduced:

   www.un4seen.com/forum/?topic=19179.msg136894#msg136894

[David_AVD]

Thanks. Any news on a release date for a new bass version?

[Ian @ un4seen]

There isn't a set date for the next release but it should be soon. Perhaps in a couple of weeks.