Active crossover running on fanless PC

sumvision cyclone

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.


11 thoughts on “Active crossover running on fanless PC

    1. I’m thinking about it. As I mentioned elsewhere, my code is a (working) mess at the moment. The measurements I use to correct the drivers were made under my previous Windows-based system – I am yet to implement a system for making measurements under Linux. There are quite a few things I would have to do to make the system usable by anyone else.

      Liked by 1 person

      1. Messes are acceptable if they work. 🙂

        Actually, a good way to make and process speaker/headphone measurements is sorely lacking on Linux, you’d be making the world a better place if you did it.


          1. Thanks for the tip – I’ll look into it.

            Under Windows I used Room EQ Wizard which, I think, is available for Linux too. Last time I looked, REW wasn’t offering me the correct input and output options, and there is this whole question of sample rate conversion and so on. It’s ‘messy’. Only by knowing that the output and input are synchronised at sample rate level can you be sure the results are meaningful. It would be very nice to be able to measure with and without the correction in place in order to confirm the correction is working.

            What I would like to do, is incorporate measurement as an option in the active crossover code. All it has to do (I think) is to play a sine sweep and gather the result from the microphone using the line or mic inputs on the same sound card as the DAC – the Asus U7 has such inputs. I think that this would ensure that input and output are locked together at sample level. I have already written the code to generate the log sine sweep, although this could be a pre-calculated WAV file, also. Making measurements is slightly hazardous, as it could damage a tweeter, so some sort of clever system to safeguard against that could be quite useful.


            1. If all you’re doing is generating crossover points, and not a parametric eq, then at that point you wouldn’t need to probe the upper limits of the tweeter’s range. If you stopped your sweep at 10k or so, would that be enough to protect the tweeter from damage? (I genuinely don’t know the answer to this.)


            2. I’m thinking more of the lower end. The usual thing is to protect a tweeter with a series capacitor to ensure that any DC or ‘thumps’ don’t damage it, but I should think it would still be possible if the signal was loud enough – and my series capacitors may be too large for full protection. You want to sweep starting at a lower frequency than the normal working range, of course.


            3. You could let people give a lower bound on the sweep and then count on them to read the datasheet for their tweeter and pick a reasonable one.


  1. Here’s another question– is this running on a separate fanless computer that receives audio from an external source, or is your software transparenly intercepting all audio played on the fanless computer and redirecting it through a crossover? Also how much latency would you say your xover adds?

    I ask because I think the soundstage improvements you’re claiming would be of great benifit for gaming in addition to music, but only if the added latency is just a couple of milliseconds. If there’s too much latency it won’t be any good for gaming at all.


    1. The idea is that the audio data ‘originates’ (in a specific sense of that word) within the same PC as the crossover. The audio data can be a file on a SD card, streamed from the internet, or from a CD. In all those cases, the software can effectively pull the data off the storage at the sample rate dictated by the DAC. An analogue input would also be OK if the ADC could be locked to the sample rate of the DAC. I am hoping that in the case of My Xonar U7, its mic and line inputs are automatically locked to the DAC, so this would work. In the case of an S/PDIF input, this scheme would not work because the stream would be arriving at the PC at 44.099 kHz, say, but the DAC might be running at 44.101 kHz. This is where software-based resampling would be essential. Linux is well-equipped to do this, and even gives a choice of conversion algorithms and quality settings. However, the highest quality is power-hungry, and you’d always have that slightest doubt in the back of your mind, don’t you think? I would just avoid the problem altogether.

      You will be very disappointed with the system’s latency: 500ms! However, this is a function of the size of filter that you wish to use, and what you want to do with it. You could use a smaller filter, and compromise on the bass correction, and so on. However, you are never going to get it down to 2ms without heavy compromise. I notice the creators of some commercial systems mention this as a limitation of their products. Also, it seems that the Kii Three has two settings, described thus:

      “The Kii THREE has two settings in regard of latency.
      One is the regular fully processed setting – audiophile listening mode: 88.78ms
      The other one is used for lipsync applications – low latency mode: 1.4msec
      You can easily switch between the modes with a little press button on the back of the Kii THREE.”


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s