cancel
Showing results for 
Search instead for 
Did you mean: 

STRIX RAID DLX - Can the control box be made functional under Linux?

lss41771
Level 7
At present I'm able to get my STRIX RAID DLX (0b05:180c) working under Linux. However, it turned out that the control box does not function and I couldn't switch between speaker and headphones through any other means than the box, even from system sound settings (there's only Analog Output, with configurations for stereo, 2.1, 5.1, 7.1 etc.), so I'm now stuck with headphone output. The hardware is correctly recognized as STRIX RAID DLX, though. I'm not certain which part (driver or API) might be needed for the operation of the control box (such as toggling and muting outputs) under Linux, either through ALSA, or PulseAudio which my distro uses.

Additionally, it seems the Asmedia USB controller the card utilizes has problems under Linux, that I need to pass "iommu=soft" to the boot parameter in order to get it working, or it'll complain about being unable to assign a slot for the device, like below, and fail to initialize.


[ 25.914386] xhci_hcd 0000:06:00.0: Error while assigning device slot ID
[ 25.914389] xhci_hcd 0000:06:00.0: Max number of devices this xHCI host supports is 32.


I'm not sure if this is a bug with the xhci_hcd, or it's just an incompatibility between Linux XHCI and the Asmedia ASM1042A controller, as apparently there were other cases where "iommu=soft" is needed for XHCI controllers, though some, like VIA's, also work with "iommu=pt". Unfortunately, "iommu=pt" doesn't work for this one as far as I have tested.

Back then with my old Xonar Essense ST (PCI, and it works flawlessly out-of-box) I was able to manually switch between them under Linux, but since my new motherboard doesn't have PCI slots and I intended to move to a relatively better product, this comes out as quite a disappointment. If only the control box works (maybe plus other excellent hardware-level effect adjustments, if any) then the card (possibly along with the entire STRIX series) would be an excellent choice for Linux.

PS, the comparable SNR and the advanced-looking control box was the main reason I decided to upgrade it further should my motherboard no longer support PCI, as at present, I've been using the Xonar Essence ST with the control box that came with an old Sound Blaster ZxR of mine (mostly for managing headphones and mic, with physical volume adjustment. The Sound Blaster card itself is currently placed in a dedicated Windows machine, as the card ironically doesn't work under Linux at all, even after this many years since it came out).

EDIT: I'm fully aware that I might be asking for the impossible, but I sincerely wish there be a *proper* method to switch between outputs. I don't see switch options on alsamixer, either (though there is an input switch between Line In and Mic).
6,620 Views
10 REPLIES 10

MasterC
Community Admin
Community Admin
Sorry, the card was made for Windows.
73363
_____________________________________________________________
FPS, Racing, and VR Gamer / Tech Enthusiast / ROG Admin

MasterC@ASUS wrote:
Sorry, the card was made for Windows.
73363


Guess I'll need to turn to the ALSA community for the answers.

But still, as for 4.16 kernel, except output switching, the control box, and the requirement of "iommu=soft" when booting, everything else on this card works without major issues on Linux.

MasterC
Community Admin
Community Admin
It's great you actually got the card to work anyway!
_____________________________________________________________
FPS, Racing, and VR Gamer / Tech Enthusiast / ROG Admin

As I currently don't have any spare Windows machines to test further... I could only test and look for clues on Linux whenever I have some spare time.

The control box is actually a HID device presented by a microcontroller within the CM6632AX audio processor, and from what it looks, the Sonic Studio (on Windows) is needed to interact with this HID device and control certain functionalities on the sound card. The HID device itself is detected and functional (I could capture the descriptor and messages from the control box through usbhid-dump), just there's currently no programs capable of initializing and interacting with this device under Linux. From the descriptor obtained through usbhid-dump, the hidrd-convert tool reveals the device is simply a consumer control device.

Usage Page (Consumer),      ; Consumer (0Ch)
Usage (Consumer Control), ; Consumer control (01h, application collection)
Collection (Application),
Logical Minimum (0),
Logical Maximum (255),
Report Size (8),
Report Count (16),
Usage (00h),
Input (Variable),
Usage (00h),
Output (Variable),
End Collection


The jack auto switching events (when you plug or unplug the headphone jack on the sound card) seems to be a programmed behavior transparent to the audio driver. At least from Linux, when the jack switching happens (the relay clicks) I wasn't able to find anything generating related logs, implying the switching is probably done at a lower level that the OS or the driver doesn't know (and doesn't need to know) about it (to the OS/driver, the speaker and headphone jacks are indistinguishable). From what I've tested, this jack auto switching behavior persists across warm reboots, but not after power-cycling the computer.

So in the end I may need to find a way to extract the installer and attempt to actually run the utility on Wine to see if it would work enough to find anything useful, but as I've attempted, under Wine the system simply couldn't find the sound card and would not allow the installation (maybe I need to look for possibilities to install only the utility, without installing the drivers as they won't install nor work).

Currently I'm looking for workarounds, such as 3rd-party volume controllers with headphone (or optionally mic) jacks that connects between the speaker and the sound card, which allows switching speaker and headphone output externally, and does not involve the headphone jack, thus avoiding the problem.

Korth
Level 14
This "3rd-party workaround" might offer the sort of controls you're looking for.

Jack detection is usually embedded into the codec chip hardware, and if so then it might simply control jack ports without any need to communicate to software/driver layers.
ASUS proudly advertises the ESS 9016 DAC, but (according to the User Manual) the actual audio processor appears to be some kind of (CM66x) Cmedia USB2.0 HD Audio part.
The STRIX RAID DLX site, specs, and manual don't seem to explicitly mention jack sensing or jack detection anywhere.

I've never seen the product firsthand, but it appears to me that the "Box Link" is actually a USB2 (UAC2) connection being physically delivered across 3.5mm audio cables, and if so then WINE won't be able to use it unless it can fully emulate the WinOS (USB) driver components.
"All opinions are not equal. Some are a very great deal more robust, sophisticated and well supported in logic and argument than others." - Douglas Adams

[/Korth]

Korth wrote:
This "3rd-party workaround" might offer the sort of controls you're looking for.

Jack detection is usually embedded into the codec chip hardware, and if so then it might simply control jack ports without any need to communicate to software/driver layers.
ASUS proudly advertises the ESS 9016 DAC, but (according to the User Manual) the actual audio processor appears to be some kind of (CM66x) Cmedia USB2.0 HD Audio part.
The STRIX RAID DLX site, specs, and manual don't seem to explicitly mention jack sensing or jack detection anywhere.

I've never seen the product firsthand, but it appears to me that the "Box Link" is actually a USB2 (UAC2) connection being physically delivered across 3.5mm audio cables, and if so then WINE won't be able to use it unless it can fully emulate the WinOS (USB) driver components.


I've already achieved what I wanted using a wired volume controller I've ordered which just arrived. The volume controller has connectors for speakers and microphones (to sound card), plus another connector that goes to the output (speaker). It also provides jacks for headphones with a physical switch that toggles between speaker and headphones, so I can make the switching from there, without plugging the headphone jack on the sound card.

Still, the old control box that came with the sound card isn't going to be anywhere useful on Linux anyway.

And as for the box link being USB2... I think it's not the case. The Box Link merely connects to the HID controller of the CM6632AX audio processor, and is part of it. The USB HID device is always exposed by the audio processor to the system under the same device ID, whether or not the control box is attached.

I could capture streams using usbhid-dump when the control box's attached, and if I detach the control box, the stream stops, and would resume if I re-attach the control box.

Some sound cards I had in the past either does jack detection at driver level (X-Fi Titanium HD), or requires manual toggling (XONAR Essense ST/STX, Sound Blaster ZxR). This card (STRIX RAID DLX) is different from those.

With X-Fi Titanium HD, I can actually switch between speakers and headphones under Linux (with snd-ctxfi), but not under Windows (using Creative's own driver). With XONAR Essence ST/STX, the headphone jacks (front/rear) are separate output options under Linux that could be selected. Sound Blaster ZxR, unfortunately, after this many years since it came out, still couldn't be used under Linux.

It saddens me that many manufacturers don't produce linux drivers for their stuff. Or even publish opensource docs which third party devs could use to code their own drivers/software for linux (or for any other OS). It's always seemed incomprehensibly stupid to me that hardware manufacturers are so utterly paranoid of software piracy - can't let anyone duplicate or improve the software - even though "pirated" drivers could only be used to operate the hardware itself, lol, how is that gonna hurt hardware sales? Seriously, how many people will copy a soundcard at the command prompt or download a GPU card from a torrent site?

I understand the economics, linux has a puny market share vs Windows so it's not "profitable" for the OEM devs to produce or support linux-based code. I even understand the politics and conspiracies, linux is actively (if clandestinely) disparaged by Microsoft and Intel and NVidia, few dare to defy these companies because they've all been vengeful and punitive before.

But it still sucks. Not everyone wants Windows.
"All opinions are not equal. Some are a very great deal more robust, sophisticated and well supported in logic and argument than others." - Douglas Adams

[/Korth]

Korth wrote:
It saddens me that many manufacturers don't produce linux drivers for their stuff. Or even publish opensource docs which third party devs could use to code their own drivers/software for linux (or for any other OS). It's always seemed incomprehensibly stupid to me that hardware manufacturers are so utterly paranoid of software piracy - can't let anyone duplicate or improve the software - even though "pirated" drivers could only be used to operate the hardware itself, lol, how is that gonna hurt hardware sales? Seriously, how many people will copy a soundcard at the command prompt or download a GPU card from a torrent site?

I understand the economics, linux has a puny market share vs Windows so it's not "profitable" for the OEM devs to produce or support linux-based code. I even understand the politics and conspiracies, linux is actively (if clandestinely) disparaged by Microsoft and Intel and NVidia, few dare to defy these companies because they've all been vengeful and punitive before.

But it still sucks. Not everyone wants Windows.


I don't think it's directly related to software piracy. To me it's more like that they can conceal much more information from end users (as well as competitors) on Windows than on other operating systems. Also, given the diversity of Linux kernels and distros, and different points of views among Linux users, providing and maintaining closed, proprietary drivers and software require much more effort than on Windows.

I switched my main computers to Linux mainly because Windows is no longer the simple, fast and responsive OS like it used to be (I'm talking about the good old XP/2003 days), not to mention Windows is still as multiboot-unfriendly as always, and that Windows updates on recent versions are often very bloated, constantly eating up precious disk spaces behind your scenes (I'm talking about the super-huge WinSxS folder, which constantly grows as you install more updates over time, and very difficult to shrink. The magnitude of the problem increases greatly if your system is on a small SSD, like 120GB).

Korth
Level 14
I still don't see any valid reason for an OEM to not publish documentation with sufficient technical detail for non-OEM devs to code a (linux) driver.

Conceal information from end users? No product is ever perfect, and certainly some are better than others, but I do still think it's preferable to let the qualities of a product speak for themselves and encourage opensource than in being secretive, deceptive, and anti-consumer.

Conceal information from competitors? I kinda suspect there's really not so many trade secrets anyhow, a sound card is a sound card, capabilities and specs are based on the hardware components it uses. Anyone with enough knowledge/resources to teardown, analyze, and reverse-engineer a piece of PC hardware already knows all about building this PC hardware anyways ... the only "secrets" left are hidden within firmware or on the production floor (where the same thing gets made but it's somehow made at higher quality, better yield, or lower cost).

Although you do point out that there's a lot of linux diversity, along with different philosophies about package management and legal licenses. The last detail is probably something fearful or distasteful to many OEMs. Although - again - I can't see how it would negatively affect them if software drivers (sometimes better than the stuff they write) was abundantly available and aggressively supported/updated outside their control ... because it still requires people buy OEM hardware to do anything with it.
"All opinions are not equal. Some are a very great deal more robust, sophisticated and well supported in logic and argument than others." - Douglas Adams

[/Korth]