Hear me, hear me!
Jonni Bidwell takes a break from his frantic conference snacking schedule to interview audiophiles and gentlemen, 64 Studio.
Jonni Bidwell takes a break from his frantic conference snacking schedule to interview audiophiles and gentlemen of 64 Studio, duo Daniel James and Chris Obbard.
the folks behind 64 Studio (https://64studio.com) are Isle of Wight-based hacker duo Daniel James and Chris Obbard. Their eponymous first contribution to the FOSS ecosystem came in 2005 – a real-time, Debianbased multimedia distribution which exploited the (then) new instructions in AMD’S early 64-bit processors.
Nowadays they contribute to all sorts of multimedia efforts, including openmha (Master Hearing Aid), a project which uses Linux to power hearing aids. They were at the Linux Foundation’s Open Source Summit in Edinburgh in October 2018, where they took the time to chat to wannabe turntablist Jonni Bidwell. Naturally, the conversation tended towards one of their other projects: Pideck, a Pi-powered digital vinyl system that allows people to mix/scratch/cut their digital music using time-coded vinyl on a conventional turntable.
Linux Format: Daniel, you used to write for Linux Format – and indeed our erstwhile rival, then later sister magazine and now alas deceased Linux User & Developer…
Daniel James: I was maintaining a list of Uk-related Linux websites in the ’90s. Alan Cox had started it and no longer had time to work on it, so I took over. When the first magazines were launched in the UK, around 1999, the impetus was coming from advertisers like IBM who wanted to spend money to show how committed they were to open source. They were hunting around for Uk-based people who knew about this stuff. And there weren’t that many of them.
LXF: Nice. Our subscribers can find your contributions in issues 100-130 in our archive and indeed the last years of LU&D issues. Tell me about 64 Studio.
DJ: Back in about 2003, AMD launched the Opteron processor, which was a bit of a departure because at that time people were focused on [Intel’s] Itanium being the future of high-performance computing.
There was a small department within AMD that looked at workstation marketing, because the high-end workstations used for movie graphics and things like that tended to be SGI Irix machines – proprietary UNIX boxes. Inside AMD there was one guy in charge of workstation marketing, and he happened to be a mad-keen Frank Zappa fan. This is all a bit random, so bear with me… Dweezil Zappa, who inherited the family business, needed some sort of sponsorship deal to get his studio up and running again after Frank died. The AMD guy decided “I can make
on studio 64’s first distro “We were a performance-orientated multimedia distro so we really wanted to get that audio package selection down, to have tools that people could rely on.”
that happen”. So they built some audio workstations with Opteron processors, put them into the studio and found that they behaved really well. The performance surpassed expectations, even when running 32-bit Windows, because they’d opened up the chip architecture and memory access and things like that.
I thought, if it works well there, why not take the Debian port to AMD64, which at that time was brand new, and combine that with a real-time kernel? I was familiar with the kernel from the Demudi project, which was a Debian multimedia distro [http://www.demudi.org]. Then we tailored the package selection, because at that time a lot of the distros gave you every package imaginable – gigabytes of binaries that would happily fill a DVD.
LXF: Yes, Ubuntu has certainly got better about that, but a few distros still seem to overload their software stack, which can be off-putting for new users and is a thorn in the side of disc editors trying to fit many distros on a DVD.
DJ: I suppose we were being a little bit like a magazine, being more editorial and purist, cutting down the package selection to those we’d personally tested. So we got the ISO size down to something that would fit on a CD. It included our Hotpicks, if you will, from all the categories in the greater desktop field. So we had Gimp,
Inkscape, Blender and all the other usual suspects, but obviously our main focus was on the audio apps. You could get Gimp and friends in any old distro, but we were a performance-orientated multimedia distro so we really wanted to get that audio package selection down, to have tools that people could rely on.
Once people started using this distro on AMD64 hardware, they found a substantial leap in performance. One of the reasons for that was that Linus originally wrote Linux on a 386, and Debian (and other distros) still compiled
for i386 targets by default. When AMD64 came along it raised the bar, because suddenly you had all these things like SSE2 optimisations by default. So when you compiled an AMD64 binary you got those for free. For things like real-time audio processing, where you’ve got plugins that can take advantage of those extensions, there was yet again this performance leap. This raised the floor level for that binary target up to what was current at the time.
On the real-time kernel side, at that time the kernel developers – Ingo Molnar and co – who were working on the realtime patchset weren’t using AMD64 processors. They were working for companies that were all doing 32-bit work on Intel, because that was the standard server platform in those days: commodity one-use servers. So we figured this warranted some investigation.
In the beginning those patches didn’t even compile on AMD64, because those guys didn’t have those machines. So we encouraged and reported back and gradually we got to a nice configuration that worked well on the version of Debian that was current at that time. That’s what we pushed out in our first releases around the end of 2005. People reviewed it, it made it onto sites like Distrowatch and it was really popular – to the point where we had to apologise to our ISP because we were exceeding our bandwidth limits. I think we had something like ten thousand downloads in the space of a few days. This was before the days of Github and content distribution networks.
Our ISP, Bytemark in York, was very generous about it – they actually stepped in and sponsored our download server, which was very nice of them. This enabled us to continue releasing and pushing those releases out to other mirrors. We had a large network of mirror sites. That ran for a couple of years and eventually people got the idea that this was a worthwhile approach. Then other distros came onboard and started shipping realtime kernels, including Debian.
Prior to this their policy was ‘Real-time is dangerous, we don’t want a real-time kernel in our release’, because it was all a bit scary and new. But they came on board with that and I’m glad to say that all the good stuff we did has been carried on in mainstream Debian and fanned out to all Debian-based distros. Other distros have taken a similar approach too – Avlinux, for example, still makes that kind of distro for workstations.
LXF: It’s interesting to hear about all those CPU optimisations. I got properly into Linux around 2004 – I guess I was using Gentoo first on an Athlon XP, then later on one of the early Athlon 64s. It was quite thrilling to learn about all the USE flags and know that the binaries I spent two days compiling had all those optimisations.
DJ: We definitely used a lot of the ideas from Gentoo, we knew it was really good. But we also knew that Gentoo’s barrier for entry was too high for most of the users we were targeting. We wanted something that people could just download, burn and install. And then it would boot up into a working desktop.
It was important for us to broaden out the user base beyond hardcore users who were comfortable compiling their own stuff. From a community point of view, all of that individual learning you invest into your personal workstation isn’t necessarily shared out. Whereas
with the Debian model, where we were packaging these improvements and pushing them back out through our distro building tool, we found that was much more manageable for sharing those benefits. We wouldn’t knock Gentoo at all, but it wasn’t the right approach for the community we were looking at: creative people who had an interest in open source, but weren’t necessarily ready to go down that [rabbit hole].
LXF: Your talk has the rather fetching title of ‘PREEMPT_RT isn’t just for lasers: The perfect match for hearing aid research’, so I’ll certainly go along. Can you tell us what it’s all about?
DJ: I can introduce that and then I’ll pass you over to Chris, who did all the work on it. In 2009 there was a group at the University of Oldenburg in Germany called Hearing4all [http://hearing4all.eu/en]. It’s what they call a competence centre, which is basically a cross-collaboration between university and industry. The university has a spinoff, Hörtech, and that’s where these two come together.
They’ve been using Ubuntu as their base platform for their R&D workstation. They had a good idea that it would work, but they turned to us for some assistance [fine] tuning it. So what we did, in 2009, was to build a distro called Mahalia – the MHA part stands for Master Hearing Aid. All our codenames are based on artists and musicians, so this one’s named after Mahalia Jackson, the gospel singer. Our first iteration consisted of a Thinkpad X-series, the smallest, lightest, fastest thing available at the time.
LXF: I’m planning on getting a Thinkpad so that I can put Coreboot on it.
DJ: Yep, it’s a great bit of hardware. The actual hearing aid was a USB peripheral, so the idea was you could carry the laptop around in a backpack and have cables running to the earpiece. Then people could take the whole apparatus out in the street and field-test different algorithms and techniques – there are many ways of tackling hearing enhancement. They could leave the lab and go out into real-world environments with just a backpack for a couple of hours, until the battery went flat. More recently they wanted to make that more compact, easy to carry, and with a longer battery life, so they switched from AMD64 to Arm (see Back to Black, page
42). That’s when Chris joined the project.
LXF: I guess it’s all highly configurable from the user side? chris obbard: Exactly. The main difference between a software hearing aid running our openmha tools and an off-the-shelf hardware hearing aid is the fact that you can instantly change the software that’s running on it to give a different frequency response. With a hardware hearing aid, this may not be so straightforward. Our system is all about software reconfigurability.
LXF: I’m just imagining a bunch of Linux audio geeks reverse-engineering off-theshelf hearing aids to run DOOM.
DJ: We were at an audio conference in Berlin last summer, and there was a developer there with a cochlear implant who was actually working on a device to put his hearing into the ultrasonic range, so he could detect bats and things like that. So there are hearing aid hackers, but it’s quite a niche community…
I think the main benefits of this sort of research approach through universities is that if they want to try a new way of working, a completely new algorithm, the cost of that is relatively low because it’s just software. Once you bake that algorithm into hardware and you fix certain parameters, then if you’ve gone down the wrong route, that is going to be a very expensive mistake, because the cost of miniaturising the hardware is so high. What we’re doing is helping with the middle step, if you like, the one before the miniaturisation. It’s all about avoiding premature optimisation. Even if you get a successful algorithm, the work to make that run on this very limited hardware is expensive and time-consuming. So you want to be able to have a device which maybe doesn’t have as good a battery life as a real hearing aid, but gives you the flexibility to try different things before you bake them in and start optimising.
If your algorithm isn’t showing good potential at the field-test stage, then there’s really no point in miniaturising it. That’s mostly what the openmha platform is about; it’s not really intended that you could walk around in your daily life with this research platform running, but that option is there. People have put a simpler two-channel version onto a Raspberry Pi. Given the availability of boards like the Pi Zero and the Pocket Beagle that cost just a few dollars, it’s not impossible that people could do a completely DIY hearing aid. Simple stereo headsets are available on the open market.
diy hearing aids? “One developer is actually working on a device to put his hearing into the ultrasonic range.”
LXF: I’m quite attached to the Iqaudio HAT, and there are a bunch of other audiophile DACS available for the Pi. Does this kind of add-on board make the Pi a more viable platform for more advanced openmha usage? co: The problem is really still the twochannel limitation. There are solutions that exist, such as the Audio Injector Octo, which does allow eight channels. But what they’re actually doing is quite sneaky – they’re piping eight channels of audio into two. This is fine, but the problem comes when there’s an audio skip or a processing latency problem and one of the channels
jumps. Then you get all of your highfrequency sound coming out of a speaker it’s not intended for, and it blows that up. So that’s quite a risky approach in a realtime context. For the medical applications we’re aiming for, you really need reliability, so we’ve chosen a Texas Instruments part which has been verified for use in medical and industrial environments.
There’s always a compromise to make these things work. One of the things I’ve been looking into at the moment is some of the Allwinner chips, which have large channel counts. We’re seeing these sort of devices because of [demand for] home cinema systems. So you’re seeing Socs with 16 or 32 audio channels, coupled with a quad-core processor.
LXF: In my diverse adventures I’ve vaguely touched on the maths behind digital signal processing. It’s amazing how it all works, but pretty difficult for a beginner to get their head around.
DJ: There is a lot of maths involved, but happily I don’t have to deal with it.
If you wanted to get involved, though, there is a good community of audio plug-in developers – LADSPA and other communities on the Linux audio scene that’ve been around for a long time.
LXF: Tell me about Pideck. How did that come about? co: Pideck [http://pideck.com] is basically a digital vinyl system which is completely open source. It’s based on the Audio Injector card, which was funded through Kickstarter. It all started around 2014. We were at a not-for-profit festival on the Isle of Wight called Mondomix. Dan was having some trouble getting his digital vinyl system working while he was Djing, and he said “Wouldn’t it be easy if there was an open source bit of kit that I could plug in and it would Just Work?”. So then we got hacking.
DJ: Xwax [https://xwax.org] is a great application and it’s been around for a long time, but you do need a well-tuned system to run it effectively and with low latency. The physical turntables are very latency-sensitive, so you can hear whenever there’s any delay – you’ve got issues with hand-eye coordination to ear coordination. People have been running
xwax on PCS and laptops for a long time, but what we did was to package it for Arm and put it into a ready-to-go image for Raspberry Pis.
Again, we wanted to make this accessible to that broader community who were interested, but maybe not ready to dive deeply into how it all works. We’ve been doing this for a couple of years now, and there’s a user community on Youtube [www.youtube.com/c/pideck] who like to upload their own videos, which is always good to see. We’ve got people doing small, portable turntables into which they’ve built a Raspberry Pi and touchscreen. We’ve had people running reggae soundsystems with this – it’s all good fun. And we keep getting people popping up [with new ideas].
A particular thing at the moment seems to be people who have the older generation CDJS that don’t have some of the features of their successors – showing waveforms or supporting media playback from USB sticks, for example. They’re using the Raspberry Pi to retrofit CDJS to give them these new features. This is a great DIY project, given the cost of buying new hardware. There are other projects that use a keyboard and other live instruments in real time. The Raspberry Pi universe is just incredible for its creativity, and we’re very happy to be part of that through Pideck.
LXF: That seems much more productive then my festival experiences last summer. I guess it makes DJ life much easier, too.
DJ: It’s a common problem for DJS (and stage managers). They’ve got their laptops and their CDJS and their boxes and cables, so the changeover is quite cumbersome and you’ll always get some downtime. One of the fun things about the Pideck is that it’s very shareable. There’s no user data on the Pi itself – it’s all stored on the USB stick with the music. So one person can come along, pop a stick in and take over, without any further plugging, unplugging or cable swapping.
The latest thing in DVS [digital vinyl systems] is the MWM Phase system [https://mwm-store.com], which is an accelerometer that fits onto the label of the record. You don’t actually put the needle on the record – you use the accelerometer to send a signal to a receiver box, which then generates timecode for that rotation speed and direction. We’ve just had a user pop up and say they’re going to get one of these and make it work with the Raspberry Pi.
It looks unusual when you see people using it, because they’re doing the same actions on the turntables, but the needle is still on its rest. One of the problems with turntables is that the manufacturers of styli are going out of business or closing down, because it’s such a niche thing now and the tools that DJS have relied on for
decades are going away. Obviously there are practical difficulties with the stylus interface – fluff, greasy fingerprints and suchlike. So having the accelerometer on the record obviates all that.
LXF: Sunshine can be a bit of a vinyl killer too, eh?
DJ Yes, warped records – outdoor gigs in general are a hassle. We did one at our local skateboard park, and none of the records I brought with me came back flat. It was a hot day and there was no shade. One of the fun things about control vinyl [for DVS] is that it’s often not black and so deals with the heat rather better.
LXF: And expensive special-edition vinyl is often a different colour too.
DJ: Yep, red or purple or see-through. That’s actually a real practical benefit if they don’t melt in the sun, which is something I’d never thought of until I had a box of wobbly vinyl. One of the fun things about physical Djing with turntables is that because of Boiler Room [https://boilerroom.tv], people are interested in what DJS look like when they’re performing, rather than just what they sound like. So there’s more focus on the performance aspect, and we think turntables are good for that, compared to just sitting in front of a laptop.
At the Linux Audio conference they had a live coding concept at the Native Instruments headquarters in Berlin. There was a guy making the most intense, amazing music just sat at a laptop typing code. But then at the end people were like, “Is it finished?”, and then he took his hands off the keyboard and… [rapturous applause noise]. It’s a different performance style and I think people like the visual aspect. LXF: It’s interesting that 4 Studio is based on the Isle of Wight, which itself has a strong musical tradition…
DJ: Yup. We did a sort of music club in association with a festival and we got some kids involved with the Pideck. They get it straight away, because they don’t understand analogue vinyl, but they do understand digital music. So they’ll say things like “Why are you turning the record over?”, not understanding that there could be music on the other side. But the tactile aspect of turntablism is really popular with younger people. And they can work in groups and get hands-on with it – it’s a very different interface to the laptop and everything else they’re used to.
LXF: How does this compare to Traktor? I like to be quite down on Traktor because it’s a proprietary product (that I can’t afford) and it makes Djing (which I’m rubbish at) far too easy.
DJ: We’re trying to bridge that gap between too easy and too complicated. People might not want to take their expensive records out – it’s much easier to take a single control vinyl and a USB stick full of music. You don’t need to worry about people (or yourself) spilling beer on the records. And they’re really heavy to carry around too, not at all practical for taking on public transport. But Pideck’s been a really fun project. What it does is hide a lot of real-time complexity in a relatively easy to use interface. If people get into real-time audio processing through Pideck or a project like it, then that’s great. We’re trying to help people understand what’s going on behind the scenes as well, so all the tools we use to create the distro are open source. We’ve got all the wiki and Github pages up for explaining how to use certain things. We’re trying to be as open so we can to help other people learn what we know.
We’re hoping, in the next few months, to have a new release of our Platform Development Kit [https://github. com/64studio/pdk], which lets you create your own custom distribution.
LXF: That’s pretty cool. Ubuntu Customization Kit (UCK) seems to have fallen by the wayside now.
DJ: This is something we adopted from Progeny Linux Systems, which was around some years ago. We carried on using it, and we’re probably the only people still using it, but it suits our purposes. You basically create components, put them together and make a distro. It’s based on
Git so you get all the revision control for free, you can do reproducible builds, and it supports APT and Rpm-based repositories as well.