[alsa-devel] M-Audio FastTrack C400

[Chris Cavey]

Having never done kernel module debugging I resorted to littering printk 
everywhere. Crude but effective. I'll really need to look into setting 
up kernel debug in VirtualBox...

The C400 appears to be UAC2 device.

The root cause of the failure occurs during snd_usb_mixer_controls()

Following down the rabbit hole,

parse_audio_unit() discovers a type, UAC_MIXER_UNIT and beings to parse 
pins in parse_audio_mixer_unit()

A pin is found of type "7" which since this is UAC2 device, could be 
UAC2_EFFECT_UNIT or UAC1_PROCESSING_UNIT

We arrive at the following case in check_input_term:

                 case UAC1_PROCESSING_UNIT:
                 case UAC1_EXTENSION_UNIT: {
                         struct uac_processing_unit_descriptor *d = p1;
                         if (d->bNrInPins) {
                                 id = d->baSourceID[0];
                                 break; /* continue to parse */
                         }

The break ultimately results (after find_audio_control_unit returns 
NULL) in ENODEV which bubbles all the way back out to 
snd_usb_audio_probe(), goto returns NULL, back out to usb_audio_probe() 
which finally returns -EIO.

Being a little daring I replaced the break with "return 0;" - now the 
card is detected but fails trying to probe sample rates.

I copied the FIXED_ENDPOINT quirk descriptor from the FTU and trying to 
slam in workable values(channels = 2, ifnum = 2).

Viola! The card now completes probing and shows up as a device in aplay 
-L/-l.

Except I can't get it to play anything (figure it would all be too good 
to be true)

$ speaker-test -Dfront:C400
speaker-test 1.0.25

Playback device is front:C400
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
Sample format not available for playback: Invalid argument
Setting of hwparams failed: Invalid argument

$ amixer contents
numid=1,iface=MIXER,name='PCM Clock Source'
   ; type=ENUMERATED,access=rw------,values=1,items=2
   ; Item #0 'Unit 129'
   ; Item #1 'Unit 130'
   : values=0

On 04/20/2012 03:54 AM, Daniel Mack wrote:
> On 04/19/2012 10:53 AM, Clemens Ladisch wrote:
>> Chris Cavey wrote:
>>>   snd-usb-audio: probe of 1-1:1.1 failed with error -5
>>>   snd-usb-audio: probe of 1-1:1.2 failed with error -5
>>>   snd-usb-audio: probe of 1-1:1.3 failed with error -5
>> Are there no other messages immediately before this?
>>
>> Daniel, are there places where the code aborts without
>> print an error message?
> Yes, there are in fact some. -5 means -EIO, and the module probe will
> fail with this error code in case snd_usb_audio_probe() returns NULL.
> Chris, can you trace this functions in sound/usb/card.c and see where it
> bails?
>
>
>
> Daniel
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel