Asus Xonar Essence ST/STX

[cerddwr]

Has anyone been able to get this soundcard to work under Gentoo? According to this article it is possible but I have had no luck. It works as expected on Windows xp so it is in working order. The card has the AV100 chipset and is said to work with the "virtuoso" module but my system does not detect it:

Code: Select all

lsmod | grep -i "snd"
snd_seq_oss            23408  0 
snd_seq_midi_event      6296  1 snd_seq_oss
snd_seq                42916  4 snd_seq_oss,snd_seq_midi_event
snd_pcm_oss            30788  0 
snd_mixer_oss          13440  1 snd_pcm_oss
snd_virtuoso           11116  0 
snd_oxygen_lib         27584  1 snd_virtuoso
snd_pcm                59516  2 snd_pcm_oss,snd_oxygen_lib
snd_timer              18120  2 snd_seq,snd_pcm
snd_page_alloc          8152  1 snd_pcm
snd_mpu401_uart         6104  1 snd_oxygen_lib
snd_rawmidi            18960  1 snd_mpu401_uart
snd_seq_device          6340  3 snd_seq_oss,snd_seq,snd_rawmidi
snd                    49896  11 snd_seq_oss,snd_seq,snd_pcm_oss,snd_mixer_oss,snd_virtuoso,snd_oxygen_lib,snd_pcm,snd_timer,snd_mpu401_uart,snd_rawmidi,snd_seq_device

lspci | grep -i "audio"
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
01:00.1 Audio device: ATI Technologies Inc RV620 Audio device [Radeon HD 34xx Series]
04:00.0 Multimedia audio controller: C-Media Electronics Inc CMI8788 [Oxygen HD Audio]

The kernel is a genkernel. The module snd_hda_intel is currently blacklisted as this is the one to drive the motherboard's sound facility, which I do not want. It seems to make no difference whether or not this module is loaded. The commands

cat /proc/info/asound/cards
and
aplay -l
both say "no soundcards detected".

Code: Select all

emerge --info
Portage 2.1.6.13 (default/linux/x86/10.0, gcc-4.3.2, glibc-2.9_p20081201-r2, 2.6.30-gentoo-r6 i686)
=================================================================
System uname: Linux-2.6.30-gentoo-r6-i686-Pentium-R-_Dual-Core_CPU_E5200_@_2.50GHz-with-gentoo-1.12.11.1
Timestamp of tree: Sun, 01 Nov 2009 17:45:01 +0000
app-shells/bash:     3.2_p39
dev-lang/python:     2.6.2-r1
sys-apps/baselayout: 1.12.11.1
sys-apps/sandbox:    1.6-r2
sys-devel/autoconf:  2.13, 2.63-r1
sys-devel/automake:  1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2
sys-devel/binutils:  2.18-r3
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.6a
virtual/os-headers:  2.6.27-r2
ACCEPT_KEYWORDS="x86"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=i686 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d"
CXXFLAGS="-O2 -march=i686 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="http://mirror.bytemark.co.uk/gentoo/ ftp://mirror.bytemark.co.uk/gentoo/ http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/ ftp://ftp.mirrorservice.org/sites/www.ibiblio.org/gentoo/ http://mirror.qubenet.net/mirror/gentoo/ ftp://mirror.qubenet.net/mirror/gentoo/ http://gentoo.virginmedia.com/ ftp://gentoo.virginmedia.com/sites/gentoo "
LDFLAGS="-Wl,-O1"
LINGUAS="en_GB"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="X a52 aac acl acpi alsa berkdb bzip2 cdparanoia cle266 cli cracklib crypt cups dbus dri dvd dvdr dvdread dxr3 encode firefox flac fortran gdbm gimp gimpprint gpm gtk hal iconv ieee1394 ipv6 jpeg kde kdeenablefinal ldap lm_sensors mad modules mp3 mplayer mudflap ncurses nfs nls nptl nptlonly nsplugin openmp oss pam pcre perl png ppds pppd python qt3 qt4 readline reflection samba session spl ssl sysfs tcpd unicode userlocales v4l x86 xorg xscreensaver zlib" ALSA_CARDS="virtuoso" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CAMERAS="canon" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_GB" USERLAND="GNU" VIDEO_CARDS="fglrx radeon radeonhd vesa"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY 

My first thought is that my ALSA_CARD setting may be wrong, but what to use? Oxygen? It's not an Oxygen card AFAIK. The ALSA support guide gives instructions for using "Alsa-driver" but I hope to avoid this. (Isn't it deprecated?)

[whig]

I've got a Xonar DX, appearing as yours.

Code: Select all

# lspci | grep -i audio
04:04.0 Multimedia audio controller: C-Media Electronics Inc CMI8788 [Oxygen HD Audio]

Run lspci -k for module info. Boot a live cd - systemrescuecd, ubuntu. See if they find it.

[E001754]

I'm very interrested in buying this card in the near future.
I've read so far that this card is using an Oxygen chipset and therefore the oxygen module found in the latest 2.6.30 kernels (alsa-1.0.20).

see alsa project for more informations :
http://www.alsa-project.org/main/index. ... e-virtuoso

but, please, post the results back, as I want to know if it really works before spending 180 bucks for this card !

cheers

EDIT : sorry, I didn't see that you already gave the link to alsa-project help guide.

As I understood, you can use alsa driver either directly compiled from the kernel, or, if you don't have a recent enough kernel, you can use the *deprecated* package "alsa-drivers", which allows you to install recent alsa driver without the need of upgrading your kernel. However, this "alsa-driver" package is deprecated, as no-one really knows a case in which you couldn't upgrade your kernel to get the wanted alsa driver version.

[cerddwr]

I have just tried a Suse live distro but it could not configure the Xonar Essence. However it only has a 2.6.27 kernel. I will look for a recent live distro with a 2.6.31 kernel and see if that will work. If not I shall have to try the alsadriver method.

[E001754]

I have bought the Xonar Essence STX.
I'll get the delivery within the next days and keep in touch here to say if it works or not.

cheers.

[cerddwr]

I have downloaded the latest systemrescue cd with the 2.6.31 kernel and tried that. No joy - in fact the disc does not seem to have any sound modules at all!

Code: Select all

lspci -v | grep -i "audio" 

gives the same output as the 2.6.30 kernel in my Gentoo setup.

Code: Select all

lsmod | grep -i "snd" 

gives no response.

Code: Select all

modprobe virtuoso
module virtuoso not found

lspci -k shows no modules for the sound card.
Over to alsadriver! I will post my findings.

[E001754]

what card do you have EXACTLY ?
Is it the Essence ST or the STX ? (i.e. PCI bus or PCI Express 1x ?).

The ST (PCI) is supported only since the 1.0.22 alsa version (kernel 2.6.33) as the STX (PCI Express) is supported since the 1.0.20, kernel 2.6.30.

I first thought it should be the same, but one told me on the phoronix forum that the PCI and PCI Express don't manage latencies the same way. Therefore, two separate drivers are needed, it's not only a matter of hardware id/vendor id to add in the STX driver for making work the ST version.

I have bought the STX version (i'd rather get a PCI Express card, as it's more future proof than the aging PCI).

[cerddwr]

My card is the ST (PCI). I have just tried removing Alsa from the kernel and installing the alsa-driver in portage (1.0.21). I get exactly the same results as with the kernel-driver and alsaconf closes with the same error message "unable to load required modules".

It surprises me that the PCI and PCI-e versions react differently as their specifications are identical apart from the interface. But it must be so, and thank you for your explanation. I shall have to wait for alsa-driver 1.0.22, which may not be long, or Kernel-2.6.33, which may be quite a long time yet. Meanwhile I shall have to make do with winxp.

Best of luck with configuring your STX (PCI-e)

[whig]

On the alsa page, http://www.alsa-project.org/main/index. ... endor-Asus

Xonar Essence ST AV100 Details [PCI] [ANALOGio] [RCAo] [TOSo] [24bit] [192kHz] ALSA 1.0.22 or kernel 2.6.33
Xonar Essence ST with H6 daughterboard AV100 Details [PCI] [ANALOGio] [RCAo] [TOSo] [24bit] [192kHz] [7.1] ALSA 1.0.22 or kernel 2.6.33

[E001754]

The Xonar Essence STX works great with the following modules loaded :

luc@localhost ~ $ lsmod | grep snd
snd_seq_oss 28096 0
snd_seq_midi_event 7904 1 snd_seq_oss
snd_seq 52288 4 snd_seq_oss,snd_seq_midi_event
snd_pcm_oss 35696 0
snd_mixer_oss 15264 1 snd_pcm_oss
snd_virtuoso 14052 5
snd_oxygen_lib 33600 1 snd_virtuoso
snd_pcm 73224 3 snd_pcm_oss,snd_oxygen_lib
snd_timer 22416 3 snd_seq,snd_pcm
snd_page_alloc 10000 1 snd_pcm
snd_mpu401_uart 7776 1 snd_oxygen_lib
snd_rawmidi 23520 1 snd_mpu401_uart
snd_seq_device 7860 3 snd_seq_oss,snd_seq,snd_rawmidi
snd 59224 19 snd_seq_oss,snd_seq,snd_pcm_oss,snd_mixer_oss,snd_virtuoso,snd_oxygen_lib,snd_pcm,snd_timer,snd_mpu401_uart,snd_rawmidi,snd_seq_device

I just removed all the hda_intel related modules, to replace by "snd-virtuoso" in /etc/modules.autoload.d/kernel-2.6 (after a kernel recompilation to get this module).
And that's all !

Hope this will work for you just as smooth as it worked for me.

cheers

[Chainsaw]

Has anyone been able to get this soundcard to work under Gentoo?

Sure, upgrade to a 2.6.32-rc6 kernel. Recent hardware requires a recent kernel...

[isolationism]

The ST (PCI) is supported only since the 1.0.22 alsa version (kernel 2.6.33) as the STX (PCI Express) is supported since the 1.0.20, kernel 2.6.30.

Shit. Thank you, E001754; without this info I'd probably still be beating my head into the desk trying to make my card work; should have checked the forums sooner -- they always come through.

My own experience, for what it's worth:

I just brought home the ST (e.g. PCI) version of this card as the STX is no longer available from any distributors in my area, it seems -- my guess is Asus may be phasing that model out in favour of the ST version instead, but who knows; I visited the Canadian Asus site a couple days ago and it didn't even acknowledge that the ST existed.

I was running gentoo-2.6.30-r5 when I installed the card. It showed up fine under LSPCI but Alsa wouldn't detect it despite having compiled the kernel driver as a module.

I then upgraded to gentoo2.6.31-r6 and lo and behold, alsa detects the card. I can even hear a physical switch click (and a corresponding speaker/headphone pop) when I change the output channel -- but no matter what I tried, I could not get any kind of audible output from either the headphone (1/4") or speaker (RCA) outputs. I made sure the power lead to the board was securely connected and worked; when I tried intentionally disconnecting the lead I no longer heard the switching sound from the card, so the power probably isn't it. Yes, I checked that all the channels were unmuted in alsamixer a few dozen times ...

Thankfully, what does still work is the SPDIF out (I'm using coaxial)-- so thankfully it's not completely useless to me as I can still decode the digital stream using my desktop DAC. Guess I'm going to be waiting patiently for 2.6.33 and/or alsa-driver 1.0.22 before being able to check out the internal DAC, though.

Edit: It's all here in black and white; one of these days I'll learn how to read.

[cerddwr]

Yes, Isolationism, that was more or less what I found as well with the 2.6.32 vanilla kernel. I have no external DAC so I don't know if that output works. The line input does work and audacity detects the signal and can record it. But there is no sound output from the RCA phono sockets.

I note that vanilla-sources-2.6.33-rc2 is now in portage, so I will have a go with that when I have time, (maybe next week).

[E001754]

Shit. Thank you, E001754;

You're very welcome.
Glad this topic has been usefull to others.


P.S : Happy new year !

[isolationism]

I actually had to stop using the SPDIF out not long after my post becuase I ran into a problem where it just went dead mid-use and I couldn't get it going again until after a reboot. It may have to do with me wanting to use OSS for everything as ALSA has an annoying habit of upsampling everything to 48KHz instead of just sending the data at its original bitrate (not sure what to do about that one; PulseAudio seems like an option but I don't see how it would work without resampling either). So I switched to using USB output direct to the DAC.

However, I left a new pair of headphones burning in overnight and went to test the on-board SPDIF out this morning and it's still working -- so I dunno what's going on. I'm going to keep using it for a bit and see what happens.

Edit: And happy new year to you all, too!

Edit2: SPDIF output worked fine for about 5 hours of on-and-off listening today -- then suddenly went dead again while I was changing to a new song while another was in mid-playback. I restarted MPD but to no avail; the DAC no longer registers that any signal is reaching it despite that any audio player still happily continues to play. This is *incredibly* frustrating.

[isolationism]

Definitely still having SPDIF problems. I've checked other threads in this forum (as well as a serious amount of Googling) but none sounds like the problem I am experiencing -- or at least, no solutions/suggestions were forthcoming if they did.

It seems like it's almost certainly a device contention issue; the sound doesn't cut out on me while in the middle of a song or movie, and it always seems to work after a clean boot even after the computer's been on for a while. Logging out then logging back in again doesn't fix it, but a soft reboot always restores SPDIF sound output. In my case, there are two clear indicators as to whether SPDIF output is working or not: First, there is the obvious audio output (or lack of), and second is an indicator light on the front of the device that indicates the incoming signal bitrate, supporting 32, 44.1, 48, 88.2, and 96 Kbit/sec.; obviously while playing nearly all CD-ripped music the 44.1 Kbit/sec lights up; 48 Kbit/sec is always lit whenever sound is playing from ALSA (regardless of the source bitrate), and of course a few 24/88 and 24/96 FLAC files I have will light up the appropriate lights. When the SPDIF output fails, none of the lights illuminate even though the player software continues oblivious (e.g. it does not warn me that the device is already in use).

Another point worth making is that I have two audio devices installed: /dev/dsp1 is the Xonar ST; /dev/dsp is a USB output to the DAC. I have the USB output set as the preferred audio output device so that system sounds etc. are played to the USB device to avoid anything else contending for access to the Xonar ST. The problem occurs whether or not the USB device is connected, but I leave it on mainly so that when the Xonar does cut out I can just switch over to USB audio out and still have audio without having to reboot immediately.

As I already mentioned, I have ALSA installed but I'm using "OSS" output so that everything plays at its native bitrate instead of ALSA's annoying habit of upsampling everything to 48KHz. SPDIF output always cuts out while in some state of transition or other. Examples experienced in the past 24 hours:

• While "jogging" through a song playing via MPD
• While playing tracks normally with MPD; the end of tracks were somehow being snipped off and after 2-3 tracks ended this way, the audio was dead by the time the next one started
• While "jogging" through a movie playing via mplayer

Some of the other posts in this forum describe problems like SPDIF dying mid-film while using mplayer (but output continues to work fine elsewhere); another was about a few different ways SPDIF would go and not come back properly for several reboots, or without removing and re-adding alsa-related software and/or deleting alsa settings files. SPDIF output stared working for me the moment I switched to 2.6.31 without having to fiddle around, so that's not it.

A number of other posts, bug reports, etc. suggest that playing a digital stream (e.g. dolby 5.1 encoded) from a movie could trip some kind of data-output mode in the IEC958 output, but that is unlikely to be the case here as it fails while playing plain old stereo music. All the same, I tried using 'iecset audio off / iecset audio on' to toggle between audio/data modes but this had no effect; the output remains in 'audio' mode when the error occurs.

Anyone have any thoughts as to what might be going on, or other stuff to try that hasn't been mentioned yet? Any suggestions at all would be warmly appreciated.

[isolationism]

Happy New Year everyone!

I was very lucky today in that my wife still managed (despite the hangover) to take my son out of the house for a few hours this afternoon so I could have some peace and quiet. Following cerddwr's suggestion, I installed kernel-2.6.33-vanilla-rc2. Below are my findings.

First and foremost, kernel 2.6.33 does indeed support the Xonar Essence ST (PCI) as promised!

After booting to the command prompt I immediately called up alsamixer and greeted a very welcome sight indeed -- there were three new options that were not previously present which will make a lot of card purchasers very happy:

• The inclusion of "Headphone Impedence" selection; options were "<64 ohm", "64-300 ohm", and "300-600 ohm". This is a really big deal for people like me who own high-impedence cans like the AKG 240s, who have typically had to buy specialized headphone amplifiers to be able to drive them to a reasonable listening volume;
• A new "DAC Filter" switch to toggle between "sharp roll-off" and "slow roll-off"; and
• A new "DAC oversampling" toggle between "64x" and "128x" settings

All of the features appear to work as advertised; higher headphone impedance boosted the volume accordingly (adjust with caution!); the DAC Filter setting produced a small audible "click" in the audio output when switched and produced a slightly warmer sound in "smooth" vs "sharp" roll-off mode, and DAC Oversampling produced a click when switching between the two modes although admittedly I could not hear any noticeable difference between the two in the limited material I played.

Next came some listening. First, through a pair of UltraSone PRO 750's, then through a pair of AudioEngine A5's.

I won't give you a full review because not only do I lack the words, but I'm also far from being a self-proclaimed golden-ear. However, it should suffice to say that the audio output is VERY clean -- even with the output at 90% there was ZERO hiss from my cans, as if they were completely unplugged (as opposed to an appreciable hiss when coming through my Graham Slee Solo desktop headphone amp via my external DAC); it's now even more fiercely evident when the hiss I hear is coming from the engineer's recording gear as opposed to my own setup. Bass was quite taut but rounder/fuller than I'm used to hearing. Lower-bitrate (e.g. 128kbit) mp3s didn't suffer from as much audible flanging in the high-end as I'm used to hearing from the DAC. Stereo separation and positioning was definitely superior to my DAC + Solo arrangement as well, noticeably better even on only mediochre audio-engineered tracks.

I noticed less difference with the speakers, but that is understandable since they have to compete with my chassis fans and they're really entry-level gear. I suspect most people with this card are probably there for the headphone amp, anyway -- I certainly do most of my listening with cans for privacy and to block out more outside sound (which is why I hardly ever use my Grado SR325s anymore, as they're not particularly good at doing either, although they do sound nice).

As with most new, unbroken audio gear, I expected the highs to be a bit brash but was surprised to find that wasn't the case. I didn't listen to any particularly high-pitched music/sounds to test this more thoroughly, but I'm guessing that the amp has been powered up all this time the computer's been on and helped to start breaking things in a bit -- certainly the PCI card was quite warm after just a few minutes of the machine being powered on even when it wasn't making any sound (I didn't touch directly, but could feel the radiant heat -- no idea how hot the card actually gets; hopefully that won't be a problem a year or two down the road).

The not-so-great-news:

First, I was still able to hose the SPDIF output pretty quickly by loading a song in mplayer then continuously jogging it back and forth for maybe 15-20 seconds -- same symptoms as above. The analogue outputs were completely unaffected and continued to work fine. I can only guess that this means SPDIF output itself is buggy/problematic and likely has little to do with the card itself or the card-specific drivers.

Second, I was (not surprisingly) unable to compile kernel-modules required to support my video card and virtual machine host tools against 2.6.33-rc2, so it's not really a usable configuration for me, yet. It's going to be a long several-months' wait until Gentoo has official kernel support for 2.6.33 as even 2.6.22 isn't marked stable yet. If anyone can think of something stupid I'm forgetting to do here please point it out to me; I'd be willing to give using 2.6.33-rc2 a shake for a while on weekends or something if I could at least have a GUI running.

[isolationism]

Well, maybe you all already knew this and I'm the last horse to cross the line -- but I am at this very moment listening to the headphone output from my Xonar Essence ST under 2.6.31-r6 with full support for all the ST/STX features in the mixer.

The solution, it turns out, is embarrassingly simple, and took all of 60 seconds to implement (although admittedly a little longer to compile). The short version is that the 2.6.33 oxygen module is a drop-in replacement for older kernels. Some more complete instructions follow:

• Download a release candidate of 2.6.33 (the more recent the better, probably; I used r4)
• Enter the directory for your current 2.6.30+ kernel
• Move sound/pci/oxygen out of the way (e.g. mv sound/pci/oxygen sound/pci/.oxygen-old)
• Copy the new 'oxygen' directory into the current directory (e.g. cp -Ru /usr/src/linux-2.6.33-rc*/sound/pci/oxygen ./sound/pci/oxygen)
• Make sure "CONFIG_SND_VIRTUOSO" is set to compile as a module (e.g. echo "CONFIG_SND_VIRTUOSO=m" >> .config)
• Make and install the new kernel module.
• Reboot your computer.

After a reboot, I now have full control over the Xonar ST and analogue outputs work. No more waiting 'til March! Woohoo!

A screenshot of the happy event: http://img109.imageshack.us/img109/2992/xonarst.png

[E001754]

Hey, it seems that the ST driver offers the choice of headphone impedance...

I wish I could choose that also on my STX release of driver.
Or maybe has it been implemented over newer kernel releases and that I should migrate as soon as possible (currently on 2.6.30)

[isolationism]

Or maybe has it been implemented over newer kernel releases and that I should migrate as soon as possible (currently on 2.6.30)

E001754, pretty sure it is a result of the new support in 2.6.33, as is (presumably?) the oversampling selection as well ... There are a few actual "xonar" driver now in the oxygen folder that weren't there before.

If you have a little free time why not try it out? It doesn't take long; you don't even need to install a new kernel. Only crummy part is you will need to reboot to load the new kernel module, but I originally compiled it using 2.6.30 (albeit without rebooting) and it did compile file, so I imagine it will probably work.

[darklegion]

It may have to do with me wanting to use OSS for everything as ALSA has an annoying habit of upsampling everything to 48KHz instead of just sending the data at its original bitrate (not sure what to do about that one; PulseAudio seems like an option but I don't see how it would work without resampling either). So I switched to using USB output direct to the DAC.
(

Old post but I just thought I'd note that you have to disable dmix if you want to prevent resampling. You'll lose software mixing of course, but it works. Alternatively you can tell alsa to mix down to 44khz, which may affect sound quality of movies but won't affect music (as it's 44khz). Additionally, you can tell alsa to use libsamplerate resamplers, which don't have the sound issues that the default resampler has.

Here's an example:

Code: Select all

pcm.!default {
type plug
slave.pcm {
type dmix
ipc_key 1024
slave {
pcm "hw"
rate 44100
}
}
}

#defaults.pcm.rate_converter "samplerate_best" 
defaults.pcm.rate_converter "samplerate_medium"

Use samplerate_best for best sound quality, or samplerate_fastest if you have a very weak cpu. samplerate_medium sounds fine to me, so I stick with that.



To go back on topic, what's the support like for these cards now (and the DX) ? Are there still any teething problems, or is it pretty much plug and play these days?

[isolationism]

Using OSS "emulation" over Alsa does the trick 100% of the time, darklegion -- it just has the same device contention problem with other applications not being able to play sounds when the card is already in use, e.g. playing music -- which is perfectly fine with me; I still get a visual notification (saying that the card is busy) and it doesn't interrupt my music.

As for device support, 2.6.33 is out -- but hasn't been marked stable for any architecture yet in the portage tree. So it's not exactly plug and play yet, no. Your options remain to either accept the unstable version (probably not very wise for the kernel), or just do as I did and copy the folder out of 2.6.33 and into your current 2.6.31 kernel and rebuild, then it "just works".

... Or just wait another few months, I guess -- but I'm an impatient sort of guy when I've got the hardware sitting there doing nothing. I've been enjoying the sweet audio quality for months now without a single problem.

[darklegion]

I'm using the zen-stable kernel, so I'm already on 2.6.33. I ended up ordering the STX before seeing your reply, but it seems like it's all good

[Sadako]

As for device support, 2.6.33 is out -- but hasn't been marked stable for any architecture yet in the portage tree. So it's not exactly plug and play yet, no. Your options remain to either accept the unstable version (probably not very wise for the kernel), or just do as I did and copy the folder out of 2.6.33 and into your current 2.6.31 kernel and rebuild, then it "just works".

... Or just wait another few months, I guess -- but I'm an impatient sort of guy when I've got the hardware sitting there doing nothing. I've been enjoying the sweet audio quality for months now without a single problem.

I'm happily using 2.6.33, for other reasons as well as the ST drivers, but you can easily use the alsa-drivers package rather than the in-kernel drivers with older kernels, it may not be the supported or recommended way, but it works.

As for disabling dmix, I went one step further; ALSA_PCM_PLUGINS='' in make.conf.

Makes sure alsa never gets to do anything funky, you just need to tell most apps to use the right device (ao=alsa:device=hw for mplayer, device "hw:0" for mpd), in both those cases the apps themselves will resample anything below 32kHz, but anything below that will sound like crap anyways (flash video).
A disadvantage of this is only one app being able to use the card at a time, but I actually prefer it like that.

I know I probably wouldn't notice much if any difference with a xonar card one third the price of this one, but still, I love this thing.

[isolationism]

I know this thread is somewhat stale now, but for those that purchased the card in the hopes of high-quality audio, I wanted to add a little post for posterity to note that I finally figured out how to get audio outputting properly at its native sample frequency and bitrate.

In short, I have been outputting audio for the past six months using an "oss" driver, which is in fact Alsa's OSS emulation feature in the Kernel.

The result of this choice, I realized only earlier today, is that the file's playback frequency is respected (e.g. normally anywhere from 44.1KHz to 192KHz) but the bitrate is not. I've been playing back 24-bit FLAC files all this time without realizing that the oss emulation feature is downsampling to 16-bit! The following snippet is the relevant two lines from mplayer:

Code: Select all

AUDIO: 192000 Hz, 2 ch, s32le, 4689.6 kbit/38.16% (ratio: 586195->1536000)
=== snip ===
AO: [oss] 192000Hz 2ch s16le (2 bytes per sample)

Note the audio file shows as Signed 32-bit little endian, but playback itself is signed 16 bit little endian. Doh!

Next, I went back to -ao alsa with my tail tucked between my legs. I had been avoiding ALSA all this time because it annoyingly resamples everything to 48000KHz to avoid device contention when multiple applications try to play back audio simultaneously. This is convenient and indeed useful for convenience's sake, but I would rather have my music play back at its original quality levels, thanks, and I prefer applications not interrupt my music.

Code: Select all

AUDIO: 192000 Hz, 2 ch, s32le, 4689.6 kbit/38.16% (ratio: 586195->1536000)
=== snip ===
AO: [alsa] 48000Hz 2ch s32le (4 bytes per sample)

Interestingly, the position is reversed from oss emulation; now the bitrate is being preserved but the sample rate is being forced to 48000Hz, which seems to be the common upper-limit for most hardware these days, presumably so DVDs can be played back without resampling.

Well, the solution turned out to be astonishingly straightforward once I realized that -- by default -- Alsa output goes to a software mixer like dmix, which is what takes care of resampling. This is happily easy to circumvent with software that allows you to specify the audio device explicitly -- which, happily, both mplayer and mpd can do. Using the following string for mplayer did the trick:

Code: Select all

$ mplayer -ao alsa:device=hw=0.0 test192.flac

AUDIO: 192000 Hz, 2 ch, s32le, 4689.6 kbit/38.16% (ratio: 586195->1536000)
=== snip ===
AO: [alsa] 192000Hz 2ch s32le (4 bytes per sample)

Brilliant! I have since set up that ao option in my ~/.mplayer/config. Setting MPD is also similarly easy:

Code: Select all

audio_output {
    type        "alsa"
    name        "Alsa Output"
    device      "hw:0,0" # Bypass audio mixer
}

And of course /etc/init.d/mpd restart, and you're done. Hope this helps someone else out!