Asus A7N8X-X: No sound

[Luposian]

I have an Asus A7N8X-X motherboard. I'm using the built-in audio.

When I JAM a build of Haiku (most recently hrev35460 or thereabouts), and boot to that partition, the first time, sound works perfectly. But after rebooting, I can't get sound out of the system, no matter what I do.

I don't think it's a startup issue (else why would it work the first time?). I suspect it may be a shutdown issue that somehow corrupts something.

I sense something is being changed, at some point, and rendering audio no longer hearable, after a reboot. I don't think drivers can be altered during reboot (if at all), so it must be something in the audio path that IS alterable. Audio add-ons, perhaps? Dunno.

[Luposian]

I've added a screenshot showing the hardware detected and the revision of Haiku. Hope this helps. If needed, I can also upload a syslog. I just reJAM'd the same revision and booted into it and now I didn't get any audio the first boot, either! Everything but the audio seems to work fine though.

I'm going to try creating a bootable CD of this revision, to see if that has any affect. I will also create a bootable CD of hrev35401, which works fine on my other system (also uses an nVidia chipset, but newer. Finally got audio working on it just a couple months ago).

[Luposian]

Ok, I just booted the system from the Haiku hrev35401 CD I created and audio works perfectly. I then proceeded to install hrev35401 onto the system and, after rebooting to boot off the hard drive, audio was non-existent!

So, something is different (or unchanged) on the CD that is no longer the same when Haiku is booted from the hard drive. So this "problem" goes back to at least hrev35401, but it's not a blatant (consistent problem, no matter what you do) issue... it's a subtle issue. Something that isn't a problem, when using the CD, but IS a problem, when booting from the hard drive!

Something is being changed/altered, that's affecting sound output. But what? Someone want the hrev35401 CD .iso image so they can pick through the differences? Or would a syslog reveal the issue?

[Luposian]

Ok, this is just getting weird. Because, I tried the hrev35401 CD again and there was no sound! But then, a couple seconds later, the sound came on! Yet, when I boot into Ubuntu, the sound is ALWAYS there. So, it CAN'T be a purely hardware issue, otherwise it would affect Ubuntu as well!

And the hrev35462 CD I created, which didn't have sound when I tried it right after I created it, suddenly has sound, after a few seconds of silence!

I figure the best thing to do is to delete the entire Haiku folder, update Ubuntu fully, and start over from scratch. Because something just doesn't make any sense! Sound is there, then it's not there. Or it pops in after several seconds of silence!

But a CD's contents don't change. Yet this issue does. So it CAN'T be the CD, can it?

Is this a Haiku bug or isn't it? I'm not sure anymore.

*sigh*

[korli]

A syslog would definitely help in any bug report.
What makes you think your audio is HDA ?

[Luposian]

Replying to korli:

A syslog would definitely help in any bug report.
What makes you think your audio is HDA ?

Sorry... just trying to get the most detailed descriptive for the report. The chipset actually uses "nVidia auich", I think. Oddly enough, the problem is definitely sporadic. Sound is there or it isn't. But, sometimes it pops in after a few seconds of dead silence. Totally crazy. I will try to get a syslog for you tomorrow.

[Luposian]

Here's the syslog I promised. Fresh from a bootup just a few minutes ago.

[korli]

Thanks. No message would explain your problem though. Did you had sound with this syslog ?

I noticed several drivers use the interrupt 0xb on your setup. As a test, you could try to remove the ethernet driver and/or the usb one. Did you also setup a startup sound ?

[Luposian]

Replying to korli:

Thanks. No message would explain your problem though. Did you had sound with this syslog ?

I noticed several drivers use the interrupt 0xb on your setup. As a test, you could try to remove the ethernet driver and/or the usb one. Did you also setup a startup sound ?

Since the audio is sporadic in one of three possibilities (it's either there, or it's not, or it comes in after several seconds of dead silence), it's random chance as to knowing when sound will or won't be there. I didn't have the speakers on at the time I pulled this syslog, but if, as a possibility, it's an inturrupt-based bug, I can tell you that I only had my Logitech Trackman Marble plugged (USB) in at the time. I could try plugging in a PS/2 mouse to see if that would salve the problem. As far as Ethernet, I could pull the driver and see if that solves the problem.

I have not set a startup sound (what format should it be in? Any other requirements for file size/type/quality, etc.?) Should I?

[Luposian]

Ok, I found the culprit... it's in the folder "usb" with Mr. "Eh?", "Oh!", and "Uh..."

That would, non-comically, be the binary (not link) files:

EHCI OHCI UHCI

All related to USB, of course.

I temporarily "trashed" nforce (the network driver) and that didn't fix the problem. I then also "trashed" the usb folder and that fixed the problem (after 6-8 reboots, sound worked every time). I then restored nforce where it belonged, and after 6-7 reboots, sound worked every time.

