Let’s get to my current usecase though. I’m making an AI-powered editor right now - and streaming response from OpenAI API looks so much better than a really long wait for a full response. Plus you can abort that response in-flight if you see it going awry.

Which means I need to send context to a server, right? And the only way to convey anything to a server using EventSource object is through the URL. There is no way I can pass enough context through an URL, and I really don’t want to use WebSockets here. It’s a totally different beast, and why would I reach for something that different if I have an almost perfect tool for that job?

So I searched the internets a bit and found an implementation of SSE using fetch. I had to upgrade it a little bit — there was no protocol parsing, but it’s just a few lines of code and it works beautifully.

Except later on I decided to make that “abort” button. How do you abort a fetch request? You create an AbortController, then pass it as fetch(url, {signal: controller.signal}), and then call an .abort() method. Awkward? Very much so. But at the very least is it working? Not at all!

I mean, yeah, request is aborted. But your promise (the one that fetch returned) is never rejected (nor resolved, of course). And in Firefox’ devtools console you get an error pointing to the line with controller.abort() call. You can’t catch it with a try/catch. Of course! Chrome is even better: it reports an error on the first line of your HTML. OooOoOoo momma I’m a web developer help me before I killed a man.

One option is to reject that promise by myself, but it sounds dirty and does not get rid of the weird errors in devtools. So I reached to an old friend XMLHttpRequest and that guy is reliable as ever! Behold the mighty:

function sseevent(message) {
  let type = 'message', start = 0;
  if (message.startsWith('event: ')) {
    start = message.indexOf('\n');
    type = message.slice(7, start);
  }
  start = message.indexOf(': ', start) + 2;
  let data = message.slice(start, message.length);

  return new MessageEvent(type, {data: data})
}

export function XhrSource(url, opts) {
  const eventTarget = new EventTarget();
  const xhr = new XMLHttpRequest();

  xhr.open(opts.method || 'GET', url, true);
  for (var k in opts.headers) {
    xhr.setRequestHeader(k, opts.headers[k]);
  }

  var ongoing = false, start = 0;
  xhr.onprogress = function() {
    if (!ongoing) {
      // onloadstart is sync with `xhr.send`, listeners don't have a chance
      ongoing = true;
      eventTarget.dispatchEvent(new Event('open', {
        status: xhr.status,
        headers: xhr.getAllResponseHeaders(),
        url: xhr.responseUrl,
      }));
    }

    var i, chunk;
    while ((i = xhr.responseText.indexOf('\n\n', start)) >= 0) {
      chunk = xhr.responseText.slice(start, i);
      start = i + 2;
      if (chunk.length) {
        eventTarget.dispatchEvent(sseevent(chunk));
      }
    }
  }

  xhr.onloadend = _ => {
    eventTarget.dispatchEvent(new CloseEvent('close'))
  }

  xhr.timeout = opts.timeout;
  xhr.ontimeout = _ => {
    eventTarget.dispatchEvent(new CloseEvent('error', {reason: 'Network request timed out'}));
  }
  xhr.onerror = _ => {
    eventTarget.dispatchEvent(new CloseEvent('error', {reason: xhr.responseText || 'Network request failed'}));
  }
  xhr.onabort = _ => {
    eventTarget.dispatchEvent(new CloseEvent('error', {reason: 'Network request aborted'}));
  }

  eventTarget.close = _ => {
    xhr.abort();
  }

  xhr.send(opts.body);
  return eventTarget;
}

That’s the full implementation of an EventSource (at least for my use case), even the method to close connection is called close(), just as in real EventSource. So you would use it like that (just an example, tune for your own needs):

const xs = XhrSource('/your/api/url/', {
  method: 'POST',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({some: data})
});

xs.addEventListener('error', e => {
  outputEl.textContent += 'ERROR: ' + e.reason;
});

xs.addEventListener('close', e => {
  outputEl.textContent += '\nDONE';
});

xs.addEventListener('message', e => {
  const msg = JSON.parse(e.data);
  outputEl.textContent += msg.content;
});

One interesting thing to note here is that loadstart event is sent synchronously with the xhr.send(opts.body) call - before the return happens. This feels weird to me, since no listeners are ready by the time… But if I put xhr.send in setTimeout, then data starts arriving visibly later. I have no idea why, profiling and looking at network panel did not give me any insights, so if you know what’s up or get other results or anything - hit me up, I’d love to understand what is going on.

All in all it feels like this post took more time to write than the code - and it’s much simpler than DecodablePipe stuff from Rob’s post. Works well for me, so maybe it’ll do the same for you. :)

I understand that hosting is more commoditized than tunnels — I guess the market is wider — but still, it felt like I could spend a few hours and get something similar working. Why do I need custom domains? Because losing cookies makes me unhappy, and cookies require domain not to change. Plus, testing OAuth is really painful without custom domain since everybody wants to pin redirect URL to a stable domain.

There are many open source alternatives, the one I really liked is called SirTunnel. It's a small script which uses Caddy's JSON API to add and remove domains. But it got me thinking: why add and remove domains when I can just give another domain for some site forever? So if I started that site's process, it's working, and when not — well, you'll get 502 Gateway Timeout on that particular domain, no big deal.

The Plan

It's simple! I create a wildcard domain (something like *.xxx.solovyov.net, xxx is for "real domain is none of your business" 😁), and then reverse-proxy everything through an SSH tunnel from a server to my laptop.

I'm still going to use Caddy since automatic HTTPS and laconic config appeals to me. 👍

Why do I need a local Caddy? Because SSH can proxy only single port and local processes occur on different ports. You can ignore that part if you don't need an ability to run multiple sites simultaneously. You know what, this case makes everything easier, since you require only one external domain for that rather than my wildcard setup.

Execution

So, I've got a local Caddy working with many domains mapped to various ports. My plan is to run every project on a separate port, so when I start a process, it's immediately available to the world. Feels a bit exhibitionist, but very convenient. ☺️

Next was permanent SSH tunnel. I could've done that myself, but I just found a recipe.

The first problem is that handling *.xxx.solovyov.net in Server-Caddy makes Caddy request a wildcard certificate. And this requires integration of Caddy with DNS provider, which is limited to a few big providers. So, I opted to just repeating site definitions. :)

Next problem was… that it all worked! I could not believe my eyes. 🤣

But the story does not end here. You know what is irritating about ngrok? Latency. Especially when you're on a bad connection.

I mean my site is right here on my laptop but those roundtrips just to test OAuth and what not… Argh. I did not invent anything better than just writing that development domain in /etc/hosts. And. It. Worked! Too bad /etc/hosts does not support wildcards, so I'll have to repeat domains there too.

Tutorial

You'll need a domain name you own and control (really, control matters more than ownership here 😜) and a VPS somewhere in the world. Please do not copy and paste stuff blindly, you'll have to change at least the domain name for this to work. :)

Domain

Add *.xxx entry of type A to your domain pointing at your VPS.

Local Caddy

brew install caddy — correct for your package manager — and start with this Caddyfile:

{
	auto_https disable_redirects # so remote caddy is happy
	email your@real.email # so you can debug problems with certs
}

(local) {
	{args.0}.xxx.solovyov.net {args.0}.xxx.solovyov.net:80 {
		encode zstd gzip
		reverse_proxy localhost:{args.1}

		handle_errors {
			respond "Local: {http.error.status_code} {http.error.status_text}"
		}

		log {
			level DEBUG
			output file /opt/homebrew/var/log/caddy/{args.0}.log
		}
	}
}

import local dev 5000
import local experiment 5001
import local blog 5002

This (local) thingie is called a snippet. Now I can just copy this import line as many times as I want, not having to repeat those lines.

We instruct Caddy to listen to port 80 so that basic HTTP works. We need HTTP since our SSH tunnel targets this port. But HTTPS (domain without :80) is also nice to have — it makes external and internal setup more similar.

brew services start caddy or equivalent to make Caddy run after system startup.

Persistent SSH Tunnel

Just follow a tutorial from Tyler, should be simple enough. Your /.ssh/config entry should look like this:

Host sshtun
	HostName your.remote.server
	RemoteForward 6800 127.0.0.1:80
    ServerAliveInterval 60

What Tyler doesn't tell is that you have launchctl load -w Library/LaunchAgents/your.plist.name.plist, this little -w marks it enabled so launchctl will start it after restart (sounds like a common theme ain't it?).

In case you're not on macOS, use your system's process manager or look at autossh.

Obviously, you can replace that part with some VPN solution, like Wireguard for an open-source solution or Tailscale like something more convenient.

Remote Caddy

No need to disable automatic redirects, so minimal version will look like this:

{
    email alexander@solovyov.net
}

(sshtun) {
    {args.0}.xxx.solovyov.net {
        encode zstd gzip
        reverse_proxy localhost:6800

		handle_errors {
			respond "Remote: {http.error.status_code} {http.error.status_text}"
		}

        log {
            output file /var/log/caddy/sshtun.log
        }
    }
}

import sshtun test
import sshtun experiment
import sshtun blog

You can see I'm using snippets here as well, but the port is the same every time, since this is our SSH tunnel.

Remote Caddy Wildcard

After some thinking, I decided to try out wildcard setup anyway. I moved my domain to Cloudflare, since this is one of the providers supported by Caddy (filter by caddy-dns here to see others), downloaded a custom Caddy build, added a diversion (Debian/Ubuntu-specific) so that the regular package is in place (though I'll have to upgrade to new versions manually) and changed config to this:

{
    email alexander@solovyov.net
}

*.xxx.solovyov.net {
	encode zstd gzip
	reverse_proxy localhost:5900
	handle_errors {
		respond "Server: {http.error.status_code} {http.error.status_text}"
	}
	tls {
		dns cloudflare <API TOKEN HERE>
	}
	log {
		output file /var/log/caddy/d.log
	}
}

You can get Cloudflare API token here. And it worked! I got wildcard certificate so no need to edit this config any more!

/etc/hosts

This is optional, but if you want the same glorious setup, add this to /etc/hosts:

127.0.0.1 test.xxx.solovyov.net

but do not forget to use your actual DNS address. :)

Adding a new domain

There are a few edit points:

• Local Caddyfile — this is non-optional to map name to port (again, I give different projects different ports so that I can start a few of them simultaneously)
• Remote Caddyfile — when there is no wildcard certificate
• /etc/hosts — optional, to short-circuit browser

In case something is not working, you will get different errors:

• Server: ... if there is no connection from your server Caddy to laptop's Caddy. Maybe your ssh tunnel is down, if everything is in place, kill $(pgrep -f sshtun) helps to force reconnect.
• Local: ... if there is no connection from local Caddy to your process. Perhaps it's time to start your site? :)
• Other stuff should come straight from your process, so you know what to do.

The End

And you know what? No need to start many ngrok processes occupying your terminal when you want a few of your sites running! Epic.

create index report_comment_lower_trgm on report 
  using gin (lower(comment) gin_trgm_ops);

But I've been looking for one concrete thing and couldn't find, even though I knew it's there:

finreport=# select count(*) from report where lower(comment) like '%кредиторськ%';
 count 
-------
     0

Yet, it turns out that just looking for a case-sensitive version works just fine:

finreport=# select count(*) from report where comment like '%Кредиторськ%';
 count 
-------
    40

What is even going on? After reading some articles, it seems like the main reason for this is an incorrect collation, so I went to check:

finreport=# select datcollate, datctype from pg_database where datname = 'asd';
 datcollate | datctype 
------------+----------
 C          | C

Wow, well, obviously C is not very correct when I'm looking at Ukrainian. Okay, is there a way to update collation? Some answers on Stack Overflow propose to just update pg_database, which is immediately did. Any guesses what happens next?

finreport=# select count(*) from report where lower(comment) like '%кредиторська%';
 count 
-------
    11

finreport=# select count(*) from report where lower(comment) like '%кредиторська%';
 count 
-------
     3

finreport=# select count(*) from report where lower(comment) like '%кредиторська%';
 count 
-------
     7

I had not expected this! Well, I did all the things you do when things are going wrong: re-created index, analyzed table, restarted the database — and the last one finally changed something! It started giving me 0 rows back again. :)

Solution

Recreate database anew, so just dump and restore:

# stop all the things which can change db here
$ pg_dump finreport > finreport.dump
# Postgres complained about "template" having other collation
# and proposed using "template0". I have no idea what's the
# difference, but it worked.
$ createdb -l uk_UA.UTF-8 -E utf-8 --template=template0 qwe
$ psql qwe -f finreport.dump

# renaming databases
$ psql postgres -c "select pg_terminate_backend(pid) from pg_stat_activity where datname = 'finreport'"
$ psql postgres -c "alter database finreport rename to asd"
$ psql postgres -c "alter database qwe rename to finreport"
# don't forget to start all the stuff here and drop asd

This obviously resets everything, and it now works as intended.

I'm uncertain if various UTF-8 collations will be different. I hope not because in other case I have no idea how to deal with multiple languages in a single Postgres db.

You see, controlling app behavior can be done in various ways, but the major one is updating what user sees with a new markup from the server. And that potentially can change URL: like when user selects a filter in a product catalogue, this filter gets appended to a query string.

“Go back”

Fortunately, there is an API to change URL without reloading the page: history.pushState. User sees an updated URL and all is well. What happens if said user presses back button? He or she expects to see interface from before URL change. Not so fast! URL will change back, but HTML will stay!

What’s the solution? Well, pushState (and replaceState) accepts an argument called state. And before every pushState TwinSpark diligently did a replaceState for current URL placing current HTML in that storage:

history.replaceState({html: document.body.innerHTML})

And when user presses back button, browser raises popstate event, indicating that user wants to go back in history. So you can listen to that event and then replace your current HTML with what’s inside of e.state.html.

Sounds like it should work nicely, eh? Except for a little problem: Firefox has a limit of 640Kb for a single entry here (Chrome and Safari limits are much higher, so of no concern here). And we have endless scroll on product lists. Do you feel where this is going? Our Sentry is full of errors of Firefox users who have scrolled enough. And if they ever go back the behavior (restoring of correct HTML) is broken.

Aside: we A/B-tested endless scroll relentlessly because every SEO expert says we should switch to separate pages because Google is really dumb. Not sure about Google being dumb, but endless scroll gives much better conversion rates than pagination. It seems humans hate excessive interaction more than Google hates us.

Real “go back”

It gets worse: what if you changed interface without changing URL and then user went to a separate, real page? Like, there is no pushState, no popstate event, what happens then? I’ll tell you! Browser will show the oldest possible HTML for that whole sequence of pushState. I.e. whatever loaded on a last real page load.

This is a problem of planetary proportions, and there is no storage like pushState to store HTML. One of the solutions could be loading full HTML for the URL you’re opening from a server, but that would be slooooow. Another is slapping some caching in localStorage and calling it a day:

window.addEventListener('beforeunload', function() {
  storeCache(location.href, document.body.innerHTML);
});
if (window.performance &&
    performance.navigation.type == performance.navigation.TYPE_BACK_FORWARD) {
  restoreCache(location.href);
}

You see, we’ve found a weird API — window.performance.navigation.type — to check if you opened a page from a “go back” action, but it’s supported in IE9+ and Mobile Safari 9+, which makes it Good Enough™.

Too bad localStorage is often too small in Mobile Safari! It’s 5MB, which is considerably more than 640Kb, but it’s for all entries rather than a single one in Firefox’ pushState. Oh well…

IndexedDB

I wanted to unify approaches for a long time, and got sick to death of those errors. And the only viable solution to all those problems combined was IndexedDB, with its great presence almost everywhere we care, and high storage limits (IE is first to panic with a threshold of 250MB).

So approach is following: before every pushState or on beforeunload current document.body.innerHTML is being written to IndexedDB. After writing that stuff a count query is made and if it’s over a (configurable, 20 by default) limit — excessive oldest entries are removed. This way if you go back you’ll always get a most recent state of that URL — unless you go back too deep. :)

A popstate event handler replaces HTML, the same as earlier, just with more blood and tears because of IndexedDB API being a little bit less user friendly. What happens on real “go back” is more interesting though: instead of putting it in DOMContentLoaded handler, like everything else, I put it right in a middle of a script itself. This way it manages to update HTML before everything else fires. Browser will even put you in a proper scroll position!

You can read all IndexedDB-related code here. This cursor stuff will leave some marks on my soul, but I won’t pretend I could design a better developer experience given all restrictions designers of that API had. Don’t take my complains seriously, I’m really happy that there is a solution for a problem, unlike often in that life.

I wonder if I need all that defensive programming in here, I could probably shave off some bytes if I remove it… That’s a reason I’m using IndexedDB API directly: I really don’t want this library to be dependent upon other libraries. It’s wrong and it’ll add a lot more code that there already is.

If you feel like I did some mistakes and it could be done better, I’m all ears! I certainly want this history snapshotting to be in a state where there is no need to think about it ever — I’d be grateful for browsers to handle that for me, but let’s work with what’s available. Cheers!

The issue here is that I can’t just start doing something suddenly. I can’t just buy a dishwashing machine — I need to read up on what are the current features and trends and qualities and select the one I like. It’s the same with streaming — I can’t stream using Macbook cam even though I’m going to sit in a little sector of a video. I need a better webcam so I can feel like it’s for real! So I set to research the topic.

Camera

And it turns out you can’t buy a good webcam. They are all shit — even if you pay $200+. If you want good picture quality the only way right now is to buy a photo camera with an HDMI capture card. All major brands have released drivers to connect cameras via USB, but those drivers are unanimously bad: USB2 can support compressed 1080p60, but those drivers only support 576p30. What is this madness I don’t know, so you have to use an HDMI capture card.

The capture card could either be some cheap thingie for $15 from Aliexpress, or an Elgato Camlink 4K for $130 (or other proper brand-name stuff for even more money). Initially I settled on a cheap crap and it works fine for now: it doesn’t support 4K, and 1080p is also questionable, but the resulting video quality is miles ahead of webcams and phones. After some time I realized that it oversaturates image a lot, so I have to turn down colors in camera and end up with almost a grey-scale picture - and bought Camlink 4K, and result is just great.

For a camera you have two non-negotiable properties:

1. It should be able to work on AC power. Working on batteries and a charger is insanity when it’s a non-mobile working place.
2. It should output the so-called “clean HDMI”. This means that HDMI output should contain whatever the camera sees but without all the technical information, which is present on a camera screen — like a shutter speed or a battery level.

The second one just out-ruled my otherwise excellent Fuji X-T1, because it outputs only recorded footage at the HDMI port. It was painful to realize, but I went to a local classified site and bought a used Sony a5100 for $250.

There are a few reasons why a5100:

1. Sony’s autofocus is the best on the market.
2. The sensor is good enough. I looked at dxomark results and they are almost the same as much newer a6400 and a6600 have.
3. It has a flip-out screen that flips up 180° (sticking from the top of the camera). Excellent as a self-monitor, because it will work even if some of the components in the path fail.
4. It’s dirt cheap. It’s an older model made for 6 years already.

I’d prefer to have Fuji — their colors are so much better to look at — but I wanted to keep investment low just in case in two months I decide I don’t need it all. And the cheapest Fuji setup would be 2x from a5100 — partially because Sony’s kit lens is so cheaply made, ugh! Also, when I compared a5100 autofocus performance to my beloved X-T1 my jaw just dropped. Reviews suggest that newer Fuji cameras have improved greatly, but still are not on par with Sony.

