Replacing the Logitech Squeezebox with something more modern

[TSZ]

WARNING - HARD WORK AHEAD
(not for the faint of heart, or folks who are not familiar with Linux or the working end of a soldering iron)

So first of all a little bit of history
Some folks have an awesome device, a Logitech Squeezebox. Now that thing is old, even by today's standards. The software is flaky, the device even more so.
The unit I have here just refuses to work, and I've spent days trying- it probably has something to do with IPv6 or a lack of support for DNS lookups and how they are done now.
It stopped working in 2016 or thereabouts, and won't work on FTTH connections at all. Logitech discontinued it long ago, and there's no support.
To cut a long story short, the desktop server software cannot see Logitech's servers 9 times out of 10, and the device itself cannot see the desktop server even via LAN or Wireless...
So in short, there's a networking issue in the device that cannot be resolved.

Here is what the unit looks like...

Now if we look inside the receiver unit.. oh my gosh, that's OLD SHIT...

So basically they have a very old Ubicom CPU (that company no longer exists) and the SoC is designed for ADSL routers as I found out, and then, as things were done in 2003, a Wi-Fi module is plugged in on the PCI bus.
Old flash memory, old SDRAM, and a CPLD (Xilinx chip) to tie everything together, plus a REALTEK CODEC IC.

But but but S2K, you CAN build a Linux kernel for this!!!

Er no I can't, because, compiling U-BOOT for this ancient chip is not possible. Its not supported, so there's no real way of getting Linux on there and there's no toolchains for that ancient device.
The last bit of info on a toolchain dates 2006 and the chip has been discontinued for over a decade, so no chance!

Solution- Design a new Device

Now, since I am very familiar with Quad core ARM Cortex CPUs, it has occurred to me that I could probably compile Linux for one of those chips and make something like this
and yes, this is exactly what I am going to do- I am going to build a Squeezebox similar to this, except I will do the following differently.

- That remote control, while it is nice and all, is a power hog, and also very expensive to make. I don't need a remote control with a screen.
I will likely drop the fricking thing and then create new swearwords because I dropped it.

- Like other models predating this one, I'd rather put the display in the receiver, and use that to display the details of what I am listening to, and use a simple remote to
control it. And because I listen to music of various origins, the one important aspect is that whatever display is used, it can handle JIS text (Japanese).
This may or may not be an issue, I think to avoid having to maintain a massive 2000+ character embedded font, and being able to use a regular character VFD (the graphics VFDs are pricey)
I will opt to just rename affected tracks to romaji <- SUBJECT TO CHANGE

- And to appease the audiophiles who constantly take a stab at me and declare that my audio designs are shit,
you can plug in an external soundcard like the ASUS XONAR and bypass the internal audio chain completely and then STFU!

So now you have the basic jist, let's get on with it. The next updates to the thread will contain progress made on the project.

 

[TSZ]

Prototyping Stage - Breadboard (15/01/22)

So to do the heavy lifting, we need a good processor, and preferably an embedded system that can run Linux.
The reasons for that are many, but the most important ones are:
- Networking
- File system operations
- Audacious

To write a networking stack in C is no easy feat, and even so, without an OS, you run into many issues, which is why most network stacks are designed to run on some kind of real time OS. Ditto for file systems and all that kind of stuff.
Then to play audio from a network share, you need a means to connect to Windows shares (for most users) and NAS drives and the like and Linux has this all built-in.
Then there's the question of what to use to play all kinds of audio formats. The answer is an app I use on the PC, called Audacious. Its open source and has been ported to Linux, and specifically ARM.

With Linux comes decades of knowledge, ready to run code, and usually its all well maintained. So it's a no-brainer, and this is the reason why so many products on the market, run Linux under the skin- most people have no idea!
Linux also brings remote access, the ability to upgrade the unit for years, etc etc etc..

So what we do first is prepare our breadboard with some power. Onboard is a cheap and readily available DC-DC converter of the buck type, which I have added, and jumpered up. Then I added necessary jumpers, capacitors, a 3.3V regulator and connector to the DC wall wart, so that it can power the OrangePi Zero properly...

And this is the result of today's work:

As easy as that, on a breadboard...

The next step is to connect a serial cable and install an OS image on an SD card into the SD card slot, so this is a simple matter. During the week I built the Armbian Linux image using my desktop that is dual-boot and running Ubuntu 20.04 LTS. That is a highly technical operation I won't bore you with here.

I prepared the image as follows:

When it is finished writing the image, we BOOT Linux from the SD card itself. Most modern ARM SoCs have had this facility for years...
Before we boot, we open up a terminal emulator on a PC or Mac (in this case I used CoolTerm) and we use an FTDI-TTL-232 3V3 cable (header was modified and soldered on as per page 56 of THE SONIC ZONE 2021 Yearbook).

If all is well, and we insert the SD card and then 12V DC is applied to the board (AFTER we adjusted the DC-DC converter) we should see activity on the terminal emulator... Sweet

The above is the first stage of booting, before it even loads the Linux kernel, in fact its U-Boot stuff
[U-boot is a loader for Linux operating systems in embedded world]

We let it boot with the device connected to the network and having internet access, we take notice of what IP was assigned to the device (it always boots with DHCP = on and will display the IP when it gets one from the router). And we get to this point, the board is running and we can SSH into it and set the passwords. It will ask for the root password to be changed and then to create a user account. I did that already prior to this screenshot.

Things to note:
CoolTerm doesn't do emulation correctly so it won't be of any use.. as you saw I couldn't even enter a password.

So this is friggen cool, we have a full blown Linux system here.

Next Steps

Next things to be done are as follows:
a) Choose ancillary hardware components i.e. display, and microcontroller to handle the display and IR and control
This is done the way its done in consumer electronics, we don't put all our eggs in one basket, it also simplifies design (as will be evident later)
b) Configure Linux, particularly the GPIO libraries, firmware, and install necessary software
c) Install and Configure Code:Blocks on a Windows machine and get it working with compiling C applications for the armhf target

 

[TSZ]

Basic Code Compilation 16-01-22

In case you are wondering, yes, the C code is developed and compiled on a
regular Windows 7 machine which is in fact my gaming machine. The magic is of course
that its cross-compiling for a different architecture.
The IDE used is Code::Blocks with the armhf-GCC compiler suite installed.

So we're going to write a daemon that controls the other applications and services the buttons and the display on the front.
To ensure we can compile for the target (before we rope in libraries to control GPIO etc.. ) we compile a simple "Hello World"
type application.

And here it is, nothing particularly heavy (as Donald Stewart* would say):

So to get this onto the OrangePi Zero, I simply copied the executable to a flash drive, mounted the flash drive on the OrangePi, and copied the file to the home directory (in this case /home/user).

And I then ran it, successfully and as you can see, the logfile was written successfully.

* Donald Stewart is a recurring character in the British comedy Benidorm

 

[TSZ]

Short update 18 / 01 / 22
So I wanted to use this display (VFD) for the project...

Turns out that Futaba (one of the few manufacturers) have completely ceased production of VFDs. Found this out because I wanted to do an availability check (and considering I bought this in 2019 for a similar project). I found this today on their website...

Oh man THIS SUCKS

The timing of the above (if you read the PDF) seems to be coincidental with the pandemic kicking butt.

So now I will be forced to use a graphics display of the LCD variety.. with it looking consequently CHEAP like its MADE IN CHINA!
Not cool!

Have a lot of different graphics LCD displays, so let's see which one is suitable here, am thinking 160 x 64 or thereabouts.

 

[TSZ]

Update: 20/1/22 (Late week update before the terrible heat)

Since this weekend coming is a no-go for anything to be done in the workroom (due to high temperatures that will lead to premature hardware failures if I try / me not prepared to sit and sweat out of every orifice) I am doing it now.

I want to see how well mapping a network share to this device would work. This is because it was a spectacular failure with the Logitech unit and I don't want to repeat mistakes.

So the first step was to install a package called smbclient

SSH into the OrangePi Zero and execute:

sudo apt-get update
sudo apt-get install smbclient

Then when the install is finished, we use it, as a first step we look and see if we can list the shares on a known host:
NOTE: I have a box in my home, that has no usernames/passwords because requiring that kind of security with kids/others is asking a bit much, so I am aware of the risk!

So simply I execute:
smbclient -L \\<hostname as seen in Windows Explorer or macOS Finder>

Complains about no workgroup available, but it does show my shares... Cool! So you see where I am going with this?
On my gaming PC, I've used a Windows feature - Map Network Drive, to map a part of the file server to a drive called Z.
In there is all my ripped CDs and other music I listen to.

But to make this possible I need another piece of software... so we install cifs-utils

sudo apt-get install cifs-utils

Now, the intention is to mount a specified share to /media on the Linux filesystem. That way Audacious can find the files in the master play list (more about Audacious later). So we're going to set up the mountpoint to my music archive on the server behind me...

So under the /media directory I made earlier, I simply create a subdirectory called "sources"

mkdir /media/sources

And then we need to mount the desired directory on the file server... Now CIFS needs the IP address (I will write a hack to get the IP against the Windows share hostname later), so I mount it with the IP address of the box... THIS CAN GO HORRIBLY WRONG, so we hold thumbs and it works...
And when we do a directory listing ls of a known directory, its actually all there... wow!

We are logically one step away from playing back audio tracks!!

Q: Why use NSP for development?
A: They sell their music directly to the end consumer, in 24bit 96kHz format, (NO BOOTLEGS or pirated tracks) which is a very good exercise for development of better-than-CD-quality playback (to appease the audiophiles).

 

[TSZ]

Notes:
The Armbian OS build for the OrangePi zero omits a lot of features. For a start, the pulseaudio mixer is absent.
So it has to be installed before Audacious is installed...

 

[TSZ]

Update 21-01-2022 - BET YOUR ASS IT WORKS!

Successful playback from a playlist has been achieved using Audacious and audtool from the command line!

As always there are caveats:

Problem - Unacceptable noise on Line Out
The designer of the OrangePi Zero lacks skills, the audio signals are routed close to a TV OUT, so noise has been coupled into them, which is not acceptable

The noise is audible if playback is stopped and nothing can remove it.
Plan B: design dedicated audio subsystem and hang that off a USB bus.
Now the good news is I have designed a sound card before, in 2019, we will re-use that design.
At this point before I proceed with software development I want the audio up to standard. That will be my focus from now until its done.

Problem - audtool (and Audacious) only produce audio output if run as root

This may (or may not) be a problem. I will be controlling them with an application and I can easily run the program as a root user which
seems to remind me of problems I have had long ago with Raspberry Pis and USB LTE sticks

Audacious Command line Cheat sheet: Ubuntu Manpage: audtool - a small tool to control Audacious from the command line.

 

[TSZ]

The first proper playback session can be viewed here:
lbry://Squeezebox-Replacement-First-Playback

Odysee

Explore a whole universe of videos on Odysee from regular people just like you!

odysee.com

Sorry I cannot upload to YouTube as those fuckers will hit me with a copyright strike because of the music played back

 

[TSZ]

