• Registered: 2010-09-26
  • Posts: 2

Topic: Multiface II alsa card number, module load order SOLVED

I have a Multiface II connected to a 64Studio (3.x beta version) work station.

The Multiface worked as advertised right out of the box. However, when I rebooted the machine, it wouldn't work. After two days of research, here is what I found and how I think I solved the problem.

Believe udev was loading the kernel modules in random order (random? can that really happen on a deterministic machine?). Using 'aplay -l' from the command line gave:

**** List of PLAYBACK Hardware Devices ****
card 0: CK804 [NVidia CK804], device 0: Intel ICH [NVidia CK804]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: CK804 [Nvidia CK804], device 2: Intel ICH - IEC958 [NVidia CK804 - IEC958]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: DSP [Hammerfall DSP], device 0: RME Hammerfall DSP + Multiface [RME Hammerfall DSP + Multiface]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Running 'cat /proc/asound/cards' gave:

0 [CK804    ]: NFORCE - NVidia CK804
                    NVidia CK804 with ALC850 at irq 22
1 [DSP       ]: H-DSP - Hammerfall DSP
                     RME Hammerfall DSP + Multiface at 0xfdff0000, irq 17

Running 'lspci' showed two "Multimedia audio controller:" entries. One for the onboard sound card (CK804 AC'97 Audio Controller) and one for the Multiface PCIe card (Xilinx Corporation RME Hammerfall DSP). No surprise there.

When I ran '/sbin/alsa force-reload' followed by 'aplay -l' the card number order alternated between the DSP and CK804. If card 0 was assigned to CK804, then the next time card 0 got assigned to DSP (and the Multiface worked as advertised). Rebooting the machine sometimes changed the card assignment order but more often than not, CK804 got card 0 (resulting in the Multiface not working).

The problem is that with DSP listed as "card 1" instead of "card 0" the Multiface would not work (hdspmixer would not work). The DSP related kernel module needs to get loaded first so alsa will get the indexes right (I guess udev is really what assigns the index numbers based on the module load order?). Running 'lsmod | grep snd' gives a list of the sound related modules loaded and their dependencies. As expected, snd_hdsp shows up in the list. Also, snd_ac97_codec which I assume is the module used by the AC'97 onboard audio controller. The snd_ac97_codec is dependent on snd_intel8x0. I needed to verify the associated kernel module names so I ran 'locate *.ko | grep hdsp' to get snd-hdsp.ko and 'locate *.ko | grep intel8x0' to get snd-intel8x0.ko.

After some research I discovered that udev reads files in /etc/modprobe.d and uses information in those files to load and initialize modules. In the modprobe.d folder, I created a file named 'sound' with the following two lines:

options snd-hdsp index=0
options snd-intel8x0 index=1

The purpose is to force the snd-hdsp module to get loaded first and the onboard audio controller module to get loaded second (by the way, I tried it with just the first line and it didn't work).

Rebooted the machine and presto, card 0 is now the DSP (Hammerfall) and card 1 is the onboard sound card. Now when I run '/sbin/alsa force-reload' followed by either 'aplay -l' or 'cat /proc/asound/cards', the DSP gets assigned as card 0 every time.

Now both the Multiface and the onboard sound card both work. By the way, I have the S/PIDF output of the onboard sound card connected to the S/PIDF input of the Multiface and routed to the Multiface outputs dedicated to the studio monitor speakers. Works great.

Looks like the options entries in the sound file worked.

I found these links were helpful:

http://wiki.debian.org/ALSA
http://alsa.opensrc.org/index.php/MultipleCards

Hope this helps the next guy.

  • Registered: 2010-09-23
  • Posts: 51

Re: Multiface II alsa card number, module load order SOLVED

Thanks for this info roloman, as am considering getting this device. I am still keen to get the Babyface, however if Linux compatibility is not found it's unlikely.

3 Reply by roloman (edited by roloman 2010-10-20 03:54:23)

  • Registered: 2010-09-26
  • Posts: 2

Re: Multiface II alsa card number, module load order SOLVED

Based on what I read on the internet prior to purchase and my own experience since purchase, I would say the RME Multiface II works great with linux (actaually, its the PCI/PCIe card that interfaces with linux).

I think I might have been confused when I was working through the problem posted above. After working with the Multiface for a while now, I think what was happening before was that when the device was loaded as device 0 and then as device 1 the audio outputs from the system were getting swapped (which caused audio to SPDIF IN and Playback/1 to get swapped) and being new to the mixer software I didn't notice that the sliders on Playback/1 were at zero. So I think it was working the whole time, I just didn't realize it. I think it is still import to ensure the load order for devices (using the "sound" file described above) so your inputs will be consistent (i.e. no swapping between system outputs).

Also, I have found that if I forget and leave the Multiface configured for 96k (instead of 48k or less) conversion, I won't get any sound from apps such as firefox plugin. That configuration mistake caused me to think the interface wasn't working when it was probably just not configured properly.

The mixer software (essential for configuring inputs, outputs, routing, and input levels) is not that difficult, but it took me a while to understand how it works (google for explanations, here is one: http://www.youtube.com/watch?v=bLIYGVYr … =related). It is actually very powerful.

The Multiface pretty much worked right out of the box (you need to have alsa-tools installed http://packages.debian.org/lenny/alsa-tools). The issues described in my original post actually turned out to be minor and as I said, I think some of the problem was operator error.

Overall I am very satisfied with the Multiface II. I use it on an AMD 64x machine running 64Studio beta 3.x. I use jack and Ardour to record tracks from guitar and keyboard (also use the other tool in 64Studio such as Linuxsampler, Rosegarden, Hydrogen). According to Jack, I have gotten the latency as low as 1.3 msec with no xruns. If you use HDSP configure to change the sampling rate, you have to remember to match the setting in the Jack setup or Jack will not launch.

I also have a MIDI cable connecting a Roland EP-7 keyboard. Have used the keyboard to control Bristol (http://sourceforge.net/projects/bristol/) via the Multiface II MIDI port.

Hope this helps.