Bug 67011

Summary:	linux sound breaks headphones in windows.
Product:	Drivers	Reporter:	Jonathan Fraser (jonathanfras)
Component:	Sound(ALSA)	Assignee:	Jaroslav Kysela (perex)
Status:	NEW ---
Severity:	low	CC:	kundarsa, richardhendricks, superquad.vortex2, szg00000, tiwai
Priority:	P1
Hardware:	x86-64
OS:	Linux
Kernel Version:	3.10.17-gentoo	Subsystem:
Regression:	No	Bisected commit-id:

Description Jonathan Fraser 2013-12-15 20:36:51 UTC

Since this is a cross OS bug, I will place it here in the hopes that it is picked up by a wise a noble champion. Fearless enough to wade into the bowels of the beast which is linux sound.    

After a warm reboot from linux into windows 7, the head phone jack no longer works (in windows). The main speakers will mute but, no sound out of the headphones. The headphones always work in gentoo.  While you may think aha, this is a windows bug. But no no my friend, as a cold boot leaves the headphones in a working state. 

It appears as though the linux sound system places the sound card in such a state that the headphones become unusable from windows.

Reproducible: Always

Steps to Reproduce:
1.Have a dual boot system of the appropriate hardware
2.boot into linux, enjoy headphones
3.reboot into windows
4.cry silently
Actual Results:  
The headphones mute the main speakers in windows but produce no sound.

Expected Results:  
the headphones should work in windows regardless of what OS I rebooted from.

Laptop, G74Sx with a realtek sound card. This uses the intel_hda module. The particular realtek chip is ALC269VB.

Comment 1 Takashi Iwai 2013-12-16 09:07:05 UTC

As your wise hindered mind already know, it's clearly a bug of either BIOS or Windows.  Put in another way: if Linux sound doesn't work after Windows boot (it happens often), would you blame Microsoft to fix their bug?

But, at least, you can try to figure out what triggers the problem.  For example, avoid the extra quirks for the laptop by passing model=generic option to snd-hda-intel.  If this helped, try to narrow down which part of patch_alc269() codes affects it, step by step.

Comment 2 Jonathan Fraser 2013-12-17 04:37:18 UTC

Since Realtek makes the card and the (windows) drivers. They get to decide the space of valid card configurations, if linux is placing it into a state that is not valid (even if said state is not documented) then it is a linux bug. The onus is on really on whomever if violating spec, and that spec gets to be chosen by the hardware manufacturer.

Now I don't know who is out of "spec" here. For all I know it could be ASUS, but I have access to the linux code and there is a helpful and active community. So i figure I might take the first whack here.

I have booted with the generic flag, It appears that the headphones work in windows with that flag set; however, it breaks the speakers in linux (headphones still work however). Interestingly enough, the 269VB codec (which I believe is the one that is loaded), has a very custom "shutup" function whatever that does.

Comment 3 Raymond 2013-12-17 06:17:57 UTC

you have to post output of alsa-info.sh  ( after cold boot and after warm boot from windows)

Comment 4 Takashi Iwai 2013-12-17 06:24:25 UTC

Whatever you define the "spec", it's the very job of BIOS who initializes the audio codec chip cleanly and it's the job of Windows driver who initializes the codec verbs properly.  So it cannot be a "bug" of Linux per se.

If the same thing happened to other side (Windows warm boot breaks Linux), we don't need to fix anything in Linux, according to your argument?  I wish everyone would agree with it; it'll reduce lots of our works! :)

The shutup function is to avoid a noise at shutdown, so this is likely the cause.  You can comment out the whole or the part of it to see whether it affects.

Comment 5 Rich Hendricks 2014-02-14 08:08:12 UTC

Link to datasheet for the ALC269 codec chip from Realtek:

http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=24&PFid=24&Level=4&Conn=3&DownTypeID=1&GetDown=true&Downloads=true#ALC269

(uses Javascript to login to an FTP server, so you can't just directly link to it)

It might not be a SW bug, it is possible that the chip itself does not handle reset properly - maybe some registers are not reset, and Windows is expecting the default value and not configuring them.  It is also possible the laptop is violating the reset timing sequence, causing the chip to not properly reset itself (but not likely).

That being said, here are some things from looking at the datasheet...

Verb 8.20 in their datasheet looks interesting.

There's something interesting, in a note to Verb 8.25:

(hand-copied since they decided to disable cut&paste in their PDF)

Note: The 32-bit registers for each Pin Widget are sticky and will not be reset by a LINK Reset or Codec Reset (Function Reset Verb).

Sounds suspicious to me.  Checking the ALC269 code for any use of that verb is where I would start.

Are you using their latest driver set from here?

http://152.104.125.41/downloads/downloadsView.aspx?Langid=1&PNid=14&PFid=24&Level=4&Conn=3&DownTypeID=3&GetDown=false#2

Looking at it, it looks like it doesn't use the SET_CONFIG_DEFAULT_BYTES verbs.

There is an interesting line of code in patch_realtek.c at line 3421, something about Asus X101 fixup, that does a SET_PIN_WIDGET_CONTROL to 0.  It's more likely though that your laptop is matching to the ALC269_FIXUP_ASUS_G73JW, which does something with the pins (comments say subwoofer, but who knows).  Or perhaps Realtek hasn't created a fixup specific for your laptop yet.  Without schematics for the laptop itself it's hard to say what may or may not be necessary.

Best of luck.

Comment 6 Raymond 2014-02-14 13:32:31 UTC

try dump the processing cofficients warm boot after windows


https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=cd262518a3ae4465e8e51c29641d98c4ed0651a1