Asus Xonar SE front-panel audio support quirks snd_usb_audio

Asus Xonar SE front-panel audio support quirks snd_usb_audio

[smesgr]

Greetings,

I have bourght a Asus Xonar SE (90YA00T0-M0UA00) which is only working partially. While the rear connectors seems to work the front header is not. I found some reports scattered around the internet with the same issue but without a solution.

It is a PCIe card with an pcie-to-usb interface. Thus the card is reported as a usb device:
ID 0b05:189d ASUSTek Computer, Inc. Xonar SoundCard

The card has several audio Endpoints EP 5 to EP 9 and an additonal HID EP 4. All the rear connectors seems to work. Can't test the SPDIF but found a SE specfic quirk in the alsa USB configuration for the SDPIF PCM thus assume this issue was already fixed.
EP 5 -> Audio Out
EP 6 -> SDPIF
EP 8 -> Line In
The rear connector don't have a plug-in-detector, the front-panel has and is working:
node hw:1, #16 (0,0,0,Headphone - Output Jack,0) VALUE
node hw:1, #31 (0,0,0,Mic - Input Jack,1) VALUE

In stereo configuration the card has "headphones" and "speaker". The Front Panel input nor output is working. If headphones is selected the rear is disabled but the front header is not working. Side note the default Microsoft driver has the same issue so I assume the card usb configuration is faulty.
I installed the ASUS driver and tracked the USB messages with wireshark in a Windows VM. I noticed the Asus driver uses those additional posts
EP 7 -> Front Audio Out
EP 9 -> Front Audio In

Neither the default Windows, nor alsa use those EP. Is there a way to force the alsa driver to use EP7/9 to further analyse this issue?

Best Regards
Smesgr

Sent with ProtonMail Secure Email.

Re: Asus Xonar SE front-panel audio support quirks snd_usb_audio

[Geraldo Nascimento]

Em Qua, 1 de set de 2021 13:24, smesgr <smesgr@protonmail.com> escreveu:

> Greetings,
>
> I have bourght a Asus Xonar SE (90YA00T0-M0UA00) which is only working
> partially. While the rear connectors seems to work the front header is not.
> I found some reports scattered around the internet with the same issue but
> without a solution.
>
> It is a PCIe card with an pcie-to-usb interface. Thus the card is reported
> as a usb device:
> ID 0b05:189d ASUSTek Computer, Inc. Xonar SoundCard
>
> The card has several audio Endpoints EP 5 to EP 9 and an additonal HID EP
> 4. All the rear connectors seems to work. Can't test the SPDIF but found a
> SE specfic quirk in the alsa USB configuration for the SDPIF PCM thus
> assume this issue was already fixed.
> EP 5 -> Audio Out
> EP 6 -> SDPIF
> EP 8 -> Line In
> The rear connector don't have a plug-in-detector, the front-panel has and
> is working:
> node hw:1, #16 (0,0,0,Headphone - Output Jack,0) VALUE
> node hw:1, #31 (0,0,0,Mic - Input Jack,1) VALUE
>
> In stereo configuration the card has "headphones" and "speaker". The Front
> Panel input nor output is working. If headphones is selected the rear is
> disabled but the front header is not working. Side note the default
> Microsoft driver has the same issue so I assume the card usb configuration
> is faulty.
> I installed the ASUS driver and tracked the USB messages with wireshark in
> a Windows VM. I noticed the Asus driver uses those additional posts
> EP 7 -> Front Audio Out
> EP 9 -> Front Audio In
>
> Neither the default Windows, nor alsa use those EP. Is there a way to
> force the alsa driver to use EP7/9 to further analyse this issue?
>
> Best Regards
> Smesgr
>
> Sent with ProtonMail Secure Email.


Hi Smesgr,

In my humble opinion I think there's a high probability this will not be
standard UAC compliant code that can help you much, specially since you
mention the Microsoft driver has the same issue.

In any case it may be just needing a snd-usb-audio "quirk" but I don't
think it would be so easy.

Unfortunately the best chance of making this work is reversing the ASUS
protocol either by capturing USB pass-through to a Windows VM with the
proprietary driver loaded or native Windows USB capture with USBPcap.

Either way you seem to have a sniff already. So the hard part is figuring
out what the alien protocols does, how it does so, and then reimplement C
kernel code for it.

Not the easiest of tasks but hopefully you will get the taste for it.

Good luck,
Geraldo Nascimento