Story of a ROOPHLOP
-------------------

This post is *about* my ROOPHLOCH 2022 efforts, but does not itself
meet the criteria to *be* a ROOPHLOCH post.  At this point, with just
a bit over 24 hours left, with tonight already dark and cold and with
family plans already made for Friday night, it seems increasingly less
likely I'll make a post which does meet the criteria.  I'm less than
happy about that, believe you me, but at least this year it genuinely
wasn't through a lack of trying.

I was content to make my very first ROOPHLOCH post back in 2019 via
the relatively unremarkable means of connecting an eeePC to a
smartphone's wireless hotspot, but after that humble beginning I always
intended to escalate my game, and from even early days I had a really
clear plan: I was going to head out with the eeePC, write a post, and
then use the `minimodem` to render said post into a .wav file encoded
the file via audio frequency shift keying.  This is exactly the
technology that the earliest dial-up modems were based on.  You play a
sine wave at one frequency for "0" and at another frequency for "1",
and you just sing your bits, one by one, in sequence, at a fixed rate,
perhaps with some "stop bits" in there to help synchronise things.
Then I'd use my phone to call my wife back at home, who would pick up
and point her phone at my ThinkPad, which would be running its own
copy of minimodem, set to listen, not to sing, in part of a script
which would save what it heard to a text file and upload it to my
phlog.  The big appeal of this approach was, while I'd probably do it
using an ordinary old phone call, the same basic approach would work
exactly the same via walky-talky or amateur radio or any other means
of remote sound transmission.  But while coming up with the plan was
easy, I had thus far failed to getting around to actually trying this
in time to make a successful post via the method.

Well, I started down the road to finally making this long-standing
plan a reality, early last Saturday.  After a small but irritating
amount of yak-shaving related to the fact that minimodem, to my
surprise, wants to use PulseAudio by default but PA wasn't set up on
either of the machines that I was using, I quickly got to the point
where this worked well and reliably with both laptops in the same
room, even separated by a few meters of empty space.  I used a low
baud rate and a wide separation between the two frequencies, to make
the whole thing more robust to noise, and because of that it worked
despite street noise filtering in through the open windows, etc.
Success!

But as soon as I moved from transmitting a phlog post across a few
meters of empty space, and tried to use exactly the same minimodem
commands on both ends to transmit a phlog post from one end of our
apartment to the other via a simple phone call, everything stopped
working and I wasted the better part of the day trying to figure out
why, to no avail, leaving me dejected and bitter.  We tried putting
the call on speakerphone, or not doing that, holding it close to the
ThinkPad's microphone or far away from it (and same with holding the
transmitting phone near or far from the eeePC's speakers), muting the
receiving phone call to avoid feedback, and we tried giving up on the
traditional telephone network proper and using a Signal voice call
instead, and we tried every other sensible little change you can think
of, and simply nothing worked.  I dropped the baud rate down so low
that sending a post as long as this one would take a literal hour, it
didn't help.  You can plainly hear with the unaided ear (and I
confirmed it by visualising the ThinkPad's perspective using the
`baudline` software) that one tone is reproduced by the receiving
phone much more quietly than the other.  The output sounds more like
on-off amplitude shift keying than shift keying.  I have no idea why,
but it's clear that modern phones are in some sense too "smart" for
this to just work - some kind of automatic gain control or noise
reduction technology or something is distorting the audio badly and
nothing gets through.  I tried reducing the frequency shift to be very
narrow, just 25 Hz, figuring that some kind of window-based frequency
domain analysis which tried to figure what the signal bandwidth was
and filter out anything outside it, but didn't operate fast enough to
reconfigure its filters between the frequency shifts, probably
wouldn't have windows so narrow that it would differentiate between
tones so close together, but this had no effect at all.

I don't know why, but accurately reproducing an audio signal consisting
of nothing other than sine waves alternating between two fixed
frequencies is apparently completely beyond the capabilities of a
modern smartphone.  I'm sure it's not impossible in principle, no
doubt if I dedicated my ongoing energies to solving this problem I
could discern the reason and come up with a work around.  But truly,
friends, life is short and time is precious and this is not an
important problem.  I'm old and tired and techno-jaded enough at this
point (and self-aware enough to know it) that if I fought the long,
hard battle and won, my lasting trophy wouldn't be joy and pride and a
sense of achievement at the victory, but disdain and hatred over the
fact that there was a battle to fight at all when this should have
simply "just worked" like I'm sure it would have with an analog
landline phone that I had to walk uphill in the snow to use.  I
declined to throw good time after bad and gave up, and I'm not ashamed
of it.

I'll have to think up something completely different for ROOPHLOCH
2023.