[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <s5hr5gl6b9w.wl%tiwai@suse.de>
Date: Wed, 22 Sep 2010 17:36:11 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Aki Parviainen <aki.parviainen@....fi>
Cc: alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
perex@...ex.cz
Subject: Re: PROBLEM: snd_intel_hda audio regression in 2.6.36-rc5
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists