Thinkpad X61s Fedora 10 PlanetCCRMA M-Audio Configuration

From Justin's Wiki

Jump to: navigation, search

Contents

Make sure the Hardware works

First, just to make sure I don't have damaged goods, I try this on a windows machine. I do this not because of a lack of confidence in ALSA, LINUX, Fedora, or any of the fine open source developers of the world, but because I'm new configuring alsa with multiple soundcards, and to pro audio in general. Windows should work well enough for a test, as most users of the M-Audio Quattro are probably Windows users.

I'm getting the Windows XP driver and trying it on a Windows XP laptop: http://www.m-audio.com/index.php?do=support.drivers&f=292

It worked fine. I tried it at several bitrates. I noticed that for each of the modes you can put it in with the M-Audio Control Panel, several bitrates were available for each mode. The modes only seemed to be defined by how many bits wide the samples were: 16 or 24, and by how many inputs were in and how many were out: 4in/4out, 2in/4out, 4in/2out, etc.

What this looks like under windows is beyond the scope of my article.

aplay and arecord

Testing sound: http://www.alsa-project.org/main/index.php/SoundcardTesting I'm doing to change things up from that article though because I want to record and then play. this also lets us test whether we can hear anything from our recording. You can always check the arguments for arecord and aplay with arecord --play or aplay --help.

cd is a shortcut for 44100Hz 16 bit little endian samples in stereo. Notice the verbose output below from -vv.

arecord -vv -D plughw:1 -fcd -foo.wav
[justin@paddy ~]$ arecord -vv -D plughw:1 -fcd -d5 foo.wav
Recording WAVE 'foo.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
Plug PCM: Linear conversion PCM (S16_BE)
Its setup is:
  stream       : CAPTURE
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 22050
  period_size  : 5513
  period_time  : 125011
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 5513
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 22050
  silence_threshold: 0
  silence_size : 0
  boundary     : 1445068800
Slave: Hardware PCM card 1 'USB Audio Quattro' device 0 subdevice 0
Its setup is:
  stream       : CAPTURE
  access       : MMAP_INTERLEAVED
  format       : S16_BE
  subformat    : STD
  channels     : 2
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 22050
  period_size  : 5513
  period_time  : 125011
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 5513
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 22050
  silence_threshold: 0
  silence_size : 0
  boundary     : 1445068800
#########+                                         | 16%

The level changed as I sang into my mic which goes through a mic preamp before going to the first input on the maudio. I go directly out from the output 1 to my stereo headset. That's a balanced output, so plugging a stereo headset means, that I'm only going to hear one channel of audio, and that I'm not going to hear the second channel. (It should also mean I'm hearing the inverse wave in the opposite ear, but the brain doesn't care). So first I'll play it back, then I'll plug the headset into the second output, to make sure I'm getting stereo out.

[justin@paddy ~]$ aplay -D plughw:1 foo.wav 
Playing WAVE 'foo.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo

I tried that in each of the 4 inputs, and heard audio in only the first one. plughw:1 is understood to be 1,0. I'd expect 1,1 to only play in 3, and it does:

[justin@paddy ~]$ aplay -D plughw:1,1 foo.wav 
Playing WAVE 'foo.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo


My understanding of this so far is that a sound card has one or more PCM device. These devices can do pulse code modulation which is a specific way of doing digital sampling. You sample thousands upon thousands of times per second to get the level on the microphone at that particular point in time. Put all these together and you have a high resolution map of the sound not unlike the way pixels are represented digitally and reproduced as colors.

aplay -l and arecord -l give us all the devices we can play and capture from:

[justin@paddy ~]$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: AD198x Digital [AD198x Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Quattro [USB Audio Quattro], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Quattro [USB Audio Quattro], device 1: USB Audio [USB Audio #1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
[justin@paddy ~]$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog]
  Subdevices: 2/2
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
card 1: Quattro [USB Audio Quattro], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Quattro [USB Audio Quattro], device 1: USB Audio [USB Audio #1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

I find a /dev/mixer and a /dev/mixer1. I find in http://www.alsa-project.org/main/index.php/Matrix:Module-usb-audio, "Note that some usb-audio devices do not have internal mixer controls"

For now I'll assume this interface has no mixer.

.asoundrc

The next step according to PlanetCCRMA is to create an .asoundrc appropriate for your device. Reading http://alsa.opensrc.org/index.php/Asoundrc we see that, "Neither .asoundrc or /etc/asound.conf is normally required. You should be able to play and record sound without either (assuming your mic and speakers are hooked up properly). If your system won't work without one, and you are running the most current version of ALSA, you probably should file a bug report."

Well, the M-Audio Quattro *can* work with no .asoundrc, but you won't be able to use it fully.

.asoundrc from alsa.opensrc.org

Using http://alsa.opensrc.org/index.php/Midiman_Quattro_.asoundrc :

The article says: "the quattro can only do stereo i/o for 96000hz 24bit, 2i/1o or 1i/2o at 48000hz 24bit, 4i/4o at 48000hz 16bit in windows and mac environments. YMMV in Linux :)".

I'm taking this to mean:

inputs/outputs Sample Rate Sample Width
2i/0o or 0i/2o96000Hz24bit
2i/1o or 1i/2o48000Hz24bit
4i/4o48000Hz16bit


using .asoundrc from the article mentioned above for my own ~/.asoundrc, I found that it was incorrect and corrected it on their wiki. It was incorrect for the following reasons:

  1. this .asoundrc refers to 3 devices (0,1, and 2) I only find two devices for this card in aplay -l/arecord -l
  2. Devices composed of hw:1,1 and hw:1,2; should be hw:1,0, and hw:1,1?
  3. Comments about different devices being for different bitrates is false. That can be configured through the device at initialization - i.e. when you start recording / playing back using a particular device.

For my particular setup:

  1. having "card 0" be "card 1" as this is what I've defined in modules.d in a previous section on Multiple Sound Cards. Also wherever there is "hw:0" change that to "hw:1" also.


This is what was there:

# quattro1 is pcm0 which has a maximum sample rate of 44100 and 16 bit stereo

       pcm.quattro1 {
                 type hw
                card 1
        device 0
         }
 
          ctl.quattro1 {
                 type hw
                 card 1
         }
    
# quattro2 is pcm1 which has a maximum sample rate of 96000 and 24 bit stereo

         pcm.quattro2 {
                 type hw
                card 1
        device 1
         }
 
          ctl.quattro2 {
                 type hw
                 card 1 
         }
    
# quattro3 is pcm2 which has a maximum sample rate of 96000 and 24 bit stereo

         pcm.quattro3 {
                 type hw
                card 1
        device 2
         }
 
          ctl.quattro3 {
                 type hw
                 card 1
         }

#----    

#
# compose 4 channels from two channel x two devices, hw:2,1 and hw:2,2
# assuming that hw:2,1 and hw:2,2 give the same condition, 24_3LE/96k
#

pcm.quattro {
        type multi;

        slaves.a.pcm "hw:1,1";
        slaves.a.channels 2;
        slaves.b.pcm "hw:1,2";
        slaves.b.channels 2;

        bindings.0.slave a;
        bindings.0.channel 0;
        bindings.1.slave a;
        bindings.1.channel 1;
        bindings.2.slave b;
        bindings.2.channel 0;
        bindings.3.slave b;
        bindings.3.channel 1;
}

ctl.quattro {
        type hw;
        card 1;
}


#
# remap 4 channels as interleaved.
# use plug instead of route here, since 24_3LE is unlikely supported by
# applications.
#
# arecord -r 44100 -c 4 -f s16_le -D q4 -d 5 /home/xxx/q4.wav 

pcm.q4 {
        type plug;
        slave.pcm "quattro";
        ttable.0.0 1;
        ttable.1.1 1;
        ttable.2.2 1;
       ttable.3.3 1;
}



ctl.q4 {
        type hw;
        card 1;
}

#
# Use route plugin for applications that do support 24_3LE
# This lowers latency which the plug plugin introduces due to resampling.
#
#   arecord -r 44100 -c 4 -f s16_le -D q41 -d 5 /home/xxx/q41.wav



pcm.q41 {
        type route;
        slave.pcm "quattro";
        ttable.0.0 1;
        ttable.1.1 1;
        ttable.2.2 1;
        ttable.3.3 1;

}

ctl.q41 {
        type hw;
        card 1;
}

#----


My .asoundrc

The .asoundrc I found above at alsa.opensrc.org wasn't working. Ingomueller.net created this article originally from the article on the old wiki, so the file's origin is unknown to me. I try various combinations of options in arecord and aplay to find out what the device really will do with and without changes to .asoundrc. It seems to me that this .asoundrc makes a bit more sense based on the following:

  1. I only have two pcms
  2. a pcm isn't locked in to record at a certain rate, but can do many things at the same time. /proc/asound/Quattro/stream0, and stream1 seem to correspond to the two pcm's capabilities under alsa. They each list interfaces for Playback and Capture - each interface listing a different rate. Setting the rate seems like something an application like arecord would be able to do at the time of record or playback.


[justin@paddy ~]$ cat .asoundrc 
# The Quattro seems to only have two pcms, not 3.
# quattro1 is pcm0 

       pcm.quattro1 {
                 type hw
                card 1
        device 0
         }
 
          ctl.quattro1 {
                 type hw
                 card 1
         }
    
# quattro2 is pcm1 

         pcm.quattro2 {
                 type hw
                card 1
        device 1
         }
 
          ctl.quattro2 {
                 type hw
                 card 1 
         }
#----    

#
# compose 4 channels from two channel x two devices, hw:1,0 and hw:1,1
#

pcm.quattro {
        type multi;

        slaves.a.pcm "hw:1,0";
        slaves.a.channels 2;
        slaves.b.pcm "hw:1,1";
        slaves.b.channels 2;

        bindings.0.slave a;
        bindings.0.channel 0;
        bindings.1.slave a;
        bindings.1.channel 1;
        bindings.2.slave b;
        bindings.2.channel 0;
        bindings.3.slave b;
        bindings.3.channel 1;
}

ctl.quattro {
        type hw;
        card 1;
}


#
# remap 4 channels as interleaved using plug.
# 

pcm.q4 {
        type plug;
        slave.pcm "quattro";
        ttable.0.0 1;
        ttable.1.1 1;
        ttable.2.2 1;
       ttable.3.3 1;
}



ctl.q4 {
        type hw;
        card 1;
}

#
# Use route plugin 
#



pcm.q41 {
        type route;
        slave.pcm "quattro";
        ttable.0.0 1;
        ttable.1.1 1;
        ttable.2.2 1;
        ttable.3.3 1;

}

ctl.q41 {
        type hw;
        card 1;
}

#----


various tests

This section became long and contains a fairly systematic march through the .asoundrc, testing the devices and finding settings that work. See Thinkpad X61s Fedora 10 PlanetCCRMA M-Audio Configuration various tests.

Current alsa-info

http://www.alsa-project.org/db/?f=7c12e0783cd61a07993a53ea35561e20e9b4e457

Useful Jack Settings

I'm using qjackctl to create useful settings and save time typing in jackd commandlines. The following are settings I found useful. For more information on how these came about, #various tests

The usb-audio problem with the M-Audio Quattro

I stumbled upon this problem through trial and error in the previous section, #.asoundrc, but later when searching for this problem found that Pavel Polischouk had already reported it in Redhat's bigtrak (closed upstream as it was an alsa problem), and in alsa's bugtrack, https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2607

It appears that M-Audio refuses to accept the configurations set by the driver and stubbornly remains in whatever mode it initialized itself upon power-up (or what Windows driver configured it to). The situation gets complicated by the fact that the power-up configuration can be different betwen re-initialization, making the usage of some pre-defined configuration unacceptable. This problem was discussed before in bug #48. At that time it was suggested that Quattro has only big-endian capture, but it appears that this is NOT the case. Quattro happily supports both little- and big-endian formats, only it doesn't recognize Linux drivers requests to swich from one to another. Its boot-up configuration is unstable - for capture, it can configure one of its interfaces into big-endian and another into little-endian, or both into big-endian; it rarely configures itself into both little-endian; for playback it seems to always configure itself into little-endian on both interfaces. It also doen't accept the request of changing to 24bit mode. While the driver reports the mode change was successful, it apparently isn't the case - the captured stream looks like 16-bit stream mis-interpreted as 24-bit.

The Quattro is actually ignoring configuration requests from the usb-audio driver apparently. I'm contacting him to see if I can help in any way. I'm curious about methods for capturing all information going across the USB interface to and from the card. If there were a solid method of doing this in such a way that information could be collected during effective configuration changes in Windows, I'd think this information could be used to hack the usb-audio driver into effectiveness.

I don't know how long those last, so I'll place it here as well:

Fedora 10 PlanetCCRMA alsa-info 20090315 1510

See Also

Personal tools