M-Audio multichannel patch?

[dewdrop_world]

Hi, haven't been around in a while (quite busy).

Ubuntu 10.04, real-time kernel

I've been using an M-Audio fast track pro using the generic USB audio driver quite well, but getting only two of the available four outputs. Eventually, I will need to try to get all four.

http://www.alsa-project.org/main/index. ... dor-MAudio says:

USB Fast Track Pro: Reduced functionality in class-compliant mode, patch available for more features. See this page

... where "this page" directs to http://alsa.opensrc.org/index.php/M-Audio_FastTrack_Pro

Unfortunately (and somewhat shockingly), alsa.opensrc.org is blocked in mainland China. (It's not the only such surprise I've encountered; I've also had problems, inexplicably, with midiox.com, git-scm.com and opencv.willowgarage.com. It seems altogether arbitrary.) I use a proxy to get through to a lot of sites, but even this proxy can't access alsa.opensrc.org!

So I'm asking if anyone has successfully set up the patch. What's involved? Is there any alternate way to get the required files (or do I have to wait until I travel back to the US on summer holiday)?

Thanks --
James

[varpa]

Just for your information http://alsa.opensrc.org/index.php/M-Audio_FastTrack_Pro does not work for me either in the US. I think alsa.opensrc.org is offline.

[Pablo]

Neither for me in Europe. It is definitely offline. It's a shame as there are very good docs.

IIRC, "the reduced functionality" refers to the fact that the standard driver supports/supported a bit depth of "only" 16 bit. With that patch, the card works at 24 bit. If you are OK with the sound, then no problem.

As for the missing outputs, they are probably available as a separate alsa "device". I think you can make them show up via "alsa_out". But to confirm, what is the terminal output of

aplay -l

?

[dewdrop_world]

Neither for me in Europe. It is definitely offline. It's a shame as there are very good docs.

IIRC, "the reduced functionality" refers to the fact that the standard driver supports/supported a bit depth of "only" 16 bit. With that patch, the card works at 24 bit. If you are OK with the sound, then no problem.

As for the missing outputs, they are probably available as a separate alsa "device". I think you can make them show up via "alsa_out". But to confirm, what is the terminal output of

aplay -l

?

Oh, OK, bummer about alsa.opensrc.

I guess you're right about the outputs. I do get two devices for the FastTrack Pro.

Code: Select all

dlm@dlm-laptop:~/share/sc.git/build$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC662 rev1 Analog [ALC662 rev1 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 3: INTEL HDMI 0 [INTEL HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 7: INTEL HDMI 1 [INTEL HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Pro [FastTrack Pro], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 1: Pro [FastTrack Pro], device 1: USB Audio [USB Audio #1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

James

[Pablo]

Yes!

Try this command after starting jack:

alsa_out -dhw:Pro,1 -joutputs34

and check qjackctl connections

If it works, you can type it as a "script after jack server starts" in qjackctl, options.

Cheers! Pablo

[dewdrop_world]

Indeed it does! I see "outputs34" in the connection window.

From there, it should be a simple matter to connect SuperCollider's hardware output busses 2 and 3 (starting from 0) to outputs34. (SC uses environment variables to configure the audio server's default Jack connections, piece of cake.)

Unfortunately I can't fully test at the moment, for lack of a RCA-to-RCA cable ! But I have no reason to doubt that it will work.

I've been wondering about this for the better part of a year... I had postponed it because the alsa-project website made it sound like I would have to compile kernel modules . But then I read the instructions more carefully and found that those kernel modules are already there in Ubuntu 10 by default... so access to the other two channels must be by some other mechanism, which you just explained to me.

Thank you!
James

[Pablo]

Cool!

Needless to say, you can change the jack client name (after "-j") or even remove it altogether. Only the alsa device, after the "-d" flag, is essential.

I am not so sure that you have the "good" kernel module though. In any case, it is not bad if you can actually make music with whatever you have.

[dewdrop_world]

Sorry to revive this thread, but I finally had a chance to test this yesterday and the output through alsa_out was really terrible, like it was clipping by a large factor (even though I was feeding it a sinewave at only -26 dBFS).

I suspect the resampling -- strange, though, because both logical devices belong to the same physical audio interface. I would have expected them to use the same clock.

alsa_out manpage says this: "As of jack-0.116.3 this works almost perfectly. It takes some time, to reach absolute resample-rate stability. So give it some minutes (its [sic] intended to be running permanently anyways)" -- I didn't do this in my test. Would that make a difference?

The resampling is quite CPU expensive. Jack's load goes from about 1% to 8-10% by starting alsa_out. Supposedly alsa_out should not be resampling if the devices are at the same sample rate, and I thought they would be at the same sample rate since they're both on the same box. Faulty assumption? (I see I can save some CPU using -q.)

Also, I'm using Jack2 -- according to [1], I can use "audioadapter." Would that get any better results? (Can't try at the moment.)

James

[1] http://ubuntuforums.org/showpost.php?p= ... ostcount=2
^^ edit, forgot the footnote

[dewdrop_world]

Sorry to revive this thread, but I finally had a chance to test this yesterday and the output through alsa_out was really terrible, like it was clipping by a large factor (even though I was feeding it a sinewave at only -26 dBFS).

Following up, in the absence of a response.

The information from the man page is correct. The sample rate conversion done by alsa_out is unstable for the first few minutes, but it does eventually lock in.

My test was to pan a sine wave around in a circle: assuming the channels are FL, FR, RL, RR:

Code: Select all

a = {
	PanAz.ar(
		4,
		SinOsc.ar(440, 0, 0.05),
		LFSaw.kr(0.2)
	)[[0, 1, 3, 2]]
}.play;

The rear outputs (handled by alsa_out) have little glitches for a while that eventually become less frequent until they disappear altogether.

-q0 also saves a TON of CPU. It took longer to stabilize, but it did eventually get clean.

I think I can work with this for the most part. BUT...

It could be a problem if I have to present a four channel piece and it isn't possible to leave my laptop running for some minutes before the performance. Or if something crashes and I have to reboot -- "I'm all booted up, but sorry, I can't play for 10 minutes yet."

So I guess I'll have another go at tweaking .asoundrc -- I think I tried this once before (for inputs rather than outputs) and failed. But that was when I was a relative Linux-audio noob. Maybe I understand it better now.

Any other options?
James

[Pablo]

Any other options?

Although I knew the existence of different alsa "devices" and the alsa_in/out trick I am lost with the subleties of linux audio. So I suggest you ask in the linux audio users mailing list. Many experts are there while only a few of them are active here at linuxmusicians. If I remember correctly, Fons pointed out these problems in alsa_in/out and he proposed an alternative.

Cheers, Pablo