Update 24-01-2022 (Can't work because of Corporate Bullshit Update)

So its one of the worst days at work, lost my temper and told them to fix their shit and call me when they have done so. This gives me time now to update this project. I don't want to talk about work but I do want to talk about all the things I've worked out with this project.

Keeping in mind the Audiophiles

In most cases, the users of the Logitech Squeezebox were audiophiles. Indeed the unit I have is on loan from an audiophile in JHB who cannot get it to work anymore (I am offering to build a replacement using this very project). I had a look at the soundcard I designed in '18 briefly and its a simple beast, it only does up to 16bit/48kHz. Additionally because the clock is recovered from the USB bus, these same people have a prejudice against the chip. Remember, these people are very very very obsessed with clock jitter, their brains think that any clock jitter, however small = THD increase (which in practice is not really the case), and no technical argument can convince them otherwise.
Meanwhile the same clock recovery mechanisms were used for decades (and continue to be used) in telephony networks including LTE and 5G, with great success. Temperature is the bigger issue, and overall analog design technique but I digress...

Now regardless of audiophiles or not, there is a danger of aliasing with the FLAC files I have. A quick experiment on my desktop PC confirms that, with all of the FLAC albums I bought from Bandcamp (the default is 96/24) there is noticeable (as in I can hear it) aliasing when played back on this sound card. Its even worse with 192/24 files. There is only one way out of this, we need to leverage the S/PDIF output of the AllWinner chip, and we need to design a receiver for that and connect that to a D/A converter.

On the OrangePi Zero LTS, this S/PDIF pin is used for something else, so stay tuned for the fun and games to make that pin work as S/PDIF out and moreover, making a connection to it (it does not route to any pin on the board)

 

[TSZ]

Planned Strategy 26-01-2022

Digital Audio
I noticed that whenever Audacious was playing, that a RED LED would turn on, on the OrangePi. So I did some digging on the schematic and low and behold, they connected an LED on that GPIO pin to indicate "status".
When I configured the Linux kernel to enable S/PDIF it also in turn configured that GPIO to be the S/PDIF output. This means its likely working. I will need to remove the LED and confirm the signal integrity of the data and that its suitable.

So the plan with this S/PDIF is to connect that to a DIR (Digital Interface Receiver) and then let that send the digital audio to a suitable D/A converter. I happen to have a CS8416 which is up to the job. Breadboarding this may be tricky but I will get it right. For a start I don't have an adapter to convert TSSOP28 to DIP (and I can't get one right now) but it is what it is, we will make a plan.

LCD DIsplay
The LCD Display troubled me, I had a look around and they're crazy expensive if they're not the Chinese favourite (128 x 64). I happened to salvage one out of an old Ericsson desk phone, and its awesome... It will do the job nicely and even supports grayscale. It has two controllers, each controlling a half of the LCD, so in total its 264 x 160 pixels display area (The controllers are EPSON S1D15E06). With a large display area like that, and the fonts I plan to use, a cheap 8 bit micro is not going to cut it, we go straight to ARM Cortex. Also driving this display from the OrangePi will consume too many GPIO pins and require overhead which *may* result in issues. So we do it the way Sony does with their consumer electronics... use a MICON (MICON = Man Interface CONtroller)- a sub processor which reports to the main processor doing the heavy lifting.

At this point, to accommodate all the devices, it needs to be moved to a bigger breadboard.

 

[TSZ]

02 - 02 -2022 - Bigger is Better

The electronics has been moved to a bigger breadboard. I also got the S/PDIF working well (see caveats below)

What's going on Above?

The OrangePi Zero is on the board, to the left is an ARM Cortex M0 Microcontroller (STM32F072RB) and on the right is a DIR and D/A converter. These all work. The dreadful noise is gone from the audio path and its pure hi-fi.

Caveats?
Because this is a breadboard, I have not configured Linux for higher than 96/24 format audio. It does however reproduce CD quality 44.1kHz stuff flawlessly and without noise. At the high resolutions (96kHz FLAC files), the audio has random noise on it, and this is because if you bring a hand (or finger) ANYWHERE NEAR the DIR or the D/A converter, it affects the signal integrity. I have mitigated this to a limited degree by using an aluminium plate on the underside (not shown). The bottom line is that when playing high resolution FLAC files, the oversampling clock frequency is so high the breadboard's parasitic effects (and those of the wires), stray capacitances, and other parasitic effects affect the signal integrity into the D/A converter. This is absolutely pushing the limits of what can be done on a breadboard. You can see the signal distortion (ringing edges and more) on test equipment.

Does it work? Damn straight it does... I spent 4 hours listening to my music, with this, over the weekend!