In my article on how to set up a Linux-based music server at home, I mentioned that I have two CuBox-i4 cube computers, using the Volumio music system, serving music in my home. I also mentioned that one of those uses an AudioQuest DragonFly digital-to-analog converter, or DAC, to get the bits out to the amplifier and speakers. Finally, I mentioned that the DragonFly and Volumio were not a totally happy pairing. The combo occasionally introduces noise in the form of high-level clicks into the analog output, sounding for all the world like the sort of pops one hears on a poorly cleaned record.

Because I am willing to spend time and effort cleaning records to reduce those kind of noises, spending time investigating the CuBox-DragonFly combo to see whether “cleaning it up” is possible also seems reasonable to me. I’m going to share a bit of my experience here, in the hope that a reader may benefit from the whole sad tale. And who knows—maybe someone will read this and, in the true spirit of the open source community, enlighten all of us with a solution.

Troubleshooting tale

First I wanted to verify that I can make the DragonFly perform acceptably in another Linux environment, so I tested it on my laptop, currently running Ubuntu 15.10 with a 4.2.0 kernel. I used my current favorite music player, QuodLibet, configured to send audio straight through to ALSA to avoid any conversion of bit rates or word lengths. Sounds great: No clicks, no pops, no messages from dmesg indicating any kind of incompatibility. Looking at /proc/asound/DragonFly/stream0, I see evidence that things are working as they should when playing a 44.1KHz/16-bit file:

Playback:
  Status: Running
    Interface = 1
    Altset = 1
    Packet Size = 336
    Momentary freq = 44100 Hz (0x2c.1998)
    Feedback Format = 10.14
  Interface 1
    Altset 1
    Format: S24_3LE
    Channels: 2
    Endpoint: 1 OUT (ASYNC)
    Rates: 44100, 48000, 88200, 96000

Similarly, things seemed to work fine with 96KHz/24-bit music.

Given that the DragonFly isn’t a hopeless case, what to do? The obvious thing—to me, at least—was to find something with a newer kernel. Lately, I have had my eye on Archphile, another music-oriented minimalist Linux. Unlike Volumio, which is based on Debian, Archphile is based on Arch Linux. I’ve tended to stick with Ubuntu over the years, with occasional forays into other Debian distros and the occasional spin with Fedora, but I haven’t really experimented. This could be one of those “kill two birds with one stone” things. Archphile still uses a 3.14 kernel, but it’s newer than what comes with Volumio. I decided to give it a try.

Archphile installation was pretty straightforward. I used Gnome Disks to format a 32GB microSD card and install the Archphile ISO. I used the Gnome Partition Editor (GParted) to grow the install partition so that it took up more of the microSD card. I installed the microSD in the CuBox-i4, connected keyboard and monitor, and powered up the system. Everything worked fine. The configuration steps for Archphile are pretty straightforward: change the root password, the locale, and the NTP servers. I’m using a hardwired connection, so I didn’t need to mess with wireless. (I should do away with DHCP on this unit as well, but maybe later.) I created a non-root user account, edited /etc/fstab to arrange for mounting my hard drive containing the music, messed with the /etc/mpd.conf file to introduce the DragonFly to Archphile and activate the hardware mixer, and I was ready to go.

I tested the results, and there was more clicking. Time to do some more detective work.

There is a lot of talk about “clicks and pops” out there on the Internet. Quite a few links relate to the Raspberry Pi, USB-connected DACs, and playing higher-resolution music.

In my case, though, I haven’t done a definitive study. I seem to experience more problems with 44.1KHz/16-bit files than with 96/24. I have wondered whether this is because the DragonFly only seems to present a 24-bit format option. I have experimented with the use of “plughw” vs. “hw” as the interface, but haven’t seen any reliable difference. The mpd.conf(5) – Linux man page is comprehensive and merits study, as does the Alsa Project wiki.

Finally I took the time to figure out how to make my parameters on the CuBox-i4 look the same as they do on the laptop. To make this happen, I discovered that I needed to set two parameters in the /etc/mpd.conf file, specifically in the audio_output stanza:

period_time     "10000"
buffer_time     "200000"

Now the /proc/asound/DragonFly/pcm0p/sub0/hw_params file looks the same on both systems when playing either 44.1KHz/16-bit or 96KHz/ 24-bit.

With that configuration change, I have listened to four tracks in 96/24 and heard no clicking. However, I am still hearing the occasional click in 44.1/16 files, perhaps 1-5 times per song. Frustrating! I also continue to see the following message in dmesg when playing starts: 2:1:1: cannot get freq at ep 0x1.

I’ve looked this up in the relevant kernel sources; the comment seems to indicate that the device doesn’t support reading, but the surrounding code doesn’t look like it does something ominous because of that. The mpd man page includes suggestions about smaller and larger _time values in the mpd man page. So something remains to be tracked down. (Do you have other suggestions? If so, tell me about them in the comments.)

Let’s close with music

In November 2015, I bought The Dunedin Consort‘s performance of Mozart’s Requiem Mass, recorded and sold by Linn Records.

I like buying music from Linn because they don’t force me to install anything to download my music, and because they offer everything in an assortment of bit rates, resolutions, and formats. Of course I always choose FLAC. And generally I buy the 96KHz/24-bit files when available, but I was tempted by the 180g vinyl offering in this case.

The Dunedin performance of this work is spectacular, and I see that they have received—deservedly—kudos from a great number of music reviewers. I have an earlier recording by the BBC Symphony under Colin Davis, and many years ago, I was fortunate enough to hear it performed in the church of St. Germain des Prés in Paris one cold January night. Of course, Mozart’s Requiem Mass also plays a pivotal role in the film Amadeus, a wonderfully raunchy and irreverent take on Mozart’s life.

My taste in classical music is quite specific, and much of “the great repertoire” leaves me cold. A visiting friend once commented, on looking over my classical CD collection, that he had never seen so much Bach and so little Beethoven on anyone’s shelves before. Still, I recommend Mozart’s Requiem Mass to anyone regardless of their preference and tolerance for classical music—perhaps especially for those who have yet to find much classical music they like.

And for readers who don’t know the Requiem Mass story, Mozart did not finish composing the piece before his death, and the work was completed by his friend Franz Xaver Süssmayr, so that Mozart’s widow, Constanze, would be able to claim the remaining payment for the composition from its patron. Clearly Mozart established the overall design of the composition and prototyped some of its sections, but Süssmayr (and possibly others) were left with quite a bit of composition (coding) to complete (and, I imagine, testing and QA). According to Wikipedia, and as was apparently common in Mozart’s time, music was somewhat modular and components were regularly reused in other compositions, thus demonstrating that the principles of open source and reusable software were once a part of the composer’s toolbox.

In fact, I think I’ll listen to Requiem Mass right now to see if I can hear any clicking…