Bug 417611 - kernel 2.6.23.8-34.fc7 stops SPDIF output on Audigy 2 Value
Summary: kernel 2.6.23.8-34.fc7 stops SPDIF output on Audigy 2 Value
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 7
Hardware: i686
OS: Linux
low
low
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-12-10 00:48 UTC by Stefan Zakarias
Modified: 2007-12-11 07:04 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-12-11 07:04:40 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
My /etc/alsa/asound.state file (63.23 KB, text/plain)
2007-12-11 03:11 UTC, Stefan Zakarias
no flags Details

Description Stefan Zakarias 2007-12-10 00:48:31 UTC
Description of problem:
Using the 2.6.23.8-34.fc7 kernel stops any digital output (SPDIF) from my
Audigy2 Value card.  Must revert back to 2.6.23.1-23 kernel for the digital
output to work.

Version-Release number of selected component (if applicable):
2.6.23.8-34.fc7

How reproducible:
Enabling Analog output works fine (e.g: the multiple connectors to the analogue
input of the amplifier). If you enable Analogue/Digital output in either Gnome
Volume Control or KMix, then the Analogue (multiple connectors) output is
disabled (no sound), but there is no output from the Digital Output either.  I
am using Optical output to amplifier.

Steps to Reproduce:
1. Open a sound mixer for Alsa (I am not using PulseAudio components)
2. Select/Enable the Analogue/Digital Output switch
3. The kernel 2.6.23.1-23.fc7 works as expected, the kernel 2.6.23.8-34.fc7 has
no sound from the SPDIF connector.
  
Actual results:
No sound output from SPDIF, but there is sound output through the analogue
(multiple) connectors if you disable Analogue/Digital Output.  If you enable
SPDIF (Analogue/Digital Output) then the analogue (multiple) connectors go
silent as well as no sound from the SPDIF connection.

Expected results:
SPDIF should work as in kernel 2.6.23.1-23.fc7.

Additional info:
I am not using PulseAudio.  Using Gnome.  This works in kernel 2.6.23.1-23.fc7,
but fails in kernel 2.6.23.8-34.fc7.  Feeding audio into a Sony Home
Entertainment Amplifier.

Comment 1 Stefan Zakarias 2007-12-10 00:51:08 UTC
Oops...  Where I mention 2.6.23.1-23.fc7, I actually mean 2.6.23.1-21.fc7

Comment 2 Chuck Ebbert 2007-12-10 22:31:40 UTC
You should be able to work around this by going to a console and running this
command as root:

alsactl -F restore



Comment 3 Stefan Zakarias 2007-12-11 03:11:28 UTC
Created attachment 283551 [details]
My /etc/alsa/asound.state file

Comment 4 Stefan Zakarias 2007-12-11 03:18:11 UTC
(In reply to comment #2)
> You should be able to work around this by going to a console and running this
> command as root:
> 
> alsactl -F restore
> 
> 
I tried this, but I get an error:

[root@localhost ~]# alsactl -F restore
alsactl: set_control:970: failed to obtain info for control #213 (No such file
or directory)
alsactl: set_control:970: failed to obtain info for control #217 (No such file
or directory)

If I do the same with the 2.6.23.1-21.fc7 kernel, then I don't get the above
error messages but it does not fix the problem for when I switch to the
2.6.23.8-34.fc7 kernel either :(

I've added my asound.state file (see previous post) so you can see it, but I
noticed that the two numbers referred to in the error messages (213 & 217) point
to IEC controls with strange "values" (compared to the rest of the controls).

Would I be wrong in thinking that this is where the problem lies and that the
2.6.23.8-34.fc7 kernel somehow exacerbates the issue?

Comment 5 Stefan Zakarias 2007-12-11 07:04:40 UTC
I think I've fixed my problem.  I deleted "control.213" in my
"/etc/alsa/asound.state" file and renumbered the remaining controls accordingly.
 This has allowed the sound to pass out to the SPDIF connection.

So yes, kernel 2.6.23.8-34.fc7 does aggravate the problem but it is not this
kernel version's fault.  You could say that it is a problem not highlighted by 
previous kernels and that the newer kernel actually makes it known :)

My apologies for any time wasted on this issue ;)


Note You need to log in before you can comment on or make changes to this bug.