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):
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.
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.
Parameters specified for capture should control hardware, power down-up should not.
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.
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.
$ 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.
$ 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.
$ 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.
Created attachment 141059 [details]
.asoundrc for quattro
Created attachment 141060 [details]
Device 1 capture with sine in both channels
Created attachment 141061 [details]
Device 1 capture after re-powering with sine in one channel and silence in another
Created attachment 141062 [details]
Device 2 capture with sine in one channel and silence in another
Created attachment 141063 [details]
2-device capture with sine in 2 channels (one per device) and silence in other 2
Created attachment 141064 [details]
Device 2 24-bit garbled capture with sine in one channel and silence in another
Created attachment 141065 [details]
2-device 24->32bit (plug) capture with sine in 2 channels (one per device) and silence in other 2
(This is a mass-update to all current FC6 kernel bugs in NEW state)
I'm reviewing this bug list as part of the kernel bug triage project, an attempt
to isolate current bugs in the Fedora kernel.
I am CC'ing myself to this bug, however this version of Fedora is no longer
Please attempt to reproduce this bug with a current version of Fedora (presently
Fedora 8). If the bug no longer exists, please close the bug or I'll do so in a
few days if there is no further information lodged.
Thanks for using Fedora!
This issue has been discussed in alsa-devel mailing list on several occasions:
I submitted a patch that partially fixes, partially works around the problem,
however due to time constraints I wasn't able to implement the complete
solution, nor was the patch accepted by Takashi. AFAIK the problem still applies
to Fedora 8. Devices affected: M-Audio Quattro, FastTrack Pro, Audiophile USB,
Adding the ALSA reference to this bug and closing upstream.