Texas Instruments SA5532A variant of the 5532 op-amp. (Credit: Raimond Spekking, Wikimedia)
First introduced in 1979 by Signetics, the NE5532 was a pretty spiffy dual op-amp for the time with low noise and low distortion. Over the years it has become a standard part that showed up in countless audio products, and has become a so-called jellybean generic component with Texas Instruments (TI) being one of countless manufacturers.

It being such a standard, multi-sourced part makes it thus even more puzzling that TI has now decided to completely overhaul this IC in a way that makes it incompatible with even the original Signetics NE5532. These changes are covered in detail by [Dave] of EEVblog as his mind is pretty much blown at such an incomprehensible change.

The changes entail an entirely different manufacturing process and a big change in specifications, while making no change to the part number. In revision K of the TI datasheet these changes are first seen, with some specifications changed for the better, like a higher unity gain bandwidth by 2 MHz, but a much slower slew rate.

Although the 5532 op-amps are multi-sourced, there are good reasons to just stick with manufacturers like TI, as that means receiving a product change notification (PCN) when anything changes. In the PCN related to this op-amp a change to process node is noted, along with other changes, but no reasoning.

Among the other big changes are a reduction in the supply voltage from 22V to 18V, and a halving of the ESD protection from 2kV to 1kV. Although it might be slightly more efficient on the new process node this way, it clearly comes with a lot of trade-offs that make it an overall worse op-amp, while also being incompatible with the same op-amp from other manufacturers.

In the video [Dave] goes through the datasheets of this jellybean part of other manufacturers, showing that they still have the original 1980s specifications. Only one exception here was the NE5532DR from Shenzhen HuaXuanYang Electronics, whose supply rail voltage is also 18V for some reason, along with a similar internal transistor configuration that reduces the ESD resistance.

In addition to the NE5532 op-amp, it seems that TI also took an ax to the OPA134 op-amp, by removing its offset trim feature and listing the pins as ‘NC’, with a warning to not connect these pins and also worsening other specifications. This makes these similar jellybean parts incompatible, with no change to the part number. Worse is that it continues with the LMH6518, whose changes [Dave] argues might even kill oscilloscopes as they are commonly found in those.

Meanwhile the LM317M also got an overhaul, but here TI opted to give it a new part name, calling it the LM317MQ with at first glance no major degradations in the specifications, but instead some actual improvements. This makes it even more puzzling why TI didn’t give the other ICs a new part number to differentiate them from the jellybean part.

Until there’s some clarification from the side of TI, it might be a good idea to source these jellybean parts from a manufacturer that is not TI, especially when replacing these ICs in older devices.

youtube.com/embed/22ZmmZ67SMY?…

hackaday.com/2026/06/03/texas-…

For those who have never played the hit video games Undertale and Deltarune, the games are partially known for their interesting characters, many of which have eerie, surreal, and expressive designs. One of the more memorable characters from Deltarune is Tenna, a game show host of sorts whose distinguishing feature is an old television as a head, as well as a colorful suit. As a result he’s been the subject of a number of recreations by various cosplayers and makers like [BigRig Creates].

This version of the character was actually inspired by a previous build by [BunnyBii] which used an iPad as the interactive screen/face. Inside the television, though, the actual human found this to be front heavy and limiting in the ways that it could be used interactively, especially since the only way to see the outside world in this version was with a small endoscope and screen. [BigRig Creates]’s version builds on this idea but swaps out the iPad for a Raspberry Pi, allowing for much more customization, and uses a pair of Xreal glasses instead of a screen for the view of the outside world from in the television.

To get the whole costume together, the head is 3D printed with all of the electronics inside, and a game controller integrated into a handheld microphone controls the animations shown on the screen. A vibrant, custom-tailored suit with white gloves rounds out the ensemble, along with a pair of 3D-printed shoe covers since actual yellow shoes were a bit pricy. There were some interesting problems to solve along the way, specifically with regards to power management for all the electronics, but in the end it all seems to have come together quite well. [BigRig Creates] is no stranger to builds with unusual displays, though; one of our favorites was the world’s largest Nintendo 3DS.

youtube.com/embed/KR8yb54V-9g?…

hackaday.com/2026/06/03/deltar…

Previously, I looked at using the Linux video loopback system from the command line. The basic trick was simple enough: capture video from a real camera, process it with something like ffmpeg, and write the result to a fake camera device via the v4l2loopback device. Then a browser, or any camera-enabled software, sees the fake camera as if it were real. This allows you to manipulate video before sending it to the rest of the world.

That works, and for those of us who like command lines, it’s easy enough to execute. But not everyone loves the command line. In the comments, there was another obvious answer: use OBS Studio.

While OBS is excellent, it is also a bit like using a laser to chop a carrot. If you already use OBS, fine. If you only want to crop a webcam, add an effect, mirror an image, or feed a virtual camera, it can feel like a lot. If you must have a GUI, you can try Webcamoid, which sits somewhere between a simple webcam viewer and a full video production system.

Webcamoid gives you a GUI for selecting a camera, applying effects, and sending the result to a virtual camera. Conceptually, it is much closer to the command-line loopback setup from the previous post than to OBS. You are still building a pipeline from input camera to output camera, but now you can do much of it with buttons and menus instead of shell commands.

That’s in theory, of course. Implementing Webcamoid turned out to be quite the exercise. Granted, this probably varies depending on where you install software. If your distro has a clean working copy of Webcamoid and its dependencies, good for you. For everyone else, keep reading.

The Moving Parts

There are two pieces to understand. Webcamoid is the GUI application. It captures video, previews it, applies effects, and can write to a virtual camera. You also need a driver to produce the fake or virtual camera. AkVCam is one of the virtual camera drivers that Webcamoid can use on Linux. It can also use v4l2loopback, as we discussed last time. Both approaches create fake /dev/videoX devices, but their configuration models are different.

With v4l2loopback, the typical setup is command-line oriented:
sudo modprobe v4l2loopback video_nr=10 card_label="Virtual Camera" exclusive_caps=1
Then some program writes frames to /dev/video10. For example, ffmpeg can read from a real webcam and write to the virtual one. Of course, if you want a permanent virtual camera, you can make an entry in /etc/modprobe.d.

AkVCam is more structured. Instead of simply creating a generic loopback device, it uses a configuration file that defines one or more virtual cameras, their input/output relationship, and the formats they support. That sounds like more work, and in a way it is. But it also gives you tighter control over what formats the virtual camera advertises. This sometimes matters more than you might expect.

Install, Remove, Install…

The hard part of Linux webcam work is often not getting video — it’s getting every piece of the chain to agree on width, height, frame rate, and pixel format, along with matching each other’s API expectations.

I tried three different ways to install Webcamoid. First, I used the normal OpenSUSE Tumbleweed repos to install the program. It couldn’t find any cameras. My next stop was a Flatpak version. That worked well, but it is deliberately crippled and won’t even try to drive a virtual camera, directing you to install the regular version instead. Then I tried an AppImage. This seemed to work OK, but the virtual camera would never display anything but a black screen.

Note that the version on AppImageHub is old, and the source project requires payment for prebuilt binaries. I didn’t try either of those options.

I tried a lot of things to make it work. My final answer was to use the AppImage, but I had to build my own version of AkvCam from GitHub.

Even then, at first, the video output was highly pixelated. The culprit was AkVCam using the 640×480 RGB format. Upscaling created a blocky mess.

You can see what a device is doing with:
v4l2-ctl -d /dev/video3 --all
In my case, the virtual output reported:
Width/Height : 640/480
Pixel Format : 'RGB3'
scaling_mode : Fast
aspect_ratio_mode : Ignore
That explains it. “Fast” scaling usually means “not pretty,” and 640×480 is not a great starting point for modern video calls.

The fix was to simplify the AkVCam configuration. Instead of giving the virtual camera a long list of supported formats, I configured it with essentially one useful format. For example, if the pipeline is meant to be 1280×720 at 30 fps, make that the format. Do not give every program in the chain an opportunity to negotiate itself down to postage-stamp resolution.

A minimal AkVCam setup generally defines a capture device, an output device, a connection between them, and formats. In the generated config I was using, the output camera had several formats:
cameras\2\type=output
cameras\2\videonr=3
cameras\2\formats=19, 20, 21, 22, 23, 24
The problem was that format 19 was 640×480. The high-resolution formats were present, but not preferred. Reordering the list might help, but for reliability, using only the desired format is even better.

Webcamoid As A GUI Pipeline

ASCII filter in action.
Once the virtual camera driver is sane, Webcamoid works well. You select the real camera as the source, apply whatever effects you want, and select the AkVCam virtual camera as the output. The receiving application then sees the virtual camera.

Compared to the command-line approach, Webcamoid makes experimentation easier. Want to flip the image, adjust color, crop, blur, or test silly filters? That is all much easier in a GUI than in an ffmpeg or gstreamer filter chain, although I still don’t mind the command line. There’s not much difference between using Webcamoid as a friendly front end or manipulating the image as we did last time.

However, I would not oversell it. Webcamoid is not OBS. It is not really a scene compositor. If you want multiple live sources — say, a screen capture as the main image and your webcam as picture-in-picture — OBS is the obvious GUI tool. With the command line, you can easily do things like this by calling ffmpeg directly.

That’s a Wrap!

If you want a full production environment, OBS is still the right answer. It handles scenes, multiple sources, transitions, screen capture, overlays, and virtual camera output in a single application. But if you liked the command-line loopback idea and wished it had a friendlier face, Webcamoid plus AkVCam is worth a look. It gives you a GUI for the common case: one camera in, effects applied, one virtual camera out. You just need to fight through the installation and configuration with your specific setup. Hopefully, yours will be easier than mine.

As usual, Linux rewards knowing what is happening under the hood. Webcamoid can make the workflow friendlier, but v4l2-ctl is still your friend, and, at least for some people, you’ll need some Linux Fu to get it all working in harmony.

hackaday.com/2026/06/03/linux-…