On 2026/03/04 20:56, Christian Schoenebeck wrote:
On Wednesday, 4 March 2026 07:16:57 CET Akihiko Odaki wrote:
init_out_device may only commit some part of the result and leave the
state inconsistent when it encounters a fatal error or the device gets
unplugged during the operation, which is expressed by
kAudioHardwareBadObjectError or kAudioHardwareBadDeviceError. Commit the
result in the end of the function so that it commits the result iff it
sees no fatal error and the device remains plugged.
With this change, handle_voice_change can rely on core->outputDeviceID
to know whether the output device is initialized after calling
init_out_device.
Signed-off-by: Akihiko Odaki
---
audio/coreaudio.m | 47 ++-
1 file changed, 26 insertions(+), 21 deletions(-)
diff --git a/audio/coreaudio.m b/audio/coreaudio.m
index 736227eb2b7a..23c3d1f80ac5 100644
--- a/audio/coreaudio.m
+++ b/audio/coreaudio.m
@@ -357,8 +357,11 @@ static OSStatus out_device_ioproc(
static OSStatus init_out_device(CoreaudioVoiceOut *core)
{
+AudioDeviceID device_id;
+AudioDeviceIOProcID ioprocid;
AudioValueRange value_range;
OSStatus status;
+UInt32 device_frame_size;
Shouldn't then be this here at the beginning?
core->device_id = kAudioDeviceUnknown;
core->ioprocid = NULL;
...
Setting device members is done in correspondence with actual device
operations. Concretely, fini_out_device() sets kAudioDeviceUnknown to
device_id to express it finalized the device. This function initializes
the device or does nothing if an error happens, so it sets device
members or does not touch otherwise.
[...]
if (status != kAudioHardwareNoError) {
coreaudio_playback_logerr(status,
"Could not set device buffer frame size %"
PRIu32,
- (uint32_t)core->device_frame_size);
+ (uint32_t)device_frame_size);
return status;
}
Why the cast here? device_frame_size is declared as UInt32.
The definition of uint32_t is not literally identical with UInt32, so
the compiler complains it is different from what the format string
(PRIu32) expects. I think I'm going to use uint32_t for the variable to
avoid this.
Regards,
Akihiko Odaki
