Bug 215331 - M-Audio Quattro doesn't accept configuration requests
M-Audio Quattro doesn't accept configuration requests
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
https://bugtrack.alsa-project.org/als...
:
Depends On:
Blocks: 427887
  Show dependency treegraph
 
Reported: 2006-11-13 10:45 EST by Pavel Polischouk
Modified: 2008-08-02 19:40 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-09 01:31:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
.asoundrc for quattro (1.88 KB, text/plain)
2006-11-13 10:49 EST, Pavel Polischouk
no flags Details
Device 1 capture with sine in both channels (43.07 KB, application/vnd.rn-realaudio)
2006-11-13 10:50 EST, Pavel Polischouk
no flags Details
Device 1 capture after re-powering with sine in one channel and silence in another (46.88 KB, application/vnd.rn-realaudio)
2006-11-13 10:52 EST, Pavel Polischouk
no flags Details
Device 2 capture with sine in one channel and silence in another (46.88 KB, application/vnd.rn-realaudio)
2006-11-13 10:53 EST, Pavel Polischouk
no flags Details
2-device capture with sine in 2 channels (one per device) and silence in other 2 (86.13 KB, application/vnd.rn-realaudio)
2006-11-13 10:54 EST, Pavel Polischouk
no flags Details
Device 2 24-bit garbled capture with sine in one channel and silence in another (64.60 KB, application/vnd.rn-realaudio)
2006-11-13 10:57 EST, Pavel Polischouk
no flags Details
2-device 24->32bit (plug) capture with sine in 2 channels (one per device) and silence in other 2 (172.27 KB, application/vnd.rn-realaudio)
2006-11-13 10:58 EST, Pavel Polischouk
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
ALSA Project 2607 None None None Never

  None (edit)
Description Pavel Polischouk 2006-11-13 10:45:01 EST
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.
Comment 1 Pavel Polischouk 2006-11-13 10:49:10 EST
Created attachment 141059 [details]
.asoundrc for quattro
Comment 2 Pavel Polischouk 2006-11-13 10:50:38 EST
Created attachment 141060 [details]
Device 1 capture with sine in both channels
Comment 3 Pavel Polischouk 2006-11-13 10:52:11 EST
Created attachment 141061 [details]
Device 1 capture after re-powering with sine in one channel and silence in another
Comment 4 Pavel Polischouk 2006-11-13 10:53:08 EST
Created attachment 141062 [details]
Device 2 capture with sine in one channel and silence in another
Comment 5 Pavel Polischouk 2006-11-13 10:54:41 EST
Created attachment 141063 [details]
2-device capture with sine in 2 channels (one per device) and silence in other 2
Comment 6 Pavel Polischouk 2006-11-13 10:57:19 EST
Created attachment 141064 [details]
Device 2 24-bit garbled capture with sine in one channel and silence in another
Comment 7 Pavel Polischouk 2006-11-13 10:58:28 EST
Created attachment 141065 [details]
2-device 24->32bit (plug) capture with sine in 2 channels (one per device) and silence in other 2
Comment 8 Jon Stanley 2008-01-07 20:48:07 EST
(This is a mass-update to all current FC6 kernel bugs in NEW state)

Hello,

I'm reviewing this bug list as part of the kernel bug triage project, an attempt
to isolate current bugs in the Fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug, however this version of Fedora is no longer
maintained.

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!
Comment 9 Pavel Polischouk 2008-01-10 12:36:26 EST
This issue has been discussed in alsa-devel mailing list on several occasions:

http://thread.gmane.org/gmane.linux.alsa.devel/42396

http://thread.gmane.org/gmane.linux.alsa.devel/47415

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,
OmniStudio USB.
Comment 10 Jon Stanley 2008-03-09 01:31:23 EST
Adding the ALSA reference to this bug and closing upstream.

Note You need to log in before you can comment on or make changes to this bug.