From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

Description of problem:
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 ALSA bug #48 (https://bugtrack.alsa-project.org/alsa-bug/view.php?id=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.

Version-Release number of selected component (if applicable):
kernel-2.6.18-1.2798.fc6

How reproducible:
Always


Steps to Reproduce:
1. Perform capture using Quattro into a file
2. Re-power Quattro. Repeat step 1.
3. Change capture parameters. Repeat step 1.

Actual Results:
Changing capture parameters seems to have no effect on hardware. Power down-power up sequence gives 50% probability of changing capture endian in one of the channels.

Expected Results:
Parameters specified for capture should control hardware, power down-up should not.

Additional info:
It is suggested that the patch forcing Quattro to big-endian capture be reverted.

Further investigation needed about the ways to properly configure Quattro, any suggestions and temporary debug patches welcome.

Attaching .asoundrc

Examples of misbehavior (see attached streams):

$ arecord -r 44100 -c 2 -f s16_be -D quattro1 -d 1 -t raw q1-44100-c2-2sine.raw

The signal connected is static from grabbing the plug by the hand (almost 60Hz low-level sine) to both channels. Appears to be "good" big endian stream. Stream truncated to quarter-second.

After re-power-up:
$ arecord -r 48000 -c 2 -f s16_be -D quattro1 -d 1 -t raw q1-48000-c2-sine+silence.raw

Static connected to one channel, almost-silence (unconnected) other channel. Even though the driver thinks it's big-endian, the stream appears to be little-endian.

Second device:
$ arecord -r 48000 -c 2 -f s16_be -D quattro2 -d 1 -t raw q1-48000-c2-sine+silence.raw

appears to still be big-endian.

Combined 2-device 4-channel capture:

$ arecord -r 44100 -c 4 -f s16_be -D q4b -d 1 -t raw q4-44100-c4-2sine+2silence.raw

Static connected to left channel of one device and right channel of another, two other not connected. Two devices appear to be in different endian modes.

24-bit capture:
$ arecord -r 44100 -c 2 -f s24_3be -D quattro2 -d 1 -t raw q2-44100-c2-24bit-sine+silence.raw

The data appears to be garbled following very strict pattern: in each 3-byte (24 bit) sample, bytes 0-1 are big-endian 16-bit data, byte 2 is exact copy of byte 0. Most likely cause is the device not accepting the switch to 24 bit mode and sending 16 bit data, the driver treating it as 24 bit data.

"Plug" 24->32 4-channel capture:
$ arecord -r 44100 -c 4 -f s32_be -D q4 -d 1 -t raw q4 q4-44100-c4-24_32bit-2sine+2silence.raw

24-bit 4-channel data (2 static, 2 silence channels) padded to 32bit by "plug" interface. (see asoundrc). Same data copying byte0->byte2, pad in byte3 of each dword.

Switching 44100-48000 doesn't have any effect on the data endian patterns. I attached the captured streams that are the most visible representations of the problem, they happened to be of different sample rates. However, it is unclear if the bit rate switch really happened in hardware or not, it is possible that the device stays in the same sampling rate mode while the driver thinks the switch happened.