We mentioned last week how robotaxi provider Cruise was having a no-good, very bad week, after one of their driverless taxis picked a fight with a semi, and it was revealed that amorous San Franciscans were taking advantage of the privacy afforded by not having a driver in the front seat. It appears that we weren’t the only ones to notice all the bad news, since California’s Department of Motor Vehicles issued an order to the company to cut its robotaxi fleet in half. The regulatory move comes after a recent Cruise collision with a fire truck, which injured a passenger in the taxi. Curiously, the DMV order stipulates that Cruise can only operate 50 vehicles during the day, while allowing 150 vehicles at night. We’d have thought the opposite would make more sense, since driving at night is generally more difficult than during daylight hours. But perhaps the logic is that the streets are less crowded at night, whereas daytime is a more target-rich environment.

# A Better Playlist Shuffle Algorithm Is Possible

When listening to music, most of us reach for the shuffle button on the regular. This is then followed by a bunch of frustrating skips as we hear the same four or five tracks that have been regularly replayed for the last few days. [Ron Miller] wants to fix unsatisfying shuffles, and he’s developed the Miller Shuffle algorithm to do so.

[Ron] realized that many big name streaming services use incredibly simple algorithms to choose shuffled songs. This can often be as simple as songIndex=random(NumOfSongs). The problem with this is that even with a good random number source, you’ll get a lot of premature repetitions. If your music service doesn’t keep track of your shuffle-point between sessions, you’ll often get annoying repeats if you’re listening on a day-to-day basis.

To fix this, the Miller Shuffle algorithm aims to offer good randomness and no repeats without the excess resource usage of the commonly-cited Fisher-Yates algorithm. [Ron] explains it like this: “The way the algorithm works its magic is by utilizing multiple computations which are ‘symmetrical’, in that the range of values which go in are the same values which come out albeit in a different order.” Since its a deterministic fixed list, there’s no need to keep track of what songs have already been played to avoid repeats. Instead, the player must simply step through the index in order, one track after another. As long as a referenced index point is maintained, along with an ID of the shuffle order being used, no repeats should come up.

If you’re implementing a shuffle algorithm for your own music, you might want to give [Ron’s] work a look. He’s taken into account details like resource usage and small and large list sizes, to account for implementation issues for even very large streaming services. If you’re more interested in shuffling cards than songs, though, we can help there too!

# Spotify Player Brings Back Physical Media

Digital music has made keeping all your tunes with you a lot more convenient, but have we lost something with dematerialization? [Jordi Parra] felt that there was something lacking with the digital music experience and designed a Spotify player with a tactile interface.

Specific playlists are selected via small RFID tags that look like a cross between a MiniDisc and a vinyl record. As this is a prototype, an Arduino reads the RFID tag, but needs a computer to actually play the Spotify playlist. Future iterations could include an integrated speaker and run libspotify to create a self-contained device.

While there is still work to do for a fully seamless experience, we love the details in the industrial design of this project. Clean simple lines and a combination of wood and more modern materials make this feel like a timeless piece of tech. Definitely check out the full photo gallery including shots of the really impressive packaging.

Want more digital music with a tactile interface? Check out this MP3 Player Shelf or a Simple Internet Radio Transplant.

# Cracking The Spotify Code

If you’ve used Spotify, you might have noticed a handy little code that it can generate that looks like a series of bars of different heights. If you’re like [Peter Boone], such an encoding will pique your curiosity, and you might set out to figure out how they work.

Spotify offers a little picture that, when scanned, opens almost anything searchable with Spotify. Several lines are centered on the Spotify logo with eight different heights, storing information in octal. Many visual encoding schemes encode some URI (Uniform Resource Identifier) that provides a unique identifier for that specific song, album, or artist when decoded. Since many URIs on Spotify are pretty long (one example being `spotify :show:3NRV0mhZa8xeRT0EyLPaIp` which clocks in at 218 bits), some mechanism is needed to compress the URIs down to something more manageable. Enter the media reference, a short sequence encoding a specific URI, generally under 40 bits. The reference is just a lookup in a database that Spotify maintains, so it requires a network connection to resolve. The actual encoding scheme from media reference to the values in the bars is quite complex involving CRC, convolution, and puncturing. The CRC allows the program to check for correct decoding, and the convolution enables the program to have a small number of read errors while still having an accurate result. Puncturing is just removing bits to reduce the numbers encoded, relying on convolution to fill in the holes.

[Peter] explains it all in his write-up helpfully and understandably. The creator of the Spotify codes stopped by in the comments to offer some valuable pointers, including pointing out there is a second mode where the lines aren’t centered, allowing it to store double the bits. [Peter] has a python package on Github with all the needed code for you to start decoding. Maybe you can incorporate a Spotify code scanner into your custom Spotify playing mini computer.

# Building A Custom Linux Single Board Computer Just To Play Spotify

If you want to hook up an existing stereo or amplifier to Spotify, there’s a fair few options on the market. You can even just order a Raspberry Pi and be done with it. [Evan Hailey] went his own way, however, and built his own Spotify Box from scratch.

Housed inside a tidy little wooden enclosure of his own creation, the Spotify Box can turn any amplifier into a remote-controlled Spotify player via Spotify Connect. Pick the songs on your smartphone, and they’ll play from the Spotify Box as simple as that.

