hs.audiodevice state is particular to Hammerspoon object, not audio device (Documation clarification needed)

[von]

This is spawned from issue 3057. It is not believed to be a bug, but counterintuitive behavior that is not currently documented.

Create a watcher on an audiodevice:

> a = hs.audiodevice.allInputDevices()
> a[1]:uid()
BuiltInMicrophoneDevice
> a[1]:watcherIsRunning()
false
> a[1]:watcherCallback(c)
hs.audiodevice: MacBook Pro Microphone (0x6000006ccb98)
> a[1]:watcherStart()
hs.audiodevice: MacBook Pro Microphone (0x6000006ccb98)
> a[1]:watcherIsRunning()
true

Then re-obtain the audiodevice, the watcher will not appear to be running when examining the new object:

> a = hs.audiodevice.allInputDevices()
> a[1]:uid()
BuiltInMicrophoneDevice
> a[1]:watcherIsRunning()
false
> a[1]:watcherStart()
2022-10-19 11:32:22: 11:32:22 ERROR:   LuaSkin: You must call hs.audiodevice:setCallback() before hs.audiodevice:start()
nil

See comment from Rhys-T for more detail.

[cmsj]

Yeah that is not technically a code bug, we don't keep track ourselves of the Lua objects that have previously been created to represent system resources, they just live in Lua until it decides to garbage-collect them.

It's definitely a design bug though, albeit one that is not trivial to avoid without making it impossible to ever release memory. Some of our extensions are better at this than others.

I've pushed a note to the hs.audiodevice docs to mention this, but it's definitely not the only extension where this is true.