Thanks for the feedback.
The problems below definitely indicate a problem in the build of the
non-debug driver. My guess on the hissing is that a mic or monitor gain
is left on, and hasn't been properly detected by the driver.
I'm passing this on to the Beijing engineers who have the code.
-- Garrett
Tim Foster wrote:
> Hi Garret
>
> ( & hi eeepc-interest at opensolaris.org! Bcc:d a sun.com alias about
> eeepcs - you guys should join the external alias too )
>
> I tested out your new audiohd driver[1] on my Eee PC 701 laptop, which I
> have running 2008.11, the nv_93 update, which is bfu'd to onnv_95 (to
> get S3 suspend/resume, yes I'm impatient :-)
>
> Here's the audio device we have:
>
> pci bus 0x0000 cardnum 0x1b function 0x00: vendor 0x8086 device 0x2668
> Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition
> Audio Controller
>
> Trying to boot with the debug version of the driver results in:
>
> Jul 30 10:22:01 beag genunix: [ID 819705 kern.notice] /kernel/drv/audiohd:
> undefined symbol
> Jul 30 10:22:01 beag genunix: [ID 826211 kern.notice] 'audio_tb_pos'
> Jul 30 10:22:01 beag genunix: [ID 819705 kern.notice] /kernel/drv/audiohd:
> undefined symbol
> Jul 30 10:22:01 beag genunix: [ID 826211 kern.notice] 'audio_tb_seq'
> Jul 30 10:22:01 beag genunix: [ID 819705 kern.notice] /kernel/drv/audiohd:
> undefined symbol
> Jul 30 10:22:01 beag genunix: [ID 826211 kern.notice] 'audio_tb_siz'
> Jul 30 10:22:01 beag genunix: [ID 819705 kern.notice] /kernel/drv/audiohd:
> undefined symbol
> Jul 30 10:22:01 beag genunix: [ID 826211 kern.notice] 'audio_tb_lock'
> Jul 30 10:22:01 beag genunix: [ID 819705 kern.notice] /kernel/drv/audiohd:
> undefined symbol
> Jul 30 10:22:01 beag genunix: [ID 826211 kern.notice] 'audio_trace_buffer'
> Jul 30 10:22:01 beag genunix: [ID 472681 kern.notice] WARNING: mod_load:
> cannot load module 'audiohd'
>
> Booting the non-debug driver is more interesting. On boot, we get a loud
> hissing being emitted from the system speakers (think air being let out
> of a bicycle tyre).
>
> According to gnome-volume-control, the sound level looks like it's about
> 75%.
>
> Doing an audioplay of /usr/demo/SOUND/sounds/bark.au plays the sample
> correctly, at the expected level, but with the same hissing in the
> background unfortunately, so it's hard to hear, but the sample does get
> played.
>
> Opening up gnome-volume-control, we see that built-in speaker and
> line-out outputs are selected. Changing the volume doesn't have any
> effect on the loudness of the hissing, but muting the audio turns it off
> completely.
>
> Turning off the line-out output also turns off the hissing completely,
> but while that's turned off, plugging a set of headphones into the
> headphone socket shows that the hissing is redirected to the headphones.
>
> Going to the "Recording" tab, I expected perhaps that we'd have monitor
> & gain turned up to max (hence the hissing), but this wasn't the case -
> so I'm not sure that's related. The gui shows one mic input.
>
>
> Finally, trying a suspend/resume with this loaded results in us being
> unable to suspend - messages are in the attached archive.
>
>
> I've attached some output that was produced during boot along with
> prtconf -v output for this machine.
>
> Hope this is useful? For now, I'll go back to the hdaudio OSS driver I'm
> using (which while it "works" ok, we don't get any audio
> post-s3-suspend, just several messages along the lines of:
>
> Jul 30 15:10:25 beag hdaudio: [ID 545374 kern.warning] WARNING: RIRB
> timeout (cad=0, nid=2, verb=f0d, parm=0)
>
> )
>
> cheers,
> tim
>
> [1]
> http://gdamore.blogspot.com/2008/07/new-experimental-audiohd-driver.html
>
