ASUS Xonar Essence One MKII USB DAC issue


I’m trying to use an external USB DAC, which is an Asus Xonar Essence One MKII, as an audio output for Kodi/OSMC on a RPi2. There are two options present in “Audio output device”:


While trying to play a 96 kHz audio file, the first option gives audio output, but the DAC sits constanly at 48 kHz despite that “Output configuration” is set to “Best Match”. The second option gives no sound at all, the playback sits at 0:00, however the DAC correctly switches to 96 kHz. So the question is — how do I make it work properly, that is play sound and switch according to file’s sample rate and bit depth?

Best regards,

I think I found a solution, hope this will help other people:

  1. Create file /etc/asound.conf with the following contents (card and device number may vary):

     pcm.!default {
         type hw
         card 1
         device 0
  2. Choose any of the software upsampling settings (Low/Medium/High), not GPU

  3. Append the following to the first line of /boot/cmdline.txt (source):

     dwc_otg.fiq_enable=1 dwc_otg.fiq_fsm_enable=1 dwc_otg.fiq_fsm_mask=0x3

Point 1 and 2 is to enable sample rates other than 48000. Point 3 is to avoids pops, clicks and white noise issues (has something to do with how USB controller works).

I’m afraid that I called it fixed too soon. While watching videos, the DAC this produces clicks, as if packets were lost. Audio files however play smoothly. Currently I have the following options in cmdline.txt relevant to USB controller mode of operation:

dwc_otg.fiq_enable=1 dwc_otg.fiq_fix_enable=1 dwc_otg.fiq_fsm_enable=1 dwc_otg.fiq_fsm_mask=0x3

Forcing the controller to work in 1.1 mode is unacceptable as it also ruins networking performance, since the NIC is connected via USB as well. Any suggestions on this matter? Thanks in advance.

Have similar issue with my Asus Xonar Echelon. It is pity that the Linux drivers do not provide the customizations we can find on the Asus driver interface for Windows.

I’ll try your solution now. Did u have any updates afterwards?


joaofl, sadly not. I haven’t tested it for quite a while, since I had to hand the DAC in for service. But apparently there haven’t been any major changes to the dwc_otg driver in upstream Linux.

How did you get access to the actual sampling rate? Without the alsa-mixer (since kodi doesnt use alsa), I can not really figure out details of the DAC operation.

Thanks for your answer.

joaofl, the DAC has LEDs on the front panel which indicate the sample rate :slight_smile: Plus if you read the first and second posts again, you’ll see I was configuring ALSA all along.

Ahh ok. Mine does not have such LEDs. Thats true, but why isnt there the alsamixer is not there. But the truth is that I did not really understood the configurations u set, and why.

But from my shallow understanding, it seems to be an issue of communication over the USB. Right?

Anyway, I will dig a bit better, and leave some feedback here if I converge to some solution.

The asound.conf file was edited to point ALSA to the DAC and set it as default. All the dwc_otg boot options are related to the USB controller. And I checked the current sample rate/bit depth through some file in /proc or /sys, can’t remember exactly which one.

It actually did not work. Still get the clicks in my stereo. Specially at the beginning of the song. Not sure it it is related to the RPi accessing the network at the same time, and congesting the USB hub + Ethernet (since my songs are remote in a SFTP server). Or maybe it is an initial match it does… Dont know. Have to figure out.

Problem solved!

Found a simple and clean solution. No glitches anymore, even with the most demanding flac or HD video.

This is, one should add to the end of the line in /boot/cmdline.txt the config smsc95xx.turbo_mode=N only. Have a clean sound now.
From Raspberry Pi and realtime, low-latency audio [Linux-Sound],

It seems that this mode is supposed to increase speed performance of USB and Ethernet, when working together, by reducing the number of packets exchanged between the core and the smsc95, by using some encapsulation, by putting USB together with Eth packets through their USB connection.

Although USB audio requires real-time service, rather then vary fast data-rates. By doing this, one loses real-time capabilities, and get the glitches in the audio, due to real-time deadline misses.