aiomixer is an application that I've been maintaining outside of NetBSD for a few years. It was available as a package, and was a "graphical" (curses, terminal-based) mixer for NetBSD's audio API, inspired by programs like alsamixer. For some time I've thought that it should be integrated into the NetBSD base system - it's small and simple, very useful, and many developers and users had it installed (some told me that they would install it on all of their machines that needed audio output). For my particular use case, as well as my NetBSD laptop, I have some small NetBSD machines around the house plugged into speakers that I play music from. Sometimes I like to SSH into them to adjust the playback volume, and it's often easier to do visually than with mixerctl(1).

However, there was one problem: when I first wrote aiomixer 2 years ago, I was intimidated by the curses API, so opted to use the Curses Development Kit instead. This turned out to be a mistake, as not only was CDK inflexible for an application like aiomixer, it introduced a hard dependency on ncurses.

X/Open Curses and ncurses

Many people think ncurses is the canonical way to develop terminal-based applications for Unix, but it's actually an implementation of the X/Open Curses specification. There's a few other Curses implementations:

NetBSD curses is descended from the original BSD curses, but contains many useful extensions from ncurses as well. We use it all over the base system, and for most packages in pkgsrc. It's also been ported to other operating systems, including Linux. As far as I'm aware, NetBSD is one of the last operating systems left that doesn't primarily depend on ncurses.

There's one crucial incompatibility, however: ncurses exposes its internal data structures, NetBSD libcurses keeps them opaque. Since CDK development is very tied to ncurses development (they have the same maintainer), CDK peeks into those structures, and can't be used with NetBSD libcurses. There are also a few places where ncurses breaks with X/Open Curses, like this case I recently fixed in irssi.

Rewriting aiomixer

I was able to rewrite aiomixer in a few days using only my free time and NetBSD libcurses. It's now been imported to the base system. It was a good lesson in why Curses isn't actually that intimidating - while there are many functions, they're mostly variations on the same thing. Using Curses directly resulted in a much lighter and more usable application, and provided a much better fit for the types of widgets I needed.

Many people also provided testing, and I learned a lot about how different terminal attributes should be used in the process. NetBSD is probably one of the few communities where you'll get easy and direct feedback on how to not only make your software work well in a variety of terminal emulators, but also old school hardware terminals. During development, I was also able to find a strange bug in the curses library's window resizing function.

The API support was also improved, and the new version of aiomixer should work better with a wider variety of sound hardware drivers.

Other happenings

Since I'm done plugging my own work, I thought I might talk a bit about some other recent changes to CURRENT.

  • Most ports of NetBSD now build with GCC 10, thanks to work by mrg. The new version of GCC introduced many new compiler warnings. By default, since NetBSD is compiled with a fixed toolchain version, we use -Werror. Many minor warnings and actual-bugs were uncovered and fixed with the new compiler.
  • On the ARM front, support for the Allwiner V3S system-on-a-chip was introduced thanks to work by Rui-Xiang Guo. This is an older model Allwinner core, primarily used on small embedded devices. It's of likely interest to hardware hackers because it comes in an easily soldered package. A development board is available, the Lichee Pi Zero. Also in the Allwinner world, support for the H3 SoC (including the NanoPi R1) was added to the sun8icrypto(4) driver by bad.
  • Support for RISC-V is progressing, including an UEFI bootloader for 64-bit systems, and an in-kernel disassembler. Some NetBSD developers have recently obtained Beagle-V development boards.
  • On the SPARC64 front, support for sun4v is progressing thanks to work by palle. The sun4v architecture includes most newer SPARC servers that are based on the Logical Domains architecture - virtualization is implemented at the hardware/firmware level, and operating systems get an abstracted view of the underlying hardware. With other operating systems are discussing removing support for SPARC64, there's an interest among NetBSD developers in adding and maintaining support for this very interesting hardware from Oracle, Fujitsu, and Sun in an open source operating system, not just Oracle Solaris.
  • A kernel-wide audit and rework of the auto-configuration APIs was completed by thorpej.
  • Various new additions and fixes have been made to the networking stack's PPP over Ethernet support by yamaguchi.
  • A new API was introduced by macallan that allows adding a -l option to the wsfontload(8) command, allowing easy viewing of the tty fonts currently loaded into the kernel.
  • ... OK, I'm not done plugging my own work: I recently wrote new documentation on using NetBSD for virtualization, Power Management, and rewrote the NetBSD Guide's sections on Networking in Practice and Audio. I also recently added support for the Neo 2 keyboard layout to NetBSD's console system - Neo 2 is a Dvorak-like optimized layout for German and other languages based on multiple layers for alphabetical characters, navigation, and symbols.
Posted at lunch time on Wednesday, May 12th, 2021 Tags: