[alsa-devel] PROBLEM: snd_intel_hda audio regression in 2.6.36-rc5

[Takashi Iwai]

At Wed, 22 Sep 2010 18:31:26 +0300,
Aki Parviainen wrote:
> 
> >
> > So, you are testing only over SPDIF output, right?
> 
> Yes, I'm only using SPDIF output!
> 
> > Looks like the SPDIF status bits has been reset by some reason.
> > Try to restore via iecset program included in alsa-utils package,
> > e.g.
> >    iecset original on
> >    iecset category 0x02
> 
> I tried this and didn't notice any difference.

Hm, then you might need to adjust other parameters, too.

> > If this doesn't help, try to unload sound driver once, remove (or
> > backup) /etc/asound.state (which might be in a different path
> > depending on the distro), then load sound modules again.
> > This will restore the default SPDIF status.  Unmute / adjust mixer
> > setups appropriately after doing this.
> 
> I also tried this but didn't notice a difference but however I noticed
> a workaround to this problem that might be related to deleting the
> asound.state (debian places it btw to /var/lib/alsa/asound.state): now
> the regular audio works via SPDIF once again if I first play a file
> with digital preencoded audio. Ie:
> 
> -Boot with 2.6.36-rc5
> -Start kaffeine
> -Play mp3 file -> no sound at all via spdif
> -Play mkv file with 5.1 sound -> sound ok
> -Play mp3 file again -> sound ok!
> -Exit kaffeine & restart kaffeine or vlc
> -Play mp3 file again -> sound ok!

At this state, run "alsactl store", and keep the renewed asound.state
file.  Once when this happens again, just run like
	alsactl -f /your/saved/asound.state store
to restore the status.

> Unfortunately the fix isn't permanent because after reboot I cannot
> get regular sound via spdif until I have once played a file with 5.1
> audio track.

This is unlikely a kernel issue but the user-space issue.
I guess this was triggered because of changes of the id numbers in
mixer elements.  Some user-space program (e.g. kmix) tend to restore
the mixer setup forcibly but often wrongly.  


Takashi