The project is based on the Allwinner V3S, a system-on-chip with a 1.2GHz ARM-Cortex-A7 core, 64MB of DDR2 RAM, and an Ethernet transceiver for good measure. There’s also a high-quality audio codec built in, making it perfect for this application. It’s thrown onto a four-layer PCB of [Evan’s] own design, and paired with a Wi-Fi and BlueTooth transceiver, RJ-45 and RCA jacks, a push-button and some LEDs. There’s also an SD card for storage.

With a custom Linux install brewed up using Buildroot, [Evan] was able to get a barebones system running Spotifyd while communicating with the network. With that done, it was as simple as hooking up the Spotify Box to an amp and grooving out to some tunes.

Along the way, [Evan] learned all about compiling drivers and working with embedded Linux, as well as how to take a bare SoC and build it into a fully-functional single-board computer. When someone else says they “made” a Spotify player, he presumably gets to clear his throat.

If you fancy retro computers, consider interfacing Spotify with your classic Mac instead!

[Thanks to Jay Carlson for the tip!]

# Otters Deliver A High Power Stationary Audio Experience

Our favorite raft of otters is back at it again with another display of open source audio prowess as they bring us the OtterCastAmp, the newest member of the OtterCast family of open source audio multitools. If you looked at the previous entry in the series – the OtterCastAudio – and thought it was nice but lacking in the pixel count or output power departments then this is the device for you.

The Amp is fundamentally a very similar device to the OtterCastAudio. It shares the same Allwinner S3 Cortex-A application processor and runs the same embedded Linux build assembled with Buildroot. In turn it offers the same substantial set of features and audio protocol support. It can be targeted by Snapcast, Spotify Connect or AirPlay if those are your tools of choice, or act as a generic PulseAudio sink for your Linux audio needs. And there’s still a separate line in so it source audio as well.

One look at the chassis and it’s clear that unlike the OtterCastAudio this is not a simple Chromecast Audio replacement. The face of the OtterCastAmp is graced by a luscious 340×800 LCD for all the cover art your listening ear can enjoy. And the raft of connectors in the back (and mountain of inductors on the PCBA) make it clear that this is a fully fledged class D amplifier, driving up to 120W of power across four channels. Though it may drive a theoretical 30W or 60W peak across its various outputs, with a maximum supply power of 100W (via USB-C power delivery, naturally) the true maximum output will be a little lower. Rounding out the feature set is an Ethernet jack and some wonderfully designed copper PCB otters to enjoy inside and out.

As before, it looks like this design is very close to ready for prime time but not quite there yet, so order at your own risk. Full fab files and some hints are linked in the repo mentioned above. If home fabrication is a little much it looks like there might be a small manufacturing run of these devices coming soon.

# You Otter Be Able To Stream That Audio: Open Hardware Eclipses Chromecast Audio

When Google halted production of the Chromecast Audio at the start of 2019, there was a (now silent) outcry. Fans of the device loved the single purpose audio streaming dongle that delivered wide compatibility and drop-dead simplicity at a rock bottom \$35 price. For evidence of this, look no further than your favorite auction site where they now sell for significantly more than they did new, if you can even find an active listing. What’s a prolific hacker to do about this clear case of corporate malice? Why, reinvent it of course! And thus the Otter Cast Audio V2 was born, another high quality otter themed hack from one of our favorite teams of hardware magicians [Lucy Fauth, Jana Marie Hemsing, Toble Miner, and Manawyrm].

The Otter Cast Audio is a disc about the shape and size of standard Chromecast (about 50mm in diameter) and delivers a nearly complete superset of the original Chromecast Audio’s features plus the addition of a line in port to redirect audio from existing devices. Protocol support is more flexible than the original, with AirPlay, a web interface, Spotify Connect, Snapcast, and even a PulseAudio sink to get your Linux flavored audio bits flowing. Ironically the one thing the Otter Cast Audio doesn’t do is act as a target to Cast to. [Jan] notes that out of all the protocols supported here, actual Cast support was locked down enough that it was difficult to provide support for. We’re keeping our fingers crossed a solution can be found there to bring the Otter Cast Audio to complete feature parity with the original Chromecast Audio.

But this is Hackaday, so just as important as what the Otter Cast Audio does is how it does it. The OtterCast team have skipped right over shoehorning all this magic into a microcontroller and stepped right up to an Allwinner S3 SOC, a capable little Cortex A7 based machine with 128 MB of onboard DDR3 RAM. Pint sized by the bloated standards of a fully interactive desktop, but an absolutely perfect match to juggling WiFi, Bluetooth, Ethernet, and convenient support for all the protocols above. If you’re familiar with these hackers’ other work it won’t surprise you that what they produced here lives up to the typical extremely high quality bar set by such wonders as this USB-C adapter for JBC soldering iron handles and this TS-100 mainboard replacement.

It sounds like a small production run might be on order in the future, but until then production files optimized for a particularly popular Chinese manufacturer are provided, with complete BOM and placement files. It sounds like turnkey production costs from that manufacturer are a shockingly reasonable \$10 (total) per unit with most components, and come to a still-reasonable \$22 with the remaining self-sourced components manually installed.

For a demo of the finished goods, check out the tweet embedded after the break.