Replacing PulseAudio with PipeWire in KDE Neon

For some time now I’ve been running KDE Neon on my desktop Linux machine, and I’m loving it. I love getting the Latest and Greatest KDE features, on top of a boring and familiar distro like Ubuntu LTS.

I’ve been following PipeWire from a distance for a while, and it seemed to be ready for prime time so, after getting some choppy audio from by Bluetooth headphones I thought I’d give it a try.

It’s actually fairly easy, and while I was at it I decided to use a PPA which will allow us to use a more recent PipeWire version.

Without further ado:

  sudo add-apt-repository ppa:pipewire-debian/pipewire-upstream
  sudo apt full-upgrade 
  sudo apt install pipewire-pulse libspa-0.2-bluetooth
  systemctl --user --now disable pulseaudio.{socket,service}
  systemctl --user mask pulseaudio
  systemctl --user --now enable pipewire{,-pulse}.{socket,service}
  pactl info | grep '^Server Name'

That’s it really. The last command will show something like Server Name: PulseAudio (on PipeWire 0.3.49) confirming you are running PipeWire as your PulseAudio server!

So far, upon switching to PipeWire my audio is no longer choppy and the volume meter is correct (it used to display 100% while clearly not being at 100%), so count me in as a happy PipeWire user.

PipeWire Original Repo

pycares 4 released, mistakes were fixed

pycares is a Python module which provides an interface to c-ares. c-ares is a C library that performs DNS requests and name resolutions asynchronously.

Finally, after a long time, I managed to make a new pycares release. Introducing pycares 4.0.0. This is an important one (note the major number change!) here are the most important features from this release:

  • Dropped support for Python <= 3.5, the supported Python versions are 3.6-3.9
  • Added getaddrinfo()
  • Added support for CAA queries
  • Updated c-ares to the latest version
  • Dropped custom patches from the embedded c-ares library
  • Added ability to use the system provided c-ares library
  • Refactor automation of the release process and wheel generation and upload to PyPI

I’m looking for help maintaining this module further, if you are interested, please comment here.

While working on this release I had some thoughts and reflections, if you are interested in those come with me in a trip down memory lane.

Read more

pycares 3.1.0 released!

Finally back blogging… it’s been a while. Today I bring you a new pycares release: 3.1.0

pycares is a Python module which provides an interface to c-ares. c-ares is a C library that performs DNS requests and name resolutions asynchronously.

This release was relatively small, but I’m really happy about the automation work that I managed to do before the release, which should help with making the next releases faster and better.

Thanks to the automation work this release includes binary wheels for Python 3.5-3.8 on Windows, macOS and GNU/Linux.

How is this done? Well, pycares is now using 3 different CIs:

  • Travis: runs tests on GNU/Linux and it builds release wheels for all 3 platforms (this las key bit is new!)
  • GitHub Actions: runs tests on macOS
  • AppVeyor: runs tests on Windows

Thanks to these 3 free services, I couldn’t have done it without them! ❤️ Also huge thanks to Joe Rickerby for creating cibuildwheel it really made this a whole lot easier.

Skookum JS 18.6.0 released!

2 years have passed since the last Skookum JS release, so here we are, with a new release, and (maybe) a new plan.

But first, for those who don’t remember: what is Skookum JS (sjs)?

Skookum JS (or sjs for short) is a simple JavaScript runtime built on top of the Duktape JavaScript engine, with a simple POSIX-y API.

I guess the first question is “what’s with the version number?”. Fair point. I decided to switch to calendar versioning and give it a try, so since we are in June 2018, it’s time for a 18.6.0.

The focus of this release was to add more features and make it more CommonJS-alike, as I mentioned on my previous sjs post, but as time passed I realized I was wrong.

When I designed sjs I got heavily inspired by the runtime I knew the most: Python. This means having a small binary and “native addons” as shared libraries, in addition to a sizeable standard library. That’s all great, but it brings significant trouble because all those need to be in some path which the runtime will query, take (potentially) long time to load, and having multiple versions installed side by side is not easy. By contrast, Node takes the single binary approach: all the native modules needed for the standard library are part of the single binary, and so is the standard library itself. So I decided to do the same.

With this release, sjs is a single binary with all previous native modules embedded, as well as the standard library. I’d like to point out how I went about embedding the standard library, because that was a fun discovery: incbin. Incbin uses assembly to embed binaries into an executable, so that’s how I chose to embed all the JavaScript in the standard library onto the binary? Ugly? Maybe. Does it work? You bet!

sjs remains a toy project I like to hack on every now and then, and it’s now clear to me that my original design was flawed in many levels, so with this release I’m fixing one of those mistakes. Hopefully there will be more to come!

You can check the release notes here, check the code on GitHub, and check the documentation here.

Streaming a webcam to a Jitsi Meet room

Every so often I see the following question:

How can I stream a webcam to a Jitsi Meet room?

Wait, isn’t this just like “joining” a room? Not quite. One may want to have some dedicated contraption streaming a webcam to a room. Think of a homemade security camera system or something alike.

This probably gets asked for other WebRTC conferencing services too. The way I see it, there are 2 ways to go about it:

  • Buid a way (on the server) to accept a stream sent with ffmpeg or gstreamer, and broadcast that.
  • Use a browser.

I know what you’re thinking: “Saúl, running an entire browser is overkill!”. Maybe. It will consume more RAM, yeah, but I argue the dominating factor here is video capture and encoding, not JavaScript execution, the DOM and other shenanigans.

Also, when all you have is a hammer, everything looks like a nail.

With the advent of headless mode in both Chrome and Firefox, this option looks more enticing than ever, so let’s roll our sleves and give it a shot.

I’m going to use Google’s puppeteer library, which runs Chrome headless to join a Jitsi Meet room. Being a headless client, we can cut down some of Jitsi Meet’s features in order to reduce the required resources:

  • No need to receive video
  • Disable simulcast (only encode video once)
  • No audio levels

I could probably add some more, but those should be enough to make a difference. The astute amongst you may think “but Saúl, disabling simulcast means every streamer will send an HD stream, I can’t cope with so many!”. Great point! Here we are going to rely on adaptivity, so no need to worry, if the client can only receive a single HD stream, the rest will be suspended, but you can switch between them just fine!

Here is the code (I also got to play with async / await for the first time, which is pretty cool):

https://gist.github.com/saghul/179feba3df9f12ddf316decd0181b03e

My original intent here was to use some inexpensive (and not very powerful) device such as the Raspberry Pi, but alas puppeteer doesn’t yet support ARM devices 🙁

Happy streaming!

Upcycling an old Mac Mini with ChromiumOS

I’ve had an (now) old Mac Mini 2,1 for about 10 years now and it has served me well. It used to be my desktop machine, then media center, then small home server.

My trusty old friend

At some point I realized I had moved all services except the printing service, so I thought it was about time I decommissioned it, but it deserved one last shot, so here we are 🙂

Read more

pyuv 1.4.0 released

Today I finally found some time to put together a new pyuv release! Oh, but what is pyuv? I’m glad you asked!

pyuv is a Python module which provides an interface to libuv. libuv is a high performance asynchronous networking and platform abstraction library.

This a big one. Here are some of the highlights:

  • PyPy support (finally!)
  • CPython 3.6 support
  • Overhauled build system (we no longer rely on the libuv build system)
  • Linux and Windows wheels published on PyPI
  • New co-maintainer! Say hi to Marc Schlaich!

See the full changelog here.

I just realized the last release was over a year ago. Time flies! At any rate, here it is now. Enjoy!

How to get AppRTCMobile for Android

More often than not, when reporting issues in the WebRTC bug tracker, you’ll be asked to reproduce it with AppRTCMobile (the “reference” or “demo” app of sorts). This may be a hassle because you might not be able to build it yourself.

Worry not! Google archives all the apk builds from their CI system and you can download it from there. I’m not sure if this publicly available information, but I couldn’t find it anywhere, so here we go!

  • Go to this site and pick the Android builder you desire
  • Then click on the latest successful build (this one for example)
  • Next, locate the “gsutil upload” step (it’s 22 at the time of this writing)
  • There should be a “gsutil.upload” link below it (this one for example)
  • Click it to download the file!

The downloaded file is a zip file containing the apk. Installing it is simple, connect your Android device and do:

adb install AppRTCMobile.apk

Done!