Topic: BASS_RecordStart fails, error code -1

[saga]

On a customer's machine running Windows 10 for Education, our software is unable to use the microphone for some reason. It appears that BASS_RecordInit succeeds but BASS_RecordStart fails, and BASS_ErrorGetCode() returns -1, so that's not exactly helpful. Could you send me a BASS debug version (64-bit) to figure out what's wrong?

[Ian @ un4seen]

Perhaps the app doesn't have permission to access the microphone? You can check that in Windows' "Microphone privacy" settings. The next BASS release will add a new BASS_ERROR_DENIED error code to indicate that issue. It is also present in the latest build, so you could try that and see if the error code changes then.

   www.un4seen.com/stuff/bass.zip

[saga]

Ah, I just realized that they were running an older version of our app which was using an older version of BASS as well. I was thinking of exactly that but using the current version of our app, I get error 49 instead of -1, so I will ask them to update to the latest version to confirm if that would return error 49 instead.

[saga]

Just got the confirmation that the Windows privacy setting was the issue here. Glad to see that this can now be reliably diagnosed with an error code!

[saga]

Piggybacking on this thread... I recently noticed that BASS_ERROR_DENIED is also available on Android now, but apparently not on iOS (at least not on the dynamic test version you sent a while ago). Would it be possible to have this feature on iOS as well? Right now, it seems that recording starts successfully on iOS but it just returns silence, which isn't very helpful of course.

[Ian @ un4seen]

Yes, iOS (and macOS) will allow recording to start without permission but it will only deliver silence. The AVAudioSession recordPermission method (AVCaptureDevice authorizationStatusForMediaType on macOS) can be used to check the permission status.

[saga]

Do you think it would make sense for BASS to do this check before trying to open the device, to make its behaviour more consistent across platforms?

[Ian @ un4seen]

When recording is first attempted by an app, iOS will automatically ask the user if they want to allow it, but the app won't be blocked in the meantime, ie. recording will start and capture silence while the user is deciding. So an app should ideally check and request permission (using the requestRecordPermission method) first, and only call BASS_RecordStart when it has been granted.

But BASS_RecordStart could be made to check when permission has already been denied previously and fail then (BASS_ERROR_DENIED). Here's an update (dynamic version) that should do that:

   www.un4seen.com/stuff/bass-ios-test.zip

[saga]

Thanks, the update works as expected. We do request the permission of course, but it is possible for a user to revoke the permission, in which case I think iOS will not show them the permission prompt again (similar to most Android devices) - in which case it's nice to show the user why the recording won't work. Would it be possible to provide the same change for the macOS build?

[Ian @ un4seen]

I'll have to first check if there's any way to get the permission status in plain C/C++, as the macOS BASS version currently doesn't include any Objective-C stuff to minimize dependencies.

[saga]

I'll have to first check if there's any way to get the permission status in plain C/C++

Did you find out anything?

[Ian @ un4seen]

No, haven't found anything yet unfortunately, so BASS still doesn't check itself, but you could have your app check before calling BASS_RecordStart. A little demonstration of doing this can be found in the RECTEST example included in the BASS package.

[saga]

We did try something along those lines now, but hoped that we could use the same code on all platforms. The biggest issue here really is that we only know until after the recording started whether the permission is given or not (as the permission prompt is not model, the program continues to run while the user is making a choice). If there was a way that BASS could stop the recording (maybe with the lost device callback?) once it knows for sure that the permission is denied, that would be very helpful - but I'm not sure if macOS would notify BASS (or our own code) in any way that the permissions have changed. Right now, we have to work around this by repeatedly checking permissions until we know for sure that the permission was given or not given, which is a bit annoying.

[Ian @ un4seen]

The biggest issue here really is that we only know until after the recording started whether the permission is given or not (as the permission prompt is not model, the program continues to run while the user is making a choice).

Perhaps you can avoid that by initiating the permission request yourself via the requestAccessForMediaType method and delay the BASS_RecordStart call until you get the result of that. For example, something like this:

Code: [Select]

AVAuthorizationStatus auth = [AVCaptureDevice authorizationStatusForMediaType:AVMediaTypeAudio];
if (auth == AVAuthorizationStatusDenied || auth == AVAuthorizationStatusRestricted) {
// cancel recording
} else if (auth == AVAuthorizationStatusNotDetermined) {
[AVCaptureDevice requestAccessForMediaType:AVMediaTypeAudio completionHandler:^(BOOL granted) {
if (granted) {
// start recording
} else {
// cancel recording
}
}];
} else {
// start recording
}