M-Audio Fast Track Pro Issue

I am presently running Ubuntu 11.10 and have an M-Audio Fast Track Pro(FTP) that I am using with Ardour. The FTP has two different outputs, 1/2 and 3/4 which can be selected with an A/B switch. The monitoring of the audio inputs on the FTP is occuring on 1/2 and Ardour is outputting to the FTP on 3/4 so I cannot hear a click track when recording or I can hear the click track but no signal. I have been able to get the FTP to play the mic and the recording at the same time but only when connecting as hw:5 in qjackctl but this disables the ability to record. Any ideas on what to check or how to proceed would really help.

You might want to read this:

You’ll probably won’t like some things you read there, since I discard ubuntu (newer versions) for pro-audio.

I have not successfully been able to have 4 simultaneous outputs since JACK sees the card as two independent audio devices, which I believe that’s what the FTP is in a way, although some testing I did some time ago, I did succeed with the 4 ins

A lot of the possibilities this device has, just depend on the sample rate you are running it in since it’s a USB1 device, you can see them also in the specs page of the M-Audio official site.

Cheers!

@joegiampaoli: did you try using alsa_out to provide the additional channels for output?

@paul:

Yep! I even just did more testing to get some dumb “maybes” off my mind that just spawned from utter nothing with no avail. This device is too basic (perfect for one man show like me), although the sound quality is very good since I have done 16 vs 24 bit tests and the SNR difference is quite obvious between both. But I don’t know how M-Audio built this thing, I opened it once and did see two PCB boards inside layered one above the other which makes me think that it is a separate 2 device in one gadget that will work well with correct drivers that must emulate it as a single device, the thing is that even in class compliant mode it’s supposed to be able to output 4 channels which I also tried but just cant get it, qjackctl shows me the device as separate devices in the output list as hw:5,0 and 5:1 besides a hw:5 have tried all three and none will work, in my case this is no great deal because it will output to headphones + only 2 outs of the other 4.

But oh well, like I said, I don’t need 4 outs (besides headphones) my aim was to push it to 24 bits. Although the digital IN did become recognized besides the 2 analog INs with the patch, but if I want to use digital IN I get an xrun every ~1-2min, would you know what could be the cause? Is there a way to run JACK with some type of word length or similar? Or maybe not the case? Fast Track pro doesn’t have a word length sync jack or switch. Have tried it in 16 and 24 bit modes and still get that single xrun once in a while using only digital IN, and it’s a very noticeable one. So I only use 2 analog INs for now…

Thanks

I was wrong at saying that I get an xrun once in a while using the digital IN’s, actually it’s above a hundred I get every now and then. I just decided to fool and experiment a little more with this thing, also i just downloaded and compiled kernel 3.2.5 and was surprised it didn’t need the Fast Track pro patch any more, the thing runs out of the box in 24 bit mode with just creating the /etc/modprobe.d/fast-track-pro.conf file I specify in my blog and if commented or removed it runs in 16 bit self compliant mode, so I am happy they did integrate my work to the kernel, but when testing the digital IN’s same problem, hundreds of xruns here and there at random moments, so still trying to figure out what could be the cause, if anyone has any ideas I would greatly appreciate it.

Cheers

@paul:

Sorry I really didn’t actually test alsa_out or alsa_in that well, I was probably too tired the other day when I tried it, just fooling around now and yes, I do of course get 4 outs now and even 4 ins at 16 bit with these 2 commands, I was able to reduce digital input xruns quite a bit by raising the P/B up to 5 and F/P to 256 still get only one xrun in a while (still remarkably noticeable), so further testing, still thanks again! Will have to do some updating to my blog soon…

Well it’s getting a little better, I have managed to filter the xruns down to a single one with the Digital IN in this thing with almost no latency…, but that single xrun happens exactly every 56 seconds, I can’t find the culprit!

Any tips?

Using JACK2