I bought a Sumvision Cyclone Mini PC for experimenting with running my active crossover software on a fanless PC. It’s no more than a tablet in a box, but it’s quad core and runs 64 bit Linux on an Intel Atom Bay Trail chipset and, presumably, can perform GFLOPS without dissipating more than few watts – that’s really quite amazing but it’s so easy to take such things for granted these days! It comes pre-loaded with Windows 8.1 and it was a pain to make it work with Linux. I relied heavily on a guide on the internet – thanks to the person who provided it.
Undoubtedly it will be much easier to install Ubuntu on one of these PCs in the future when the Linux people have caught up with the hardware. The WiFi doesn’t work yet so I am using a USB dongle, nor does the on-board audio but I am using the Asus Xonar U7 for that, anyway. Interestingly (to me anyway) I was able to remove Pulse Audio (I think) from this version of Ubuntu without affecting the other system settings [I think this was a fluke: removing pulseaudio properly is impossible, and what I really should do is merely set “autospawn=no” in /etc/pulse/client/conf and reboot].
Absurdly, once Linux was installed following the guide, it worked straight away with the Xonar U7 and my crossover software, plus 64 bit Spotify.
I am assuming I could plug in a common or garden USB DVD drive for playing CDs without a problem [tried this and it works fine].
While running the active crossover software and streaming from Spotify, according to psensor the core temperatures are stabilised at about 56-60 degrees C in an ambient room temperature of 22 degrees C, and overall CPU usage is about 18%.
UPDATE 13/09/15
Things haven’t worked out quite as smoothly as I thought: on the fanless PC I have been getting occasional glitches in the audio, in the form of a click audible within the music, perhaps once every 10 minutes on average. These don’t occur in silent sections of the music so I am assuming that it is a case of missing, or extra, samples rather than corrupted samples. I didn’t notice this when running the code on a Pentium IV based desktop machine.
As a result, I have made major changes to the software, reducing the number of threads from three to one (plus a default thread for the GUI – which is currently just a mute checkbox for each driver). There are suggestions on the web that the ALSA functions are not ‘thread safe’. So now, all the ALSA audio and DSP processing runs in a single thread and all ALSA calls are non-blocking. This arrangement dispenses with the necessity to lock various circular buffer pointers with mutexes when accessing them, so the code is now more stripped back and simpler to understand.
The main motivation for multi-threading originally was that I assumed that the OS would assign threads to different cores, so for coolest running it would be best to share the computation load across several threads. Therefore I expected to see the CPU load on one of the cores go up as a result of combining three threads into one, but it doesn’t seem to have greatly affected the CPU load traces, nor the core temperatures.
No glitches so far.
[UPDATE 29/10/15]
Still had the glitch problem! It wasn’t happening on a P4 desktop minitower PC, but on the Sumvision I might get a glitch once in ten minutes. Nothing drastic, but I found myself on edge waiting for it. Really, any glitches are unacceptable, even if only one every three hours.
Is it related to input or output? As an experiment I modified the code to stream the incoming audio to a file while playing music. When I heard a glitch I noted down the time it occurred. Examining the data in the audio editor app Audacity I found a discontinuity in the waveform. Gotcha! In order to test for this problem reliably I created an audio file containing a continuously-repeating ramp waveform. In my program I added a check on consecutive samples to flag up any discontinuities. Sure enough, the problem only occurred occasionally, but it always happened eventually. Playing with threads etc. didn’t get rid of it.
In desperation I started to look at the open source code for the snd-aloop driver I am using as my bridge between audio player apps and my code. I found a mysterious system whereby there are separate ‘rate shifts’ (the programmable sample rate I am relying on in my code) for playback and capture. I don’t really understand this: unless playback and capture are locked together (at least on average), it seems to me that they must eventually diverge and cause audio discontinuities. I bodged the snd-aloop source code in order to precisely lock together the playback and capture ‘deltas’. This sort of thing is outside my comfort zone. I had to re-compile the snd-aloop driver and use the Linux command insmod to load it into the system.
It worked. I now get zero errors no matter how long the system is running. The difference between the Sumvision and the old P4 may be explained by the fact that the PCs’ clocks were quite a bit different, and much more rate shift was necessary in the Sumvision in order to synchronise with the sound card.
I still think I am making this harder than it needs to be. Do I need the snd-aloop driver at all? Can it all be done with ALSA plugins? One Linux guru said I should write my program as a plugin itself. It has occurred to me that at least I can now modify snd-aloop in order to make it work as I want: not with its own sample rate at all, but merely as a relay from the capture demand to the playback demand.
But the bottom line is that the system is now working perfectly on the Sumvision Cyclone.
02/12/16: It seems that there will be no ‘official’ version of Ubuntu for the Bay Trail and Cherry Trail chipsets, but someone called Ian Morrison (a.k.a. “Linuxium”) has created an installer and very kindly made it available. I found that his version of Ubuntu 16.04 seemed not to boot on the Sumvision Cyclone, but 16.10 appears to be fine. I haven’t transferred my software over to it yet but my second Sumvision Cyclone appears to be working fine, with Wi-Fi. Many thanks to Ian for this. I wouldn’t know where to start in creating such a thing.
UPDATE 30/01/16: I just spent quite a large proportion of my Christmas break worrying about, and trying to fix, an issue that arose after I put the latest version of Ubuntu (mentioned above) onto a Sumvision Cyclone and installed my active crossover software. Glitches were back!
I cannot tell you how many fruitless attempts I made to solve it. I narrowed it down to the DAC output, where some zero-value samples were being substituted in the analogue output, but with the overall timing remaining correct. There were no EPIPE (buffer underrun) errors.
I created a ‘glitch detector’ where I generated a waveform from the DAC’s analogue output and fed it via a cable into the microphone input, looking for excessive sample-to-sample amplitude changes. Glitches would always occur, but it seemed worse when loading web pages etc.
Finally, I think I hit upon the solution in this forum topic:
Problem with Bay Trail and new kernels
It seems that recent versions of the Linux kernel have changed something regarding ‘C-states’, related to the way the processor cores are dynamically put into low power modes when idle in order to reduce average power consumption. With the new, more aggressive, power saving, they take longer to start up again (flushing pipelines etc.), and this has been causing Bay Trail setups to freeze completely. It is still being discussed as a live issue on Intel forums. I think I have been suffering from another side effect of this misguided change.
There is a workaround, which is to specify a boot option to keep the cores relatively ‘alive’ at all times. (There may also be a BIOS setting that I could have changed, too). It seems to have fixed my problem completely.
If this turns out to be the issue, it highlights the fragile nature of any IT-based product. An innocuous update in the operating system can kill your product because of real time issues; there is no amount of testing that can be done by the OS people that can eliminate the potential for problems in users’ own applications.
At one time, I naively thought that it was possible to put together an embedded PC-based system that could be ‘frozen’ and would always work, and could always be duplicated, but I have long given up hope on that. Embarking on any digital audio scheme based on a PC implies a commitment to constant maintenance, in a way no different from the constant maintenance you commit to when using, say, reel-to-reel tape recorders.
The Rational Audiophile 