Lightning 0.9.7

A calls release. If people could not hear you, this is the one.

People can hear you again

Lightning was sending your voice 12 dB too quiet on a multi-input audio
interface. A USB interface — an audio box with several inputs, rather than a
plain headset — usually presents four or more capture channels with a
microphone on the first and nothing on the rest. Lightning asked the sound
system for a single channel, and it produced that single channel by averaging
all of them. Your voice was mixed with three silences and came out at a
quarter of its strength: audible in theory, inaudible in practice, and the far
end heard nothing.

Lightning now takes the input that has your microphone on it. Measured on the
device this was reported against: the capture went from -33 dBFS to -5 dBFS.

Ordinary microphones and headsets are unchanged. A stereo microphone is still
mixed down the way it always was, because for an actual microphone that is the
right thing to do.

The delay is gone

Your audio reached the other side about a second late. The buffer between
the microphone and the encoder was allowed to hold a full second of sound and
never to let any of it go, so a single moment of the machine being busy turned
into a delay that lasted for the rest of the call — in one direction only.

That buffer is now a tenth of a second, and when it does overflow it drops the
oldest audio instead of queueing it. In a conversation a lost instant is always
better than a second of lag on everything that follows.

Lightning can tell you when your microphone is dead

This is the part that took a day to find, and the reason it took a day is that
nothing in Lightning could tell a working microphone from a silent one. An
encrypted call carrying pure silence produces exactly the same healthy-looking
counters as one carrying a conversation.

So Lightning now measures what it is actually sending:

• the microphone's level goes into the log every few seconds, whether it is
  good news or bad;
• if the microphone produces nothing at all while you are unmuted, you get a
  warning in the call header saying so;
• and if the capture never starts, the log says that instead of staying quiet.

If you ever report "nobody can hear me" again, the first line of the log will
say whether your microphone was live.

Encryption in calls

A call could join an encrypted room without encryption. If Lightning had not
yet finished working out whether a room was encrypted when you pressed call, it
could publish your audio and video in the clear. It now re-checks at the moment
you join and never downgrades a room it knows to be encrypted.

Keys sent to you a moment too early were thrown away. The other person sends
their call key as soon as they see you join, which can arrive before Lightning
is ready for it — three such keys were discarded on every call, which is why the
first seconds of a call could report that someone's audio could not be
decrypted. Those keys are now kept and applied the moment the call starts.

Lightning no longer encrypts under a key that reached nobody. If a key could
not be delivered to anyone, Lightning keeps using the one the other side
actually holds.

Calling in rooms Lightning created

A room Lightning created did not let its own members join a call. Rooms were
created with the default permissions, which reserve call membership for
moderators, so an ordinary member pressing call published nothing. New rooms are
created correctly now.

Rooms created before this release still carry the old permissions and need them
changed by a room admin.

Diagnostics, for the next time

Lightning now records what a call is actually doing, because none of the above
could be found from what it used to record:

• the microphone's level, every few seconds;
• how many RTP packets really left the machine — the old counter was measured
  before the packetiser and said nothing about what was sent;
• whether the call server accepted the microphone track it was offered;
• and whether the microphone is muted, which had never been logged at all.

Still not fixed

Sending camera or screen share in an encrypted room does not carry. Receiving
works. This needs a change to how video is packetised and is not in this
release.

This is a read-only mirror. It is not a release authority.

The canonical Lightning 0.9.7 release lives on GitLab:
https://gitlab.smetonis.net/Mizerd/lightning/-/releases/v0.9.7

The files attached here are byte-identical copies of the artifacts published
there. They exist so downloads do not all have to come from one small server.
Nothing about this page decides anything: it does not determine what version
exists, what is installable, or what Lightning will accept.

Verify any download against the SHA256SUMS asset, which is itself a copy of
the published one.

Lightning's in-app updater fetches its update manifest only from GitLab and
verifies an Ed25519 signature made with a key that exists nowhere near GitHub.
Every downloaded file is checked against the SHA-256 recorded in that signed
manifest before it is installed, so replacing a file here cannot cause Lightning
to install it.

Issues, source, and history: https://gitlab.smetonis.net/Mizerd/lightning