UPDATE. After being unhappy with the fact I sold my Fuji (despite not touching it for years) I decided that if I’m so stuck with my gear obsession, it’s better to satisfy it than suffer with it. So I’ve bought Fujifilm X-S10 and Viltrox 23/1.4, and I couldn’t be happier! First, image quality is much better with more detail. Then, colors are excellent. It’s a Fuji’s strength and I just love them even without color-grading. Plus instead of a dummy battery I just plug USB-C cable in! So I put it on a quick release Arca plate, and within 10 seconds I can have a great camera in my hands. It takes same 10 seconds to put it back on, so that’s really low bar to make a better photo. Also, autofocus is good enough for me, reviews left me with impression that it’ll be much worse. :)

Mount

Of course, you can’t just put a camera on your display. Webcams can do that, haha, should’ve gone that way, right? Tripod is an option if you have a place to put it beside a table, but I don’t. So I watched some YouTube videos to see how people mount cameras to film themselves and discovered a Magic Arm.

Aside: did I tell you I had to watch a lot of videos instead of reading text to discover everything? No? Now I did. It’s a bit painful, but lots and lots of information are in video format only, and text articles about streaming are hard to find and incomplete. I guess including this one. :-)

Back to the story. I never saw Magic Arms before, but the way they work is magical.

It seems that Manfrotto invented that stuff (can’t find reliable sources, but I recall reading somewhere it was invented in 2008), but now everyone and their grandma are making clones of it. Clones are not even close in terms of quality to Manfrotto’s products (or Matthews Infinity Arm, or other costly brands), but they are cheap! You can get a “decent” one along with a “crab” clamp for around 20-25$ here in Ukraine (and even cheaper on AliExpress). It’s made from aluminum and will die on you if you use it a lot, of course, but the plan is to leave it sitting in place.

So I bought a monitor stand (it was around $30) and put a magic arm there, and a little $4 ball head, and — bam! — camera is looking right at me now.

Microphone

They say that there are three important things in a video, in that order:

1. Sound
2. Light
3. Video

And… did you know that camera’s mic is the worst mic ever? By a weird coincidence — I tried to make a video with Fuji X-T1 a few times — I already knew that. They pick up weird frequency profiles (to a point where I can’t listen to my voice from those mics), and they are noisy as hell. My MacBook’s mic array is vastly superior to a camera mic! As you can guess to make all that feel more real I need an external microphone.

I knew next to nothing about mics, and I didn’t just want to buy a Blue Yeti because it’s a layman’s choice. Plus I had an audio interface with XLR input and a 48V phantom power¹. So I went to read and watch some videos on mics and after some point stumbled upon Neat Worker Bee — see review at Podcastage (which is the one of two channels I liked about audio, the other being Curtis Judd).

It turns out Neat Microphones were a subsidiary of Gibson and made some upper-class mics: like Worker Bee for $200 and King Bee for $300. But after Gibson’s bankruptcy Neat’s CEO (and maybe some others, IDK) was able to buy it out. That CEO — Skipper Wise — is also one of the founders of Blue Microphones. So Neat Mics are independent now and decided to change their pricing strategy. Unfortunately, King Bee is not produced anymore, but Worker Bee is sold for $90, which is a steal! It has loads of glowing reviews on YouTube and the design… it’s funny, and it’s different, and I just like it. Too bad that it’s mostly black from the back (especially sitting in a cradle), so it’s a bit less interesting in a captured video than I hoped. But I bought one anyway.

Other big brands you probably know of — like Audio-Technica and Shure — are great as well. There are some other great companies I’ve never heard of before, like RØDE.

Various tests say that your listeners won’t be able to tell the difference if you have any mic costing from about $100. Do whatever you want with that information.

UPDATE. I really liked Worker Bee, both it looks and sound, but an appartment with small children is an unsuitable location for a condenser microphone: it picks up too much of a background noise. Dynamic microphones are much better at that, so I switched to RØDE PodMic. I like the sound of Worker Bee more, but slightly worse sound quality is an acceptable payment for the peace of my mind. Also, while not as intriguing as Worker Bee, it certainly doesn’t look dull. Along with a yellow cable on a stand I think it provides nice direction to my face composition-wise.

Sound processing

I mentioned that I already have an XLR interface to drive the mic — it’s Presonus AudioBox 22VSL. It’s a good interface with reasonably good pre-amplifiers. Can I complain? You bet! I’m an expert complainer²!

And the main complaint is that it’s just an audio interface. Let me elaborate.

There are a few things you could do with your voice: de-noise, compression, and equalization.

De-noise is self-describing, but important: when you stream, your laptop is going to make a lot of sound spinning coolers. This generates a lot of background noise which tires your listeners. What’s more important, it drives me mad. This could be done in a simpler way, like noise gate — just silencing signal under some volume level, and in a more intelligent way, learning noise and then trying to clean the whole duration of a recording.

Compression is a really interesting way to improve voice signal: make quiet sounds louder and loud sounds quieter, “compressing” your sound volume to some middle level. This is good because then your distance to the microphone becomes less important, and what’s especially good — changing distance to a mic is much less pronounced, with a volume level being more stable.

Equalizers are used for two purposes. First is altering the perception of recorded voice — add lows to make it sound fuller, remove them if it sounds “muddy”; add highs to make it airier, remove if it cuts your ears; alter mids for better understanding; you know, usual equalizer stuff. Another one is that mics are not perfect and the recorded voice could have some irritating frequencies. Go see Curtis’ video on that — it’s pretty interesting, but it’s a bit too hard. I tried looking at my recordings but it feels like it needs someone with a trained ear. :)

There are two ways how to do those things: either you’re doing that on your computer or it’s done in a DSP of your audio interface. DSP is vastly superior, of course: it does not add latency, there is no additional load on your CPU, and last, but not least, all your audio receiving apps will receive same processed sound, be it OBS, Zoom, browser or anything else. But, of course, 22VSL has no DSP — it’s just an audio interface! So I have to do all that in software.

For software let’s look at Windows side first. There is an app for Windows called VoiceMeeter Banana, which replaces the system mixer and allows you to do all the things you want — compressor, eq, even some de-noising. And then silently sits in the tray. Nothing like that exists for macOS! Every article on the web tells you “get a DAW and put a sound through there”. DAW is something like SoundForge or Cubase or Ableton Live or Reaper. All of them are pretty expensive (Reaper is cheapest from 60$), eat a lot of memory, have highly cryptic interfaces, and are not resident apps. Each and every one of them thinks it’s the main app of your life, eating like 10% of a core just to sit there. Ugh. GIVE ME BANANA!

Hardware way

I found two interfaces with DSP under $500: Yamaha AG03 (and AG06) for $170 and Steinberg (which is also Yamaha) UR22C (UR24C etc) for $250.

Yamaha AG03 has a 4-line equalizer and a compressor, but no de-noise, which is a shame. I guess there is a reason why eq is only 4-line and not like 30-line, but this feels underwhelming. Reviews say that pre-amp could be better there… Steinberg looks like a more conventional interface, and has a few amplifiers emulation built-in (for guitars), but just a 3-line equalizer (what). Reviews on their audio quality are also not glowing, and some reviews on Steinberg complain that it’s not working with top AMD chipsets (X470/X570), so it’s not all sunshine and rainbows.

Alternatives from other manufacturers include Behringer XR12 and Motu UltraLite mk4, which are more professional-grade devices and their size doesn’t let me splurge on that.

There is UAD Apollo Solo for $700, and it’s small, but 700?! Is it that hard?!

RØDECaster Pro for $600 is widespread among professional streamers. It gives you 4 XLR inputs and Bluetooth connectivity so you can get someone on the phone into your stream. There are DSP and equalization presets — but no way to customize them, which is a shame.

There is also a highly popular TC Helicon GoXLR, which does all processing in software. It’s not useless though: you can assign apps on your PC to faders and have hardware control of their volume. So you can regulate your voice, music, game sounds, etc — very effective to manage what your viewers hear, right on your desk with a nice tactile feedback. But it doesn’t work under macOS!

I guess you can see I’m in search of a solution, so if you have any suggestions please let me know — I even made a Discourse for comments (see after the post).

Light

I just can’t stop here. Like, I’ve had two points out of three crossed, is it possible to stop? But light is the hardest one because it’s much more about the physical world than anything else. It depends on your room, ability to place stuff around, and it can change anything drastically. Also, you can compare a camera to other cameras and buy the one you decided on, you can do the same with a mic, but with lightning, the specs of light you buy is not going to be the main thing. The main thing is placement. Tutorials say you have to have three different light sources: a key light, a fill light, and a back light.

A key light is a bright source of light that should light up your face somewhat from the side so that you have some shadows. I put a Yongnuo YN300 right behind my camera.

A fill light should be less bright, its purpose is to reduce the harshness of those shadows on your face. I have a small lamp from the other side of my display which I reflect from the wall.

And a back light is something to highlight you from a back (surprise!) to add a feeling of depth to the image. I don’t have a back light and my image is a little bit too plain because of that. I’ll have to fix that.

There are also so-called practical lights, whose purpose is to add interesting points to your background so it’s less dull. This starts to feel like I’m going too far, though, I’m not a “real” video maker yet but geared up as hell already, haha.

Various

There is also some streamer-oriented hardware I’m not very excited about, like Elgato Stream Deck. It’s a keyboard with LCD screens under each key, where you can put various actions and sequences of actions (“macros”). So it’s like Hammerspoon + Optimus Maximus. The only reason I’m mentioning it here is to tell a story of how Ecamm Live can switch screen configuration presets either from the app interface or by installing a plugin to Stream Deck. No AppleScript, no global hotkeys… it’s like someone has a blind eye on power users? Anyway, good for Elgato, its product seems to be really popular.

The same Elgato has an interesting mount system, but it’s not only not sold in Ukraine and costs considerable amounts of money, but also is constantly out of stock.

Those Elgato people seem to be the most successful company oriented on the streaming market. Their Key Lights are also good, plus the software is excellent — you can control them from your phone.

I also feel like I need to link a few channels I liked (that talk about streaming) - EposVox, Alpha Gaming and Tom Buck. I’m sure there are other sensible channels, but those are that I stayed with.

Software

Default app for streaming is OBS. It’s an open source software, so it’s free and full of capabilities, but, traditionally for open source, interface leaves much to be desired. So I decided to try out Ecamm Live, which costs money (subscription!), but is much nicer to use.

Particularly around multi-person presentations! We did an online meetup using Ecamm Interview: you start the app, it gives you a link to share and other people (up to 4 of them) can open that link and appear in the app as sources. Controls for configuring how you are displayed (side to side, picture-in-picture, only somebody) are excellent!

The way you can do that in OBS is to install obs-ndi plugin, then configure Skype to stream there (because Skype supports streaming over NDI), and then spend eternity resizing sources on your screen.

Of course, I have a few complaints for Ecamm Live. I mean, that’s the curse of computers — even if you try to do something in a best way possible, there will be someone to complain. The first one is that there is no support for VST/AU plugins. OBS allows you to process your sound, Ecamm wants you to use external software. That would be OK if there were something good available but ARGH. :) Another one is price, but that’s because I wanted Live Interview — in that case the cost is 40$/month. And the fact that you can setup multiple scenes (like just you, or just somebody, or two people together, or an intro screen), but you can’t switch between them without activating Ecamm. No global hotkeys, no AppleScript support… this looks like an oversight, really. :\

Streaming

Now that I told you the gist of what I learned over a few weeks (I’ll try to add more information, it’s hard to extract knowledge from a human brain), let’s get to the point of all that — streaming.

I did some. It doesn’t feel satisfying though. I know that to get some audience you have to persist, but the content should be interesting as well. 5 viewers suggest it’s not yet.

I still feel the itch to produce some video content, but I guess it shouldn’t be live coding. It’s not exciting to watch some guy trying to figure out what the hell is going on with that SHA1 calculation for 10 minutes. Maybe diving deep in some bigger project would be more interesting, but I’m not involved in a big open source right now, and showing innards of Kasta is something I’m wary of.

Now my idea is to do a few (shorter) videos on various technical/programming topics. Stay tuned, subscribe to my channel to get notifications, etc.