S/PDIF digital output with the AV710 on Linux - guide
Jan 13, 2006 at 2:26 AM Thread Starter Post #1 of 14

AdamWill

Headphoneus Supremus
Joined
Dec 28, 2004
Posts
1,643
Likes
28
We have a thread with a quick guide to using the AV710's analog output under Linux, but not its digital output. I aim to fill that gap! The AV710 is a good choice for a digital output as well as analog, since it's cheap and has a non-resampling optical output. Under Linux, here's how to use it. This should work since about ALSA 1.0.9, I'm not so sure about earlier versions.

0. Make sure your system is configured to use snd-ice1724 as the sound driver. This is outside the scope of this guide but should be the case on most distros. You can check with, as root, "lsmod | grep snd-ice1724".
1. Download the first attachment to this post and save it as /etc/asound.state .
2. Download the second attachment to this post and save it as ~/.asoundrc (that is, filename .asoundrc in your user's home directory).
3. Run this command as root:

alsactl restore

That's basically it. Play sounds and they go out over the optical output. There is an optional step, if you're running a recent distro. Edit /usr/share/alsa/cards/ICE1724.conf and, if it has a section like this at the top:

default with dmix & dsnoop
ICE1724.pcm.default {
@args [ CARD ]
@args.CARD {
type string
}
type asym
playback.pcm {
type plug
slave.pcm {
@func concat
strings [ "dmix:" $CARD ",FORMAT=S32_LE" ]
}
}
capture.pcm {
type plug
slave.pcm {
@func concat
strings [ "dsnoop:" $CARD ",FORMAT=S32_LE" ]
}
}
}

then consider deleting it, or commenting it out. This section enables dmix and dsnoop. These mix (respectively) playback and recording streams so you can play several sounds at once. The problem is they force resampling to a single sample rate, for dmix the default is 48KHz. I'd rather play one sound at a time and avoid any manipulation of the audio, so for this reason, I remove this section. (It's a very recent addition to ALSA, so if your distro isn't brand new, it may well not be there anyway). Enjoy!
 
Jan 21, 2006 at 4:53 AM Post #2 of 14
Thank you! I wasted a ton of time trying to get this to work, and then finally I stumbled upon your guide. It really helped!

A couple of questions:

1) I see that in the asound.state file you provide, you have unmuted and raised the volume levels for many different channels. Is there a reason for this? I only use the SPDIF out on this card, and I was under the impression that you only needed "Master" and "PCM" unmuted for it to work.

2) While I was trying to get this thing to work, I was totally disregarding the .asoundrc file, and using commands like aplay -D hw:1,1 test.wav (I have two sound cards, in case you're wondering why I used hw:1,1), which never worked. What exactly is going on in the .asoundrc file? Specifically, I'm interested in the format S32_LE line... that's probably what was holding me up, so I'd like to know what's going on there.

Again, thanks for this!
 
Jan 21, 2006 at 10:28 PM Post #3 of 14
Well, I'm going to have to let you down by pleading "not a clue" to both questions
smily_headphones1.gif
. I took both files from other sources. I modified the .asoundrc substantially - the original used dmix, which I took out as it forces resampling which is bad for quality - but left the mixer settings as-is. They don't appear to hurt anything, so I left them. I think PCM is the only one which really affects anything when doing digital out (try changing Master while you're playing music, nothing will change), but I'm not 100% sure. I did have the same experience as you, though - without an asoundrc like this, it doesn't work, so I agree it's the S32_LE bit that's vital (the rest of the .asoundrc simply tells it to send everything to device 0,1 - the digital output - by default). I don't know what it means, though.

There's a couple of things I forgot to mention, BTW: I find you need apps that do native ALSA output - OSS output won't work - and I had problems using apps based on gstreamer 0.8 with this config, they would skip heavily. gstreamer 0.10 is fine, so I have simply found patches to build all the gstreamer-based apps I use against 0.10 instead of 0.8.
 
Jan 22, 2006 at 8:15 AM Post #4 of 14
Quote:

Originally Posted by AdamWill
...without an asoundrc like this, it doesn't work, so I agree it's the S32_LE bit that's vital (the rest of the .asoundrc simply tells it to send everything to device 0,1 - the digital output - by default). I don't know what it means, though.


Well, I played around with it a bit, and here's what I found out. As far as your /etc/asound.state file goes (the file that is automatically edited when you run alsamixer), you only need the "Master", "PCM", and "IEC958 Output" channels unmuted... everything else can be muted. Additionally, "IEC958" and "IEC958 1" should both be set to "PCM Out", and the "Multi Track Internal Clock" should be set to "44100". All of these options are set correctly in the example asound.state file that you posted; I just thought I'd clarify the pertinent ones.

Furthermore, the "format S32_LE" line in the ~/.asoundrc file is actually not required. It seems that all that is required is a valid "slave" plugin entry. My SPDIF out works with only the following in my .asoundrc (and remember, I'm using "hw:1,1" only because my AV710 is the second sound card in my system):

Code:

Code:
[left]pcm.!spdif { type plug slave { pcm "hw:1,1" } }[/left]

I then use the device name of "spdif" when I want to play PCM audio through my AV710's SPDIF out with ALSA (for example, I'd run "aplay -D spdif file.wav").

Additionally, this can also be represented as:

Code:

Code:
[left]pcm_slave.blah { pcm "hw:1,1" } pcm.!spdif { type plug slave blah }[/left]

What this all means, I am not really sure. If you look here [alsa-project-org] you'll see a listing of various ALSA PCM plugins, and it seems that the "slave" plugin is meant for resampling/changing audio "formats", but it seems as if in our case, all it is doing is simply routing PCM audio to the proper hardware channel. I experimented with the "hw" plugin with no success.

A couple of thoughts about this. The files that I am playing through this card are 16-bit, 44100 Hz audio (ripped from CD). I think the real key element is properly passing 44100 Hz PCM audio to the SPDIF out; that would correspond with the "44100" value for the "Multi Track Internal Clock" option in alsamixer. I'm still unsure of what the "S32_LE" format is, but it seems to indicate 32-bit floating point? I'm not sure what happens when you pass true 16-bit audio to this 32-bit "format", but perhaps it is dithered...

Anyway, I know that when I want to play PCM audio through the SPDIF out of this card with kernel streaming in foobar2000 under Windows (i.e. bypass the Windows software mixer, or the equivalent of the ALSA mixer in Linux), I need to make sure resampling is disabled (i.e. the output sample rate is 44100), and that 16-bit fixed-point is used. In Linux, I would assume this to be the same deal, although the ALSA mixer seems to be required in the middle. Maybe the "slave" plugin is passing the correct audio regardless of what is explicitly stated in the .asoundrc file? You could just as easily include the lines "format S32_LE" and "rate 44100" in the file, but they don't seem to be required...

But I'm rambling. I wish someone with more knowledge of this would take a look and tell us what is going on. But on the bright side, it works, so I should just shut up
wink.gif
 
Jan 22, 2006 at 10:07 AM Post #5 of 14
As long as you don't have rate locking on (i.e. unmuted - I think it's the very last mixer control), the rate will be automatically changed to match whatever you're playing. Try it - set it to 22050 or something then play some music. It'll sound fine, and if you go back into the mixer, you'll see it's back at 44100. That's my experience, anyway. Thanks for your experiments, maybe I'll take the S32_LE line out of my file on the theory that simple is best...
 
Jan 22, 2006 at 3:02 PM Post #6 of 14
Quote:

Originally Posted by AdamWill
As long as you don't have rate locking on (i.e. unmuted - I think it's the very last mixer control), the rate will be automatically changed to match whatever you're playing. Try it - set it to 22050 or something then play some music. It'll sound fine, and if you go back into the mixer, you'll see it's back at 44100. That's my experience, anyway.


Yes, I've noticed this too, but I'm unsure if that behavior is by design. If you read the first user post towards the bottom of this page, it seems that there is/was a bug in the ice1724 driver, whereby the clock rate gets "stuck" on a given value and doesn't stay changed if you try to change it. This post is dated in 2003, however, so I'm not sure if this bug was fixed since then (a developer posted a patch at one time, so it was addressed, but I don't know if this patch made it into the ice1724 driver).

Anyway, I'm probably getting hung up on nothing. As far as I can tell, with these settings, we can properly pass 16-bit 44100 Hz PCM audio through the SPDIF out to an external DAC, which is all I wanted to be able to do in the first place.
 
Feb 15, 2006 at 5:24 AM Post #8 of 14
Quote:

Originally Posted by fathom
AdamWill: Thanks so much for posting this. It made the installation completely trouble-free.


seconded. i just got my AV710 today and was going nowhere until i found this thread.
 
Feb 16, 2006 at 3:09 AM Post #9 of 14
No problems, happy it's working for you guys, and thanks to GetCool for helping me refine it
smily_headphones1.gif
 
Feb 21, 2006 at 4:46 AM Post #10 of 14
Absolutely wonderful guide. Thanks for piecing together all the clues. My Linux box has never sounded better!
rs1smile.gif


edit: I was also wondering if the asound.state file you attached will ever be updated per alsa's development.
 
Feb 22, 2006 at 2:36 AM Post #11 of 14
Can't say for sure. The ALSA devs appear to regard rearranging mixer channels with no warning and for no good reason as excellent sport, so it's entirely possible. If I ever update ALSA and find I have to change stuff to make it work, I will come back and update this thread. It didn't change from 1.0.9 to 1.0.10, though, which is a good sign.
smily_headphones1.gif
 
May 22, 2006 at 10:07 PM Post #12 of 14
Quote:

Originally Posted by GetCool
Furthermore, the "format S32_LE" line in the ~/.asoundrc file is actually not required.


This is from the ALSA wiki, the documentation for the ice1724 driver:
Sample rates no longer need to be specified since everything from 8 - 44 kHz is enabled by changes to ALSA 1.0.10. The S32_LE format has apparently been made the default for non-dmix type outputs, and no longer needs to be specified.

http://alsa.opensrc.org/index.php?page=ice1724


By the way, thanks for this guide. Very, very useful.
 
Jun 5, 2006 at 4:14 AM Post #13 of 14
I tried installing my AV710 with ALSA 1.0.11 and I get the following error:
Code:

Code:
[left]# alsactl -f /var/lib/alsa/asound.state restore alsactl: set_control:888: warning: iface mismatch (3/2) for control #53 alsactl: set_control:890: warning: device mismatch (1/1) for control #53 alsactl: set_control:892: warning: subdevice mismatch (0/0) for control #53 alsactl: set_control:894: warning: name mismatch (IEC958 Playback Con Mask/IEC958 Playback Con Mask) for control #53 alsactl: set_control:896: warning: index mismatch (0/0) for control #53 alsactl: set_control:888: warning: iface mismatch (3/2) for control #54 alsactl: set_control:890: warning: device mismatch (1/1) for control #54 alsactl: set_control:892: warning: subdevice mismatch (0/0) for control #54 alsactl: set_control:894: warning: name mismatch (IEC958 Playback Pro Mask/IEC958 Playback Pro Mask) for control #54 alsactl: set_control:896: warning: index mismatch (0/0) for control #54[/left]

When I play sound through the digital output, all I get is static. Any ideas?
 

Users who are viewing this thread

Back
Top