Digital audio systems since the beginning have used elevated sampling rates for processing while down-sampling the product to 44.1 or 48 KHz sampling rates for storage and transmission. These design decisions are attempts to satisfy the requirements of the sampling theorem using easily implemented anti-aliasing filters and reconstruction filters.
Reference 1 gives a good explanation of the sampling theorem and up-sampling for implementation convenience and the interaction of digital audio with human hearing. Reference 2 explains the theory behind dither in digital systems. Reference 3 explains oversampling techniques.
The Sampling Theorem
The sampling theorem states that any band-limited signal can be perfectly reconstructed from a sequence of uniformly spaced samples taken at twice the frequency of the highest spectral component present in the signal. The catch is that no energy must be present above one-half the sampling frequency and that ideal low pass filters (brick wall filters) must be used in both the recording and playback systems.
The sampling theorem is not a matter of belief. It is mathematically proven theory that describes the behavior of sampled data systems. Any well-behaved sampled data system must satisfy the sampling theorem’s requirements. Sampled data systems that work do so.
As with any engineering theory, the devil is in the details of satisfying its requirements. The sampling theorem requires unrealizable ideal low pass anti-aliasing filters and reconstruction filters. The art is in designing a sampled data system that works with realizable filters. For audio systems, an important part of the art is in choosing and designing anti-aliasing and reconstruction filters that do not introduce non-musical artifacts to the reconstructed audio signal.
After the break, we’ll explain how digital audio system engineers design real world digital recording and playback systems that can be built with realizable filters. As you might guess, it is over-sampling that makes this possible
FreeNAS 11.2 has been out for a few weeks. After some time running Roon on a Ubuntu equipped 2009 Mac Mini, I decided I’d give Roon a try in a BHYVE VM on the new FreeNAS build. This note recounts the experience so far. As usual, both FreeNAS and Roon have their secrets and they interact.
Intel(R) Xeon(R) CPU E3-1225 v5 @ 3.30GHz (4 cores)
32 GB memory
Six 4 TB storage array class SATA disks split between two manufactures
Ubiquity EdgeRouter Lite gateway
Ubiquity Unifi Switch 8 core switch
Netgear ORBI WiFi in access point mode
Software
Roon 1.6
FreeNAS 11.2
Ubuntu Desktop 18.04 minimal install
Preconditions
FreeNAS 11.1.2 was previously running on the host. The normal update procedure took the machine from 11.1.2 to 11.2 without incident.
Roon had previously been run on the machine but was moved to a Mac Mini when it became unstable somewhere along the 11.1 upgrade trail. The original was in an IOHYVE administered BHYVE. The IOHYVE and GUI VM environments were separate and somehow the original fell between the cracks as updating happened. I had the Mac Mini in retirement (it is around to digitize LPs) so I put Ubuntu 18.04 LTS on it and moved Roon over there for about 6 months.
Getting bored one evening, I decided to move Roon back to the Xeon server. Being over there greatly reduces disk traffic as the music share and the Roon instance are on the same box.
Getting Started
In preparation I downloaded Ubuntu 18.04 and saved it to a CIFS share used to keep ISO images of OS releases. I also downloaded the Roon 1.6 Linux easy installation script later following the Roon installation instructions.
Roon Database Backup
To migrate a Roon installation to new hardware is a bit different than initial installation. Roon requires a license for each server environment. To bring up a new server without buying a new license requires transferring the Roon database and license from the old to the new. To prepare for the transfer, back up the database.
Database backup is straight forward following the Roon Backup dialogs. Except for one little thing. Roon is running as root (if you weren’t a clever lad and moved roon to daemon where it should be). And Roon is unable to mount CIFS file systems read-write. No way in hell will Roon write to a CIFS file system, well not that I could find.
I finally ended up making my backup to /tmp and using the primary user file manager to move the directory to a USB stick. Using the USB stick, I put the database on a CIFS share using MacOS. This is the same share holding my media so it is readable by Roon.
BHYVE Preparation
Materials in hand, I created a small BHYVE environment
2 virtual processors
8 GB memory
64 GB disk ZVOL
NIC EM0
VNC framebuffer
I originally created 2 ZVOLS, one for the primary VM disk and a second to hold Roon backups. Note that VM disks must be ZVOLS. FreeNAS will not configure a dataset as a virtual disk. I never did find a description of where BHYVE hid disks that weren’t the startup volume. It had not been auto-mounted for me and I didn’t know what it was called to make a /etc/fstab entry for it. I also never got the console working quite right so I could look for it.
For initial boot, I chose VNC synchronous connection (boot holds until VNC connection is established). This option ensured that I could see all of the messaging during Ubuntu startup. After initial installation, I removed this option to allow unattended restarts
Ubuntu Installation
I installed Ubuntu 18.04 LTS into this environment taking the normal installation defaults with the exception of minimal installation (no LibreOffice, games, media players, etc). Ubuntu installed as expected.
Roon Installation
Roon 1.6 installed from the shell script following the instructions. I installed ffmpeg as instructed. I installed libavtools as instructed. When I went to install libasound2, I found that apt had already installed it. I installed CIFS-tools as instructed. The installer script checks for CIFS mount capability whether you expect to use it or not. Then I ran the Roon installation script as instructed.
Roon Setup
When you start Roon for the first time (no credentials in place), Roon offers two choices: start a trial or purchase a license or two, restore a Roon database backup. For the transfer, you choose to restore the database backup. This brings over your Roon service credentials, Tidal credentials, and Qobuz credentials. Once the database is restored, deauthorize the original Roon server. You can connect to it and reauthorize it later if the new installation goes sideways.
All went well. Once Roon had restored the database, I had signed in to Roon, Tidal, and Qobuz, I found my stars and tags did not come over but once authenticated, all of my local music and subscription music were available.
Roon Backups
Disks are a complication. Basically, if you don’t have a domain controller, and you have a mixed Unix, Mac, CIFS environment, you are in authentication Babel. Good luck matching user id numbers as each implementation is free to assign them how it will. And the numbers matter across platforms.
Roon does not like to write to CIFS disks
Roon does access mounted disks in /mnt
I never could get the permissions right to write to disks mounted in /mnt
Back in the old SunOS NFS days, life was good. There was only Sun and Sun licensed NFS installations that behaved themselves and used Yellow Pages for credential sharing. In the good old days, you could have a Sun workstation in service 5 minutes after picking up the box knife to cut the box open. (I miss those days).
Today we are in credential Babel. Enterprise credential environments are just too hard to set up if you’re not a high priest in your day job. So nobody does and the mitigations in the FreeNAS+Roon environment are not written down, well not so Google can find them.
So, I configured Roon to write backups to /var/RoonBackup (or is it plural). I let Roon create the directory so the permissions would be right. I set up a scheduled backup and manually initiated the first one once Roon had settled. Roon will keep 10 (or the number you set). Each appears to run 1 to 2 gigabytes so that 64 GB of space will come in handy. If need be, I can grow the ZVOL.
I’ll try to avoid the schiit puns as Gungnir Multibit (Gumby) arrived and is settled in my audio rack. Gumby is a good Gumby! Jason Stoddard and Mike Moffat founded Schiit about a decade ago to scratch their audio design itch. Schiit has an unusual philosophy and take on high fidelity audio equipment, that it exists to serve the love of music and not to be techno-sculpture in the lounges of the rich. Rather than making a big statement piece for the wealthy, they began by making affordable $100 devices for those wishing for more than headphones plugged into an iBook. And they set out to show that you could build here of mostly US made stuff and be profitable.
I’ve not written on audio and networking in a while but over the holiday I read Jason Stoddard’s Schiit Happens about his return to the high fidelity equipment industry as co-founder of Schiit, a maker of personal audio and value oriented high end audio. I found the book after I had ordered my Schiit Gungnir Multi-bit DAC. Over the break I had also watched a video in which Mike and Jason (the founders) talked about how Schiit came to be and this, that, and the other thing. They are toying with the notion of offering a new product which Mike kept calling Schiit Pi. This got me thinking I should write about my streaming environment again as I had improved it significantly in 2018.
In the video Mike and Jason speculate about what they might do with a Raspberry Pi. Mike, in true company spirit, referred to the mythical product as a Schiit Pi. Mike did not want the new device to be a general streaming client as he didn’t want to support multiple streaming service protocols on the device or do significant UI development.
Rather, he was contemplating a device that would connect between a streaming client and a DAC and would perform some digital signal processing magic to decrapify the streamed source. He tossed around a number of ideas. It will be interesting to see Mike’s ideas evolve into a product.
Mike’s musings prompted this article as network performance significantly affects the behavior of network audio devices. As we will see, network issues may be the result of an ill-behaved application on any network endpoint.
Before Roon
Originally, I used iTunes and Apple AirPlay to an Apple TV to play music. I didn’t like the requirement that I leave the Mac up to serve music. Apple just plain got iTunes architecture wrong and has not seen fit to fix it because it works for the masses.
Back in ancient history an Nvidia Shield appeared in the TV rack. This impulse purchase device picked up music serving duties using Plex to stream from a copy of my iTunes library on an external disk. From time to time, I would move the disk to my Mac and rsync the iTunes library over.
I quickly discovered that Plex supported Chromecast Audio as an endpoint so I gave it a try. Wow, what an improvement in sound quality. The image solidified and the sound became crisper. Hearing Thile-Mehldau Scarlet Town on this line-up was a revelation. Clearly, Apple was doing one or more things badly in AirPlay or Apple TV.
But there were random fades. After several months of this, I realized they were happening while using my iPad and were noticeably more frequent using the iPad Facebook app.
The HiFiBerry Digi+
Manually syncing my music library to the Nvidia Shield was getting old. As I was planning for a new iMac in the fall, I built the FreeNAS server and a HiFIberry Digi+. The FreeNAS box was slotted to become a media server and Time Machine spool volume. The HiFiBerry was to replace the Chromecast Audio with something more robust and durable. Google was pimping the little Chromecast gadget pretty hard, it ran warm, and I was concerned about its future support.
In 2017 I built a HiFiBerry Digi+ to use as a streaming endpoint. I placed the HiFiBerry in service connected to a Burr Brown based DAC in my Parasound P5 preamp. The sound was good but there were still drop outs.
When I moved the streaming endpoint from an Apple TV to the Raspberry Pi, both on the wired Ethernet, I began to experience network fades. Apple AirPlay had covered these up by using a 2 second fade buffer.
My old network topology
In an effort to stop the fades, I tried moving things around. At the time, the cable modem fed a Netgear Orbi WiFi router which, in turn fed the network core switch. Each equipment rack in the living room (audio rack and TV rack) had its own rack top switch, an Netgear 8 port gigabit unmanaged switch. The music server was in one rack and the player in the other. Music sample packets had to travel back to the core switch (also an unmanaged Netgear switch).
The first thing I tried was to connect the Roon Server and the Raspberry Pi to the same rack top switch. In theory, Roon packets would enter the switch and be forwarded directly to the Pi. But fades still happened.
Undesirable #1
Every time I touched the iPad Facebook app, there would be a music stall. This happened before any experimentation and continued to plague every every experiment going forward. Part of the solution was to drop Facebook and Instagram for other reasons (corporate miss-deeds, sock puppet memes, precision guided propaganda delivery system).
UniFi Switch 8 150 Arrives
In 2017, a local electrician installed 3 network cameras for me. These were Ubiquity UniFi Video G3 cameras that required power over Ethernet. I purchased a Switch-8-150 to power these cameras. This switch replaced the unmanaged network switch in the core network closet (my closet).
The Netgear Orbi continued to have routing and WiFi duties. One port on the Orbi connected the core network switch. The second connected a rack top switch in my study. Still fades.
UniFi EdgeRouter Arrives
While researching networking for my church’s move to a new clubhouse, I discovered the EdgeRouter Lite and ordered one for home. This router replaced the Orbi in the Internet access router role. I reconfigured the Orbi as WiFi only (no DHCP, DNS, or routing chores) as these moved to the EdgeRouter Lite.
In this arrangement, I used 2 lines from my study to the core switch. the first connected the router to the core switch. The second connected the core switch to the rack top switch in my study equipment rack. Surprise. No streaming fades. Nary a one. Orbi just did not have the processor horsepower to handle the WiFi and route packets both
UniFi Switch-8-60 Arrives
I’m slowly converting all of my Ethernet equipment to Ubiquity UniFi. The next change was to replace my study switch with a new Switch-8-60 to power a UniFi Cloud Key G2 that picked up network management duties formerly performed by a VM on my FreeNAS box and NVR duties for the cameras. I changed the topology to make this switch my core switch and the Switch-8-150 remained in the role of tying everything on the wired Ethernet together.
The router now connected to my study rack top switch. This study switch now served the CloudKey G2+, my iMac, and a new printer in my study and connects the wired Ethernet core switch and the Orbi as WiFi access point to the access router. This arrangement continues to provide fade-free music streaming both to the wired Ethernet and the WiFi
Final Topology
Final Network Topology
The diagram shows the final topology that I adopted. This topology has proven robust. Music is fade free. YouTube video is fade free. The Cloud Key G2+ and Switch-8-60 are on the study rack where I can check their indicators. The only real disadvantage to this topology is that NVR video passes over to the study switch to reach the NVR.
About a year ago I installed Roon Audio and began using it without Tidal. In my original configuration, Roon Audio ran in a VM hosted by my FreeNAS storage server. It delivered audio to either an Apple TV or a Google Chromecast Audio. Both were connected to a Cambridge DACmagic converter by TOSlink. For the first year I passed on the Tidal subscription, assuming that it, like Apple and Amazon streaming, sounded horrid. Then I got curious.
Best wishes for a wonderful 2019. Boy has it been a busy year. As 2018 closes, Dave, Nick, and Missy are well. Dave remains busy with club activities while the Greyhounds continue to keep our garden zombie free.
I’m now officially a Moocher
I turned 70 and started collecting Social Security. This should be a good bet as monthly benefits increase by about 30 percent. The design is neutral from an actuarial vantage point. Social Security will pay out the same total from commencement to median life expectancy. The bet you make is that you will live past median life expectancy, a good bet as most relatives who dodged early canecer have done so on both sides of the family. Most cancer cases involve risk factors like tobacco use, agent orange exposure, or alcohol abuse. I now actually have some income. Surprisingly, Social Security covers about 1/2 of my income needs.
A new switch, cloud key, and updated network video recorder joined the Dismal Manor UniFi stable this October. The Moocher checked firmware to discover that updating the core POE switch to the latest firmware required updating UniFi Controller. At that time, UniFi controller ran in a FreeNAS jail. So, the cheap intrepid Moocher tried to update UniFi controller in the jail. He quickly discovered he was in dependency hell. Find out how he got out after the jump.
After many years of using a Canon Pixma printer, the Moocher decided that the time had come for its retirement. Like many things in computing, changing interface standards rather than aging led to its replacement.
Moose, one of my Twitter buddies, is a disgustingly cute Italian Greyhound (I believe) who has attracted an unseemly number of Twitter followers. Somewhere along the way his minions had the notion to start a Sighthound Welfare Charity in the UK. Being in the UK and (for the moment in the EU) my peeps are well aware of the plight of the Spanish Glagos (a field bred coursing hound) and the UK is awash in lurchers (deliberate greyhound crossbreeds bred as field dogs). Strong regulation and a strong network of adoption charities support the UK racing greyhound population but the hunting bred dogs are not well regulated and don’t have the industry assisted adoption network enjoyed by the racing dogs. It is with the field bred Galgos and Lurchers where I see Moose’s Trust filling a need.
The Moocher is a music collector with a growing CD and record collection. In this article, the moocher describes how he transfers CD to FLAC to play using Roon Labs Roon Player. We’ll look at the motivation behind FLAC, the tools used to turn a CD into FLAC encoded tracks, and how to get the tools.