So, if it's a interrupt issue, we now know who is interrupting the "sound party" :-D

[mmadia]

IIRC, umccullough has the same issue on one of his pc's. Luposian: could you restore the trashed drivers and see if a cold-boot vs. warm-reboot makes a difference?

[Luposian]

Replying to mmadia:

IIRC, umccullough has the same issue on one of his pc's. Luposian: could you restore the trashed drivers and see if a cold-boot vs. warm-reboot makes a difference?

What would that help diagnose? If it was found to be a warm-boot issue (meaning, if you cold boot, it works fine), does that then mean I'd have to cold boot my system every time I want to make 100% certain I will have audio? That gets into the realm of inconvenience. In removing the USB drivers mentioned, the problem is no longer there. I can turn the system on now and test it again (it will be a VERY cold boot -- it's extremely cold out in the workshop tonight) and see if the problem is still gone. If so, then, as far as I would suspect, it must be the USB drivers. If the problem is present after a cold boot (with the USB drivers "removed"), then that lends credibility to it being a cold-boot issue. But I'm not about to cold-boot my system 7-8 times in a row... that's (while do-able) rather time consuming and inconvenient.

An OS is suppose to be reliable... you must be able to trust that it will perform as expected when you first boot it, vs. rebooting it a dozen times. Nay, even if you yank the power plug (as Jean-Louis Gassee' did, during his presentation of BeOS)! :-D

If the general consensus is that I really should try this drawn out "cold-boot" (with all drivers accounted for), I will go ahead and do it. But I'd rather not have to, if I don't have to.

[anevilyak]

Replying to Luposian:

What would that help diagnose? If it was found to be a warm-boot issue (meaning, if you cold boot, it works fine), does that then mean I'd have to cold boot my system every time I want to make 100% certain I will have audio? That gets into the realm

It would help determine if the problem is the driver not properly coping with certain initial hardware states.

of inconvenience. In removing the USB drivers mentioned, the problem is no longer there. I can turn the system on now and test it again (it will be a VERY cold boot -

This in no way establishes that it's a bug in the USB drivers. Rather it points at the possibility of an issue with interrupt handling/sharing (which could be a problem in any of the involved drivers, or even hardware). Knowing if warm/cold boot makes any difference would be helpful in making a more meaningful diagnosis. If you want the problem to be fixed correctly, then you're going to have to be able to give as much information as is needed to correctly determine the problem, not make assumptions that you know what the problem is when you have no understanding of the code involved.

[Luposian]

Very well... I shall reenable the USB driver(s) and Cold Boot (I assume that means a full shutdown and power back up... do I have to wait any certain period after shutdown to make sure it's a 100% cold-boot when I power the system back on?) the system 6-8 times, just to make sure we have a large enough spread of cold-boots to compare between.

Should I also zap the syslog each time and send the ones that "no sound" occurs with?

Should I make sure there are any setting in the BIOS that are configured a certain way?

I assume "Plug and Play" is meant to remain OFF, right?

Should all IRQ/DMA settings be set to AUTO or something else?

If we're gonna do this, let's do it whole hog and cover every avenue...

[umccullough]

On my Acer Aspire One (AOA150), Haiku's HDA gets screwy and conflicts with USB during a warm boot as well. I am pretty certain this started happening *after* R1/Alpha1, but I haven't figured out when.

At first, I thought it was complete failure after some rev, and was testing as such, but then I later realized that even the most recent rev works after a cold boot (as in: complete power cycle), and all my binary-searching was irrelevant after that :(

When I get more time/motivation, perhaps I'll start searching again for the rev that caused this problem for me.

[Luposian]

Ok, I restored the USB folder (gee, didn't know you could "restore" from the trash, just by clicking on the word "restore"; but normally what goes in the trash goes bye-bye, not back where it started!).

I cold-booted 4 times (shut down completely, waited (on average) about 10-15 seconds) and powered back up... and sound worked fine!

But... on the 5th cold-boot... no such luck. Dead silence! However, about 5 minutes later, the audio file I was playing suddenly popped back in... albeit it with a very noticable studder initially (kinda like it was "coming up to speed" or something). Then it sounded fine.

Whatda ye make of this?

[stippi]

It sounds a bit like the node has some sort of race condition to calculate latency and drift correctly. With the adaptive drift calculation, it may come to life later, such that some buffers begin to arrive at the correct timing (studder), until all buffers arrive correctly.

[Luposian]

I downloaded and built a GCC4 build of Haiku (R35740 or thereabouts) and have rebooted about 6-8 times and every time the sound worked. I *think* the bug has been squashed. I'll leave it up to korli or whomever else, to decide if this ticket should be closed or not. But I can always open another one if the problem comes back.

[korli]

Hello Luposian, could you check with a current revision to see if it's really gone ?

I'll then close if you don't mind.

Thanks.

[korli]

Closing.