Whtch USB audio interface to choose

Actualy, I’ve got an M-Audio Fast Track Pro usb audio interface, I’m limited to 16 bits 48 000 Mhz recordind and I want to upgrade to an usb 2 or 3 interface with higher capability.
I’m using Ardour 5 with Jack on an Ubuntu machine on 4.8.0 kernel.
Somebody have son advise based on experience to help me choose my next gear ?


You realize that use of bit depths and sample rates greater than 16/48 or 16/44.1 being deficient are largely a false impression largely informed by myth, misinformation and the usual “bigger numbers are better” fallacies employed in marketing pretty much everything…

Before you spend a penny watch this: https://www.youtube.com/watch?v=cIQ9IXSUzuM

Beyond that if you simply want more channels there are quite a few supported now by Linux, also USB-3 to my knowledge is not supported with Linux and even causes problems with USB-2 Audio devices on Windows so should be avoided. Many people even disable USB-3 in their BIOS for Audio work.

Top picks are the Focusrite products, Presonus 1818VSL, NI Komplete, an outdated but ‘safe’ list is here: http://wiki.linuxaudio.org/wiki/hardware_support

Hi Ph,
I have the same interface and it should be usb 2. I have Ardour 5.5 and Ubuntu with a 4.4.0 low latency kernel.
Are you sure you’re limited to 16 bits? I usually record at 24 or 32.
Also. In the M-Audio manual it’s written that the A/D INs and OUTs have a frequency response from 20Hz to 20kHz, +/- 0,1dB with sample rate 48kHz and from 20Hz to 40kHz, +/- 0,1dB with a sample rate 96kHz, though I don’t know if it can record at 96kHz.

I was writing while GMaq was writing as well. I agree with him, it doesn’t mean that 96 is better than 48 than 44.1.
There is a point in which the human ear cannot hear the difference. To me the most important is the buffer, is it’s also connected to the soundcard.
Some time ago Michael Willis posted a link about it but it was on irc, so there’s no trace in here.

pdhemartin: If there is nothing wrong with your device and you don’t need any more channels then you don’t gain much by changing the device.

If you need more channels, check this recent discussion here: https://community.ardour.org/node/14143


Thank’s a lot for the advices
The truth is that it is not really possible to hear the diference from 44.100 to 48.000 or 96000 for the finished mix, but I like to record with a lot of overhead and use also a lot of treatment for the voices… I always wanted to record in 24 bit 96000 sample rate but neve be able to get that from the M-Audio fast track pro.
I’ve readed some post with specials kernel module argument to get those sample rates but I never reached it :frowning:
I will read all those discitions and learn some more. ;=;

24 bits is absolutely worth it. 96kHz is absolutely not worth it unless you have hardware a lot better than the fast track pro.


I should clarify that as Paul said 24bit should be preferred but 16bit isn’t as ‘bad’ as some people would have you believe…

If I recall from the old days the Fast Track Pro could use 24bit if it had some extra module tweaks placed in a configuration file in /etc/modprobe.d/

It should be possible to use 24bit with any Kernel 3.0+. Joe Giampaoli has a VERY detailed guide on his blog here:

