Zetta Com v1.3.0
A microphone that opened dead stayed dead
After installing, voice did not work until the machine was logged out of and
back in. That is fixed, and it is the reason to take this build.
A capture stream can open, report no error, and never be called once — which is
what starting before the audio endpoints are ready looks like from inside the
app. Nothing noticed it. The device name had not changed, so the device poll was
satisfied; playback had its own liveness check and was fine; and the only
capture counters advance solely while the talk key is held, so a dead microphone
and a quiet room were the same two zeros. The app went on believing it had a
microphone, everyone else heard silence when you pressed the key, and the state
lasted as long as the process — which is why logging out looked like the remedy.
Capture now has the pulse playback already had. Three seconds without a callback
rebuilds the pipeline: twice at that speed, then once a minute for as long as it
takes. It never gives up, because a rebuild costs about a second of playback and
neither extreme is acceptable — retrying every few seconds forever would trade
not being able to talk for not being able to listen.
There is a log now
Release builds run without a console, which on Windows means the process has no
standard error at all — so every diagnostic the app produced, naming exactly
which device failed and why, was written to a handle that went nowhere. That is
why the fault above took two attempts to find.
Everything now goes to:
%APPDATA%\com.joy.zetta-com\zetta-com.log
It sits beside your settings, never leaves the machine, and is dropped and
started again once it passes a megabyte. The once-a-second line leads with
mic — capture callbacks in the last second. That is the first number to read
when somebody cannot hear you. Zero there, with a device named in the lines
above it, means the microphone stream is open and dead.
Which build everyone is on
Each machine puts its version on the wire, and the roster names anyone running
something different from you.
This is for keeping a rollout straight, not for finding faults, and it is worth
being exact about the difference: a machine too old to talk to you at all cannot
tell you its version either, because its packets are rejected before anything in
them is read. It also has nothing to say about a network of 1.2.0 machines,
which do not send a version. It starts being useful from this release onwards.
Nothing here asks the internet. The app makes no outside calls, in this version
or any other — it only knows what the machines on your own network have said.
Updating a network that is already running
1.3.0 and 1.2.0 work together. The wire format is unchanged and the version
packet is a kind older builds ignore, so machines can be updated one at a time,
in any order, with nothing going quiet in between.
The microphone fix is per machine. A PC still on 1.2.0 keeps the fault until you
get to it.
Machines on 1.0.0 still cannot hear anybody, as with 1.2.0: the wire format
changed at 1.1.0 and an older build rejects every packet from a newer one
without reporting it. Those need updating before they are part of the room
again.
Installing
Windows — Zetta.Com_1.3.0_x64-setup.exe. It asks for administrator so it
can add the firewall rule for you.
macOS — Apple silicon, and unsigned, so Gatekeeper will call it damaged. It
is not. Move it to Applications and clear the quarantine flag:
xattr -cr "/Applications/Zetta Com.app"Then turn on System Settings → Privacy & Security → Local Network. Clearing
quarantine can mean that prompt never appears, and without the permission the
app looks like it is running perfectly while hearing nobody at all.
Linux — .deb, .rpm or the AppImage.