Bug 417611

Summary: kernel 2.6.23.8-34.fc7 stops SPDIF output on Audigy 2 Value
Product: [Fedora] Fedora Reporter: Stefan Zakarias <my.my.cro>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 7   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-12-11 07:04:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
My /etc/alsa/asound.state file none

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 ;)