I’ve dig up some old forums and tried to put those conf file in /etc/modprobe.d/ but it’s look like I would need to patch and recompile the kernel for that. And all the patch I’ve found was for 3.* kernels version.
And it look like that now, nobody updated those patch for mor recent kernels. :=(

Ok, that sounds like a valid reason to upgrade your card :slight_smile:

I’m not expert at all, but: do you have to compile the kernel specific for the fast track or you can use a normal low latency one? Since the newest is the 4.4 I wrote above, if the kernel doesn’t have something directly connected with the sound card, you can install the low latency and go on with the fast track.

Re:24 Bit
Yes and no.

24 Bit is absolutely a large improvement for recording purposes, especially when dealing with noise floors, but for delivery 16 bit is perfectly fine yes. But for recording purposes I will always recommend people go to 24 bit recorders over 16 bit. (OF course even 24 bit is a bit of a misnomer in actuality, but that is another topic:)


The Fast Track work fine in my system in 16 bit and 44.100 and 48.000 Mhz, but I’m not able to get it recording in 24 bits or with higher Frequencies than 48.000, I’ve tried all tha “Magic” comand line to load manually the kernel module and also the /etc/modprobe.d/ way, bot without succes.
First I was under OpenSuse, and now under Ubuntu.
i’m not an engineer but I run Linux for more than 20 years now, so or I’ve got some thing really wrong, or this hardware is really not fully supported.
Y will try to download som studio specific distribution to see if I can borrow some kernel already patched.


I doubt any modern Audio distros will be any better for you. I maintain AV Linux and my previous (now obsolete) AV Linux 6.X versions had full support for the Fast Track Pro and it worked @ 24bit out of the box, I know my current version (AV Linux 2016) no longer has any special provisions included in /etc/modprobe.d and unless there is upstream patching in our custom RT Kernel specifically for the Fast Track Pro my guess is you won’t be any further ahead. KXStudio uses the standard Ubuntu lowlatency kernels so it will offer you nothing specific to the Fast Track Pro that vanilla Ubuntu doesn’t already have available.

@GMaq @telover
Yep, I’ve updated my kernel to the standart 4.8.0-38-lowlatency and put the this fast-track-pro.conf in /etc/modprobe.d/
If I dont have this file, it cannot get back to 16 bit ???
(I’ve uploaded the working version on my server: http://demartinenchile.com/media/fast-track-pro.conf )

The 24 BIT - 44.1/48 KHz - 2 INPUTS (ANALOG) - 4 OUTPUTS (ANALOG + DIGITAL) Work

and the 16 BIT - 44.1/48 KHz - 4 INPUTS (ANALOG + DIGITAL) - 4 OUTPUTS (ANALOG + DIGITAL) Work also

but I was unable to get to work the 24 BIT - 88.2/96 KHz - 4 INPUTS (ANALOG + DIGITAL) OR 4 OUTPUTS (ANALOG + DIGITAL)

I’ts a big jump ahead, but I’m still limited to 48.000 mhz.
I thing that the problem is that Pulseaudio is geting the Fast-Track “output” mode and tha jack server cannot get it in input only, how is this configuration work… 4 input or 4 output.
Anyway, it’s sufficient for me to get 48.000. and geting only the input working is not optimal, I have only this sound card and I need to monitor the recording from the studio.

Thank’s a lot for the help.

Tue Feb 21 18:18:58 2017: creating alsa driver … hw:Pro,0|hw:Pro,0|128|2|48000|0|0|nomon|swmeter|-|32bit
Tue Feb 21 18:18:58 2017: configuring for 48000Hz, period = 128 frames (2.7 ms), buffer = 2 periods
Tue Feb 21 18:18:58 2017: ALSA: final selected sample format for capture: 24bit big-endian in 3bytes format
Tue Feb 21 18:18:58 2017: ALSA: use 2 periods for capture
Tue Feb 21 18:18:58 2017: ALSA: final selected sample format for playback: 24bit big-endian in 3bytes format
Tue Feb 21 18:18:58 2017: ALSA: use 2 periods for playback
Tue Feb 21 18:18:58 2017: graph reorder: new port ‘system:capture_1’
Tue Feb 21 18:18:58 2017: New client ‘system’ with PID 0
Tue Feb 21 18:18:58 2017: graph reorder: new port ‘system:capture_2’
Tue Feb 21 18:18:58 2017: graph reorder: new port ‘system:playback_1’
Tue Feb 21 18:18:58 2017: graph reorder: new port ‘system:playback_2’

the problem is that Pulseaudio is geting the Fast-Track "output"
In a system that's running Jack, you'd have to have a VERY good reason for keeping Pulseaudio. You almost certainly don't need it, and it can cause problems with Jack. My first step would be to remove it from any system that was being used for audio production.

The problem is that some software like Skype need PuseAudio and I use my workstation also for other things, not only audio recording :=(.
As a missionary living oversee, I need to comunicate with that kind of software.

In another topic, what is the problems generated by running a low latency kernel all the time ? Why it is not the default kernel for everybody ? is it related with electrical consumption or some incompatibility with some process ? Any clue ?

the low latency kernel is certainly an enemy of low power consumption. it trades (improved) latency for (worse) bandwidth, so it is also generally unsuitable for servers. the same feature also makes less appropriate than the default kernel for machines that will do lots of non-time-critical computation.

Unless you need VERY low latencies the normal kernels in recent distros should be “real-time enough”.

http://jackaudio.org/faq/pulseaudio_and_jack.html shows how to get Pulse and Jack to coexist.