snd-usb-audio and M-Audio Quattro problems.

snd-usb-audio and M-Audio Quattro problems.

[Pavel Polischouk]

Hi!

I'm trying to make my Quattro work with ALSA 1.0.13. While this seems 
possible with some hacks, it's not a straightforward and hassle-free 
experience.

I submitted a bug report on the matter some time ago 
(https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2607), see there 
for detailed description. Short description: Quattro initializes itself 
to an unusable (or semi-usable) state and refuses to change its mode 
afterwards.

After seeing no activity on the bug for some time I decided to 
investigate the problem further. First I tried to extend the Audiophile 
hack to Quattro (that disables all altsettings on driver init except the 
one desired). Surprisingly it worked - almost. It only works the first 
time after Quattro has been powered up, after that, re-loading the 
driver doesn't help - the device sticks to the old state.

My temporary patch is available here:
https://bugtrack.alsa-project.org/alsa-bug/file_download.php?file_id=1630&type=bug

Are there any suggestions on how to make the device accept the changing 
settings? Perhaps there's a need for hardware reset or something similar 
between mode changes? Any suggestions/patches are appreciated.

Thanks,
Pavel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: snd-usb-audio and M-Audio Quattro problems.

[Thibault Le Meur]

Hi,

> I submitted a bug report on the matter some time ago
> (https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2607), see there
> for detailed description. Short description: Quattro initializes itself
> to an unusable (or semi-usable) state and refuses to change its mode
> afterwards.
>
> After seeing no activity on the bug for some time I decided to
> investigate the problem further. First I tried to extend the Audiophile
> hack to Quattro (that disables all altsettings on driver init except the
> one desired). Surprisingly it worked - almost. It only works the first
> time after Quattro has been powered up, after that, re-loading the
> driver doesn't help - the device sticks to the old state.


Yes that's the same for the audiophile Usb device: I have to turn off  
the audiophile usb card, then deregister (modprobe -r) the driver, and  
register it back with a device_setup parameter corresponding to the  
new device mode.

> Are there any suggestions on how to make the device accept the changing
> settings? Perhaps there's a need for hardware reset or something similar
> between mode changes? Any suggestions/patches are appreciated.

The windows driver only selects AltSettings 0 for all interfaces  
"multiple times" before switching modes. I tried to implement this but  
with no success. That's why I didn't included this in the first  
Audiophile USB patch. However I'm still interrested in a way to do this.

Another 'M-audio usb' user recently wrote a patch for the Fast track  
pro (however I'm not sure it has been included in the hg repository  
yet). I wonder if he had managed to handle such setup switching for  
his device.

Regards,
Thibault


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

RE : snd-usb-audio and M-Audio Quattro problems.

[Thibault Le Meur]

> >
> > After seeing no activity on the bug for some time I decided to 
> > investigate the problem further. First I tried to extend the 
> > Audiophile hack to Quattro (that disables all altsettings on driver 
> > init except the one desired). Surprisingly it worked - 
> almost. It only 


Your patch changes the AUDIOPHILE_* constant to MAUDIO_* constants.
This is ok, but the Fast Track Pro patch submitted by "Peter Oehry" would
need a trival rework to be applied.

> > works the first time after Quattro has been powered up, after that, 
> > re-loading the driver doesn't help - the device sticks to the old 
> > state.
> 
> Another 'M-audio usb' user recently wrote a patch for the Fast track  
> pro (however I'm not sure it has been included in the hg repository  
> yet). I wonder if he had managed to handle such setup switching for  
> his device.

See the "snd-usb-audio - Driver for M-Audio Fast Track Pro" thread (August
2006) from Peter Oehry.

HTH,
Thibault



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: snd-usb-audio and M-Audio Quattro problems.

[Pavel Polischouk]

Thibault Le Meur wrote:
> Your patch changes the AUDIOPHILE_* constant to MAUDIO_* constants. This is ok, but the Fast Track Pro patch submitted by "Peter Oehry" would need a trival rework to be applied.
> See the "snd-usb-audio - Driver for M-Audio Fast Track Pro" thread (August 2006) from Peter Oehry.
>   
Hmm, the old Audiophile and FastTrack discussions are fascinating 
reading. Seems like all M-Audio USB devices have the same or similar set 
of quirks and oddities that it's worth it to unify the approach to all 
of them.

Some observations:
1. All (please confirm for Audiophile) have some sort of 
usbaudio.sys-compatible functionality. In case of FastTrack it's a 
separate configuration, in case of Quattro it's a set of 2 streaming 
interfaces (#1 out, #2 in) within the single configuration. The 
"windows-compatible" pair of interfaces are *little-endian*, the rest 
are usually *big*endian* (except Quattro output interfaces which are 
little-endian). The windows-compatible interfaces only work with the 
first two channels, there's no windows-compatible interfaces for other 
two channels. This explains why the "default" driver setup 
(device_setup=0) gives the result of "2 channels little-endian, 
2-channels big-endian" (as I described in bug #2607) - the driver 
selects win-compatible interface for the first sub-device and the only 
available 16-bit interface for the second sub-device, and they are of 
different endianness. The device then locks itself into this useless state.
*Solution*: The win-compatible interfaces should be either completely 
ignored, or (if anyone ever needs them - maybe for some non-demanding 
applications that don't support big endian) made the ONLY available by 
the driver, perhaps with some module parameter. FastTrack seems to 
require additional quirks for that, or, looking from another angle, can 
provide an easier method of doing it completely in user space by writing 
a proper udev rule to select only the desired configuration.

2. All of these devices have 3 distinct operation analog modes: 16x11-48 
(all interfaces), 24x11-48 (2x4 or 4x2, bandwidth limitation) and 
24x88-96 (2x0 or 0x2). Some additional digital modes are also available 
for certain devices. Once a mode is chosen, it implicitly affects ALL 
interfaces - so choosing 16x48 for first device input and 24x48 for 
second output will NOT work. This is probably the reason why M-Audio 
chose to make two different (class-compliant and non-class-compliant) 
configurations for its devices, USB-Audio spec doesn't seem to define or 
permit such strict dependency between several interfaces, in the 
standard each interface is implied (or even defined? please correct me 
if I'm wrong) to be independent from others. So there's a need for the 
driver to explicitly forbid using incompatible interface altsettings.
*Current*solution* that is implemented: restrict the drivers to 
compatible list of altsettings upon load, specified by a module parameter.
*Limitations*:
 - Need to power-down and then power-up the device to change the mode. 
To overcome this, the device has to be set to "default state", by 
selecting "altsetting 0" for ALL interfaces, multiple times, but 
previous attempts to do this in Linux did not succeed.
 - Altsettings are chosen by their NUMBER, per device. Since altsetting 
numbers for each mode do NOT match among the devices, different set of 
quirks has to be implemented for each new (or old) device that needs 
support. Instead, the code should look at altsetting's data format and 
supported bit rates to decide if it should be included or not.
 - Need to reload the driver to select another mode. Once limitation 1 
is sorted out, there's a possibility of another approach - implement an 
ioctl (or other similar userspace-driven mechanism) to switch the device 
to another mode.

Plan of action:
1. Merge existing FastTrack and Quattro patches, leave quirks for the 3 
devices separate. *UPDATE*DOCUMENTATION*
2. Implement selecting either win-compatible or full mode.
3. Merge setting quirks for all devices by doing altsetting selection 
based on their inherent properties rather than number. When the user 
specifies a module parameter that is incompatible with the device (e.g. 
Digital output for Quattro), skip ALL altsettings.
4. Implement hot-reconfig.
5. Implement userspace mode selection (proc, ioctl,...). Might involve 
not "skipping" altsettings completely upon init, but rather making them 
"invisible" by some means, to be able to change the invisible flag to 
other altsettings later.

#1: I can do it easily, will send the patch later today.
#2 is already present in FastTrack patch, I can do it for Quattro and 
it's most likely the same for Audiophile but that needs verification.
#3 I can do partially, for analog altsettings only - Quattro doesn't 
have any digital interfaces.
#4:
> The windows driver only selects AltSettings 0 for all interfaces 
> "multiple times" before switching modes. I tried to implement this but 
> with no success. That's why I didn't included this in the first 
> Audiophile USB patch. However I'm still interrested in a way to do this. 
> I tried several patches in order to avoid this limitation (reset the 
> usb device, reset all interfaces to AltSet 0 several times before 
> re-setting them...) but nothing proved to be usefull for this issue.
Do you still have any of that code around? Can you send me an "attempt" 
patch so I can try it out locally? If not, can you point me to the 
existing code that sends "select altsetting zero" to the device?
I think I have an idea - and the keyword is to select altsetting-0 for 
"ALL interfaces", including the win-compatible ones! Anyway, this is 
worth playing around with.

#5: We need working #4 first, and then discuss the possible approaches.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: snd-usb-audio and M-Audio Quattro problems.

[Takashi Iwai]

At Tue, 21 Nov 2006 22:49:49 +0100,
Thibault Le Meur wrote:
> 
> > Are there any suggestions on how to make the device accept the changing
> > settings? Perhaps there's a need for hardware reset or something similar
> > between mode changes? Any suggestions/patches are appreciated.
> 
> The windows driver only selects AltSettings 0 for all interfaces  
> "multiple times" before switching modes. I tried to implement this but  
> with no success. That's why I didn't included this in the first  
> Audiophile USB patch. However I'm still interrested in a way to do this.
> 
> Another 'M-audio usb' user recently wrote a patch for the Fast track  
> pro (however I'm not sure it has been included in the hg repository  
> yet).

It's not in HG repo, AFAIK.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV