Raspberry Pi Streams Music Using Only The Default Linux Tools

Getting a  home music streaming system off the ground is typically a straightforward task. Using Apple devices with Airplay makes this task trivial, but if you’re a computing purist like [Connor] who runs a Linux machine and wants to keep it light on extra packages, the task gets complicated quickly. His goal is to bring audio streaming to all Linux platforms without the need to install a lot of extra software. This approach is friendly to light-footprint devices like the Raspberry Pi that he used in his proof of concept.

[Connor] created a set of scripts which allow streaming from any UNIX (or UNIX-like) machines, using only dependencies that a typical OS install would already have. His Raspberry Pi is the base station and streams to his laptop, but he notes that this will work between virtually any UNIX or Linux machine. The only limitation is what FFmpeg can or can’t play.

We definitely can appreciate a principled approach to software and its use, although it does seem that most people don’t have this issue at the forefront of their minds. This results in a lot of software that is bulky, making it difficult to maintain, use, or even know what it does, and also makes it harder for those of us that don’t want to use that type of software to find working solutions to other problems. It’s noble that [Connor] was able to create something without sacrificing any principles.

Automated Tuning Of Linux Audio

Audio systems in Linux are terrible. You’ve never known true pain until you’ve tried to set up a recording or broadcasting workstation running Linux. I did, twenty years ago, and nothing has changed since. This wasn’t really a problem when Linux was either used in server spaces or some nerd’s battle station, but now we have small single board computers that everyone uses and wants to turn into a modular synth. Welcome to paintown, because the Linux audio stack is terrible.

For the past ten years, [Dynobot] has been working on improving audio in Linux. This is a decade of reading manuals from IBM and Oracle, and a deep knowledge of how to adjust settings so audio actually works. All of this work is now combined into a single script that improves everything. This means the priority of the Audio group is changed, the thread priority is better, the latency is better, and for anyone who wants to set up a local streaming service, the network latency is better. It’s not everything, and there’s no mention of recording multitrack audio, but we’ll accept the baby steps here.

There are two relevant Github repositories for this, the first containing audio adjustments for Debian-based systems, including the Raspberry Pi. This should work on any single board computer running Debian, and has been tested on all the Raspberry Pis, the Allo Sparky, ASUS Tinkerboard, and the Odroid C2. There’s also a version for TinyCore-based Linux systems that improves the priority of the audio threads, changes the thread scheduling from ‘whatever’ to FIFO, and improves the latency. If you’re running Linux, and you’re doing something with audio, this is what you need.

Give Your Raspberry Pi SD Card A Break: Log To RAM

The fragility of SD cards is the weak link in the Raspberry Pi ecosystem. Most of us seem to have at least one Pi tucked away somewhere, running a Magic Mirror, driving security cameras, or even taking care of a media library. But chances are, that Pi is writing lots and lots of log files. Logging is good — it helps when tracking down issues — but uncontrolled logging can lead to problems down the road with the Pi’s SD card.

[Erich Styger] has a neat way to avoid SD card logging issues on Raspberry Pi, he calls it a solution to reduce “thrashing” of the SD card. The problem is that flash memory segments wear out after a fairly low number of erase cycles, and the SD card’s wear-leveling algorithm will eventually cordon off enough of the card to cause file system issues. His “Log2Ram” is a simple Unix shell script that sets up a mount point for logging in RAM rather than on the SD card.

The idea is that any application or service sending log entries to /var/log will actually be writing them to virtual log files, which won’t rack up any activity on the SD card. Every hour, a cron job sweeps the virtual logs out to the SD card, greatly reducing its wear. There’s still a chance to lose logging data before it’s swept to disk, but if you have relatively stable system it’s a small price to pay for the long-term health of a Pi that’s out of sight and out of mind.

One thing we really like about [Erich]’s project is that it’s a great example of shell scripting and Linux admin concepts. If you need more information on such things, check out [Al Williams’] Linux-Fu series. It goes back quite a way, so settle in for some good binge reading.

Bye Bye Vi: GNU/Linux Distros Drop Support

If you grew up with Unix systems like we did, you’ll be sorry to hear the news: vi, the noble text editor that has served us so well these 40 years, is going away — from many GNU/Linux systems, anyway. As of this writing, GNU/Linux Mint, Debian, Ubuntu, and OpenSUSE — four of the five most popular GNU/Linux distributions — have all announced that they will no longer ship the ‘vi’ editor as part of their base installs. For those of us who got our start in the punched-card era and still think of files as a collection of lines instead of a stream of bytes, this is a major blow. But, we can all take some comfort in the fact that, at least for now, the stripped-down version of vim synonymous with vi on these systems will continue to be available from package repositories.

The reasons for the move aren’t entirely clear to us, but from what we can see on the GNU/Linux mailing lists, the confusing modal interface and the fact that novice (and many seasoned) users can’t figure out how to save a file and exit the program seem to have influenced the decision. Also cited were support changes expected as GNU/Linux gains in popularity. As the user base expands to include less technically-savvy individuals, fewer people will be able to fix their constant boot issues, which is the primary use-case for vi. Replacing the self-help model will be a support infrastructure where users can take their machines to “GNU/Linux Geniuses” who will solve the problems for them.

Continue reading “Bye Bye Vi: GNU/Linux Distros Drop Support”

Reverse Engineering A Modern IP Camera

Security cameras used to be analog devices feeding back into a room full of tiny screens and commercial grade VCRs. As technology moved forward, IP cameras began to proliferate. Early models simply presented a video stream and configuration page to the local network. Modern models aimed at the home market differ however. More often than not, configuration is through a strange smartphone app, and video is accessed through third-party servers. It’s all a bit oblique, and so [Alex] decided to take a look under the hood. 

The exploration begins externally, with [Alex] capturing data sent to and from the camera with Wireshark. Straight away, red flags are raised. For as yet unknown reasons, the camera attempts to resolve Google, Facebook and Alibaba servers over DNS. Disassembly then follows, revealing that a serial terminal with root access is available. [Alex] uses this to probe around, uncovering the firmware update script and a way to decrypt said updates.

The work thus is a great example of how to approach hacking a given device from first principles. The overall goal is to find a way to gain complete control over the camera, reprogramming it to serve up video as [Alex] wishes, rather than to a distant third party server. It’s not the first time we’ve seen an IP camera hacked, and we doubt it will be the last. If you’ve got one cracked, be sure to let us know.

Octavo Systems Shows Off With Deadbug Linux Computer

Once upon a time, small Linux-capable single board computers were novelties, but not anymore. Today we have a wide selection of them, many built around modules we could buy for our own projects. Some of the chipset suppliers behind these boards compete on cost, others find a niche to differentiate their product. Octavo Systems is one of the latter offering system-in-package (SiP) modules that are specifically designed for easy integration. They described how simple it would be to build a minimal computer using their SC335x C-SiP, and to drive the point home they brought a deadbug implementation to Embedded World 2019. [Short video after the break.]

Most of us encounter Octavo modules as the heart of a BeagleBoard. Their increasing integration made tiny wonders like PocketBeagle possible. But bringing out all those pins for use still required a four-layer circuit board. Octavo’s pitch for hardware professionals center around how easy integration saves time for faster time to market, and fortunately for us easy integration also translates to a more accessible device for our projects. It’s one thing to publish a document describing a hypothetical single-layer PCB for an Octavo module, it’s quite something else to show that concept in action with no PCB at all.

Of course, this little machine only has access to a fraction of the module’s functionality, and it is certainly overkill if the objective is just to blink a few LEDs. If so, we’d just use 555 timers! But it does show how simple a bare bones “Hello World” machine can be built, removing intimidation factor and invite more people to come play.

One of the three top winners in our circuit sculpture contest was a wireframe Z80 computer. There’s quite a jump from a Z80 to an Octavo SC335x, but we’ve already seen one effort by [Zach] over Supercon 2018 weekend to build a deadbug computer with an Octavo module. It won’t be long before someone one-ups this minimalist LED blinker with something more sophisticated and we can’t wait to see it. Continue reading “Octavo Systems Shows Off With Deadbug Linux Computer”

Hackers Turn Hard Drive Into Microphone That Can Listen In On Your Computer’s Fan Whine

As reported by The Register, hackers can now listen in on conversations happening around your computer by turning a hard drive into a microphone. There are caveats: the hack only works if these conversations are twice as loud as a blender, or about as loud as a lawn mower. In short, no one talks that loud, move along, nothing to see here.

The attack is to be presented at the 2019 IEEE Symposium on Security and Privacy, and describes the attack as a modification of the firmware on a disk drive to read the Position Error Signal that keeps read/write heads in the optimal position. This PES is affected by air pressure, and if something is affected by air pressure, you’ve got a microphone. In this case, it’s a terrible microphone that’s mechanically coupled to a machine that has a lot of vibrations including the spinning platter and a bunch of fans inside the computer. This is an academic exercise, and not a real attack, and either way to exfiltrate this data you need to root the computer the hard drive is attached to. It’s attacks all the way down.

The limiting factor in this attack is that it requires a very loud conversation to be held near a hard drive. To record speech, the researchers had to pump up the volume to 85 dBA, or about the same volume as a blender crushing some ice. Recording music through this microphone so that Shazam could identify the track meant playing the track back at 90 dBA, or about the same volume as a lawnmower. Basically, this isn’t happening.

The interesting bit of this hack isn’t using a hard drive as a microphone. It’s modifying the firmware on a hard drive to do something. We’ve seen some hacks like this before, but the latest public literature on hard drive firmware hacking is years old. If you’ve got a tip on how to hack hard drives, even if it’s to do something that’s horribly impractical, we’d love to see it.