After Standby: Audio Control Panel options invert and won't allow changing back until reboot.

[GoogleCodeExporter]

What soundcard to you have (make, model, chip)?
Onboard CMI 8738, on a Soyo KT400 Dragon Ultra Platinum motherboard:
http://www.soyo.com/product/search/1/SY-KT400_DRAGON_Ultra_(Platinum_Edition)/13
8

What steps will reproduce the problem?
1. Set options as desired in audio control panel and begin normal PC use
2. Allow the computer to enter standby normally, or force it into standby
3. Wake the computer up via power button
4. Upon resume, no sound, and audio control panel options are wrong, and
will not allow proper configuration until reboot.

What is the expected output? What happens instead?
I would expect standby to have no effect on audio output once resume/wake,
and that the options in the audio control panel would remain the same.

Instead, upon resume I lose all audio.  The audio control panel options are
changed preventing audio out.  You can change the options, but upon hitting
Apply or OK, they revert to how they were (the incorrect ones). 
Furthermore the first two radio button options, have 3 of the 4 radio
buttons selected (inverse of normal) which is also very odd.  Nothing I've
found will fix the audio control panel, except a restart/shutdown.  Upon
restart, the options are still wrong, but once changed they will STAY that
way and will not revert upon hitting OK/Apply.  And it will keep working
great, until the PC enters standby again...

I took two screen shots (driver3.jpg and driver4.jpg) of the audio control
panel with the settings I normally use properly selected.  Then I took two
more screenshots (driver1.jpg and driver2.jpg) showing what those same two
tabs in the 'panel, with how they look after standby... Attached them to
this post.

What version of the driver are you using? On what operating system? What
version of the operationg system are you using (32 or 64 bit)?
Driver version 1.2.3
Windows XP Professional, Service Pack 3, 32 bit.

What ports of the soundcard are affected by the bug (e.g. SPDIF, Mic-In)?
SP/DIF OUT is all I use this card/driver for.  So that's what I'm noticing
a problem with.

Please provide any additional information below.
I have tried several uninstallations and reinstallations of the drivers
originally upon narrowing down this problem / figuring out the circumstances.  

Thank you very much for your work on this driver!!
-Jim

Original issue reported on code.google.com by protonus.ws@gmail.com on 15 Mar 2009 at 9:26

Attachments:

• driver3.JPG
• driver4.JPG
• driver1.JPG
• driver2.JPG

[GoogleCodeExporter]

First of all, thanks for the report.

Unfortunately, I haven't been able to reconstruct this bug with my installation 
of 
Windows XP SP3, so I'd like you to do the following:
Please install a debug version (see attachment) and send me the debug log if 
it's 
not too much trouble. For that, download DebugView 
(http://www.microsoft.com/technet/
sysinternals/utilities/debugview.mspx) and start it before you update to the 
debug 
version of the driver. Then try to install the driver (you can use setup.exe), 
and 
after that, start cmicontrol, press "Apply", close it and do a standby / normal 
operation cycle. Then restart cmicontrol and press "Apply". That should 
hopefully 
give me a clue on what went wrong.
There's no hurry, so take all the time you need.

Original comment by dogb...@gmail.com on 19 Mar 2009 at 6:21

Attachments:

• debug-x86.zip

[GoogleCodeExporter]

I installed debuView, started the program then updated your new debug build of 
the
driver.  It asked me to restart which I did.  I noticed that nothing was 
generated in
Debug View though.  After restart I started DebugView again, and then the 
control
panel.  Noticed the version was now 1.2.4-debug. 

Did an apply/close cycle, and noticed that still nothing in DebugView. I 
enabled the
option for "Capture Kernel" which was not enabled by default, and did another
apply/close cycle in the control panel.  This time it generated content.  I 
assume
this is what you wanted.

So I did a standby/resume cycle.  Launched the control panel again, and it 
showed the
incorrect settings / problem I reported.  Did another apply/close and verfied
DebugView showed updated content.  I saved this log and attached it here.  
Hopefully
this is what you needed, let me know if I need to do anything else! Thanks!

Original comment by protonus.ws@gmail.com on 19 Mar 2009 at 9:11

Attachments:

• debuglog.LOG

[GoogleCodeExporter]

Thanks for the log. Superficially, everything looks alright.

Does the computer account you are using have administrator rights?

After a standby cycle, can you please try to disable and enable the device in 
the 
device manager while running DebugView?

Original comment by dogb...@gmail.com on 19 Mar 2009 at 9:35

[GoogleCodeExporter]

Yes, I am logging in as an administrator user.  

I created two new logs for you.  The first, log2.log, was me rebooting the PC 
to fix
the control panel and then setting the values normally and hitting ok.  Then I
started the DebugView.  I then reopened the control panel and hit apply/ok.  
Then I
went into standby.  Then resumed.  Then went back into the control panel and 
verified
the settings were corrupt as usual. I hit apply/ok again.  By this point, this 
is the
same thing that you had me try before, except I noticed it had generated a lot 
more
entries this time.  After this, I then went into device manager, and hit 
disable on
the device except I accidently clicked cancel instead of OK.  I did it again 
and hit
ok.  It asked for a reboot but I did NOT reboot. I then Enabled the device 
again. 
Again I did NOT reboot.  I closed device manager, and saved the log as log2.log.

The second new log, log3.log, I did right after the aforementioned one.  
Without a
reboot or doing anything else, I started DebugView again, and went into Device
Manager, and disabled the device. I did NOT reboot when asked.  I then enabled 
the
device, and again, did not reboot.  I then closed device manager and saved it as
log3.log.  I think that is all you asked for me to do in this second log.  But I
included the first one too as hopefully it may contain more info then the 
original
log.  Hope this helps!  

Original comment by protonus.ws@gmail.com on 20 Mar 2009 at 2:46

Attachments:

• log3.log
• log2.LOG

[GoogleCodeExporter]

Thank you very much for the logs - that has finally given me the right idea.

My guess is that after a standby cycle, access to the PCI I/O is somehow 
blocked 
(0xFF values in the registers - every bit is '1'). If you disable and enable 
the 
driver manually, the I/O stuff should be completely reinitialized and possibly 
prove 
that this might be a workaround for this bug.

However, when you are asked for a reboot after disabling the device, some app 
seems 
to be using the soundcard and therefore blocking the driver from unloading. Can 
you 
try to identify this app and close it before trying to unload the driver?

Again, thanks for your effort - I'm happy about every bug I can squash.

Original comment by dogb...@gmail.com on 20 Mar 2009 at 10:46

[GoogleCodeExporter]

Any news so far?

Original comment by dogb...@gmail.com on 26 Mar 2009 at 8:31

[GoogleCodeExporter]

Hi, sorry it took so long just had a busy week here.  I did the following:

1. Verified I had audio / normal ACP (i'll start abbreviating Audio Control 
Panel)
settings, after normal boot.
2. I closed all apps and processes that were non essential to Windows.  Very 
clean -
18 processes total.
3. I launched debug view to start a log.  
4. I put the computer into standby and then resumed it.
5. Verified after resume, per usual I had no Audio and ACP settings were whacky 
again
like "usual".  Verified changing them didn't "stick" per usual.
6. I went into device manager and disabled the audio device.  Did NOT restart 
like it
asked.  I then enabled it again and closed device manager etc.  
7. I went back into the ACP - the settings were still whacky, and changing them 
did
not "stick" still after applied...  
8. I closed and saved the log i'm attaching here...

So it seems like disabling/re-enabling the device even with all non-essential
programs/processes closed, isn't working as a work around.  I'm rather 
confident I
had no applications or processes running that would be using audio or affecting 
this.
 This PC is rather clean/barebones too.  But perhaps this log will show something
new/useful?  Let me know if you need me to do more testing! Thanks!

Original comment by protonus.ws@gmail.com on 27 Mar 2009 at 6:34

Attachments:

• 032709.LOG

[GoogleCodeExporter]

Here is a log from process explorer showing all running processes I have open 
at the
time of this testing - only 17 processes total.  Very clean I think.  The SVC 
hosts
are just running normal Windows XP Services as far as I see.  

Original comment by protonus.ws@gmail.com on 27 Mar 2009 at 6:40

Attachments:

• Procexp.txt

[GoogleCodeExporter]

Thanks again for the detailed log.

You are right: I can't make out any process which might use the soundcard and 
block 
the driver from unloading, so there has to be some other cause.

I took another dive into the source code: the C-Media hardware is pretty old-
fashioned, and its registers aren't memory mapped like most other PCI devices, 
but 
accessible only over I/O. This is pretty much straightforward and doesn't 
require 
initialization which suggests that the blocking of the I/O access after a 
standby 
cycle is caused either by a buggy BIOS or a buggy chipset driver.

The only advise I can give you for now is to try some different versions of the 
chipset driver and to fiddle around with the BIOS settings and/or versions. In 
order 
to test whether this has an effect or not, I suggest employing tools which 
allow 
direct access to the PCI I/O registers from user mode, for instance WPCREDIT. 
The 
vendor/device ID of the C-Media device should be 13F6:0111 or 13F6:0110. If you 
read 
out the PCI registers of the C-Media device after a standby cycle and most of 
them 
are 0xFF, then the hardware is inaccessible.

Good luck!

Original comment by dogb...@gmail.com on 28 Mar 2009 at 5:30

[GoogleCodeExporter]

Original comment by dogb...@gmail.com on 11 Sep 2010 at 6:07

• Changed state: Invalid

[GoogleCodeExporter]

I ended up getting a new HTPC, and throwing a video card in it that does audio 
over HDMI, so this is no longer an issue for me as I'm no longer using that 
PC/sound card/this driver. Thanks. 

Original comment by protonus.ws@gmail.com on 13 Sep 2010 at 3:30