For completely legitimate reasons other than “I was bored in Lockdown” I commited to an CPU & motherboard upgrade on my studio machine, previously an Intel i7-6700.
I considered AMD, but stayed with Intel in the end. Mostly this was out of fear of PCI & USB stability issues, and slightly that I wanted to play with Thunderbolt for audio. There is one suitable Thunderbolt AMD board, but it has the B550 chipset which are limited on expansion. Plus Thunderbolt on Windows still feels a bit experimental and Intel felt safer in terms of getting support from manufacturers.
The new full spec is:
- Intel i9-10850K
- Gigabyte Z490 Vision D
- 64GB Corsair 3200Mhz
- 2TB NVMe
- Palit 2070 Super
Quick video editing aside, the combination of the new CPU and the fairly recent GPU upgrade (it was a GTX 970 up until August) makes my Premiere experience much smoother. I can now view 5 x 4K multicam footage without proxies, and view the final edit including FX without proxies at 50% resolution (which is absolutely fine in itself, and especially since the proxies would be 720p anyway).
But this post is really going to be about some Thunderbolt experiments with the Motu 1248. The 1248 is a Thunderbolt 2 device and I’m using the Apple Thunderbolt 3 to 2 adapter, and a 2m StarTech cable.
Why Thunderbolt?
USB has traditionally been the poor cousin of audio interfaces, given it wasn’t really designed for low latency work. Prior to Thunderbolt, Mac users had the option of Firewire but PC support was always a bit variable and dependent on exactly which TI chipset you had in your interface card.
The potential benefits of using the Thunderbolt interface on the 1248 are going beyond 64 channels (not relevant for me) and improved stability at low latencies.
Latency hasn’t been a huge deal for me historically as normally I’m recording all the parts at once so can just set the buffers to be huge for safety. The one exception to that is for the piano sessions where the sound is being generated by a VST.
Even with my normal recording style, there’s a potential benefit is being apply to have live monitoring for performers routing through the DAW rather than just via the hardware mixer. This would allow more live FX options, particularly reverb which is limited on the hardware.
Live recording
For my tests I used the final Beechmast mix as a base. This has 16 instrument channels, with various per-channel compression, EQ and reverb.
I started by adding another 8 recording channels, and set the Motu buffers to minimum. Minimum here is 16 samples buffer and 16 sample safety offset giving a round-trip latency of 1.6ms. I kept the safety buffer at 16 samples for all tests as it didn’t seem to make much difference in terms of stability and just increased latency.
In this configuration the output was stable with both USB and Thunderbolt. CPU usage hovered around 20% (more later) and I could even thrash a Web browser in the background and it stayed OK – which wasn’t true with my previous tests on the i7-6700.
To make it more of a challenge I ran 8 threads of Prime95 to load the CPU. With the extra load I started to hear clicks as the audio broke up. The Thunderbolt connection was slightly better than the USB, but it wasn’t bulletproof. I assume there’s some level of work at which the interface audio will be stable on Thunderbolt but not USB, but it feels like a small window.
One thing I noticed, in general, was that once the 1248 has broken up once it will likely continue to show issues even when the extra load is removed. To solve this you have to ‘reset’ it by changing the sample rate and changing back again. I’ve hit other issues with the 1248 that are solved the same way.
Live monitoring
My second test I replaced the 8 just-recording channels, with 16 recording-and-monitoring channels. Each of these 16 was set with record monitoring turned on (routed to various interface destinations) and had reverb and compression plugins enabled.
So now we have 32 audio channels in the DAW (plus some submix channels), 16 channels of audio being sent by the interface and 18 channels going to the interface.
Again, with both USB and Thunderbolt this was a stable configuration at the lowest buffer sizes, which is great because this is more than I’d ever ask of it (excluding perhaps adding a big piano VST).
One surprise for me was that the CPU usage for Reaper was very similar for both connection types. There may have been some hidden system CPU overhead for the USB version but I couldn’t observe it. At minimum buffer size of 16 samples (1.6ms round trip) CPU usage was around 23%. At 32 samples (2.6ms) it was 20%, at 128 samples (8.6ms) 9% and at 1024 samples (64ms) 6%.
Low power CPU comparison
I took the live monitoring test project and ran it on my laptop, an ageing Dell E7440 from 2013, housing an Intel i5-4300U with 8GB RAM. This is the laptop I actually use for portable recordings and it’s always been fine in the large-buffers-and-just-record configuration. This is USB only.
At minimum buffers it was a complete mess, not even able to keep up the playback speed. Things start to become recognisable at 64 samples. At this setting Reaper is claiming 60% CPU, but total overall CPU use is 100%. By 512 samples it’s 99% stable to listen to, and the recording seemed glitch free.
Something I noticed with the live monitoring project on USB with both the desktop and laptop was that it was unstable with the 1024 sample buffer, even when it was stable at lower buffer sizes. I’ll be sticking to 512 as my largest buffer size in the future.
Conclusions
- Thunderbolt works, which is great since not that long ago support on Windows for many manufacturers was still experimental. There was no special config needed, it was just plug-and-play
- Thunderbolt doesn’t offer a lot over USB on my desktop PC. I can do the same work with either connection
- The Motu 1248 USB implementation really is good
- The 1024 buffer size setting on the 1248 is bugged, stick to 512 if latency isn’t a concern
- CPU power is king. I’d prefer a high power machine with USB over a lower power one with Thunderbolt
- My laptop is closer to the end of its life than the start