Buzzing snd_emu10kx enabled card with r206173

[Mark Stapper]

On 12/04/2010 16:29, Garrett Cooper wrote:
> On Tue, Apr 6, 2010 at 3:39 AM, Garrett Cooper <yanefbsd at gmail.com> wrote:
>   
>> On Mon, Apr 5, 2010 at 12:26 PM, Garrett Cooper <yanefbsd at gmail.com> wrote:
>>     
>>> On Mon, Apr 5, 2010 at 11:22 AM, Garrett Cooper <yanefbsd at gmail.com> wrote:
>>>       
>>>> Hi,
>>>>    When I first installed FreeBSD on this machine, I had a heck of a
>>>> time getting the soundcard's PCM channel to function properly. It
>>>> would buzz incessantly when I played any audio on it; I disabled the
>>>> onboard snd_hda enabled audio and things magically worked, until
>>>> today. After a kernel upgrade and a few warm boots, I'm back to where
>>>> I started from -- the PCM channel buzzes whenever I play audio;
>>>> line-in works perfectly fine however. I'm not seeing anything out of
>>>> the ordinary in commits over the past couple of weeks for the pcm
>>>> pieces (the last successful kernel I used was 2~3 weeks old).
>>>>    Are there any device_printf's I should add or a debug procedure
>>>> that you recommend I do to triage the situation?
>>>> Thanks,
>>>> -Garrett
>>>>
>>>> # uname -a
>>>> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r206173M:
>>>> Sun Apr  4 19:54:22 PDT 2010
>>>> root at bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA  amd64
>>>> # pciconf -lv | grep -A 4 emu
>>>> emu10kx0 at pci0:8:0:0:    class=0x040100 card=0x10211102 chip=0x00081102
>>>> rev=0x00 hdr=0x00
>>>>    vendor     = 'Creative Technology LTD.'
>>>>    device     = 'sound blaster Audigy 2 (ca0108)'
>>>>    class      = multimedia
>>>>    subclass   = audio
>>>> # dmesg | grep 'irq 16'
>>>> uhci0: <Intel 82801JI (ICH10) USB controller USB-D> port 0xa800-0xa81f
>>>> irq 16 at device 26.0 on pci0
>>>> pcib7: <ACPI PCI-PCI bridge> irq 16 at device 28.1 on pci0
>>>> emu10kx0: <Creative Audigy 4 [SB0610]> port 0xec00-0xec3f irq 16 at
>>>> device 0.0 on pci8
>>>> # dmesg | grep 'pcm'
>>>> pcm0: <EMU10Kx DSP front PCM interface> on emu10kx0
>>>> pcm0: <SigmaTel STAC9750/51 AC97 Codec>
>>>> pcm1: <EMU10Kx DSP rear PCM interface> on emu10kx0
>>>> pcm2: <EMU10Kx DSP center PCM interface> on emu10kx0
>>>> pcm3: <EMU10Kx DSP subwoofer PCM interface> on emu10kx0
>>>> pcm4: <EMU10Kx DSP side PCM interface> on emu10kx0
>>>>         
>>> Some more information:
>>>
>>> 1. snd_emu10kx and sound are both modules loaded on boot, along with
>>> if_re, linux, and nvidia.
>>> 2. Disabling nvidia -> no change.
>>> 3. Disabling acpi -> unbootable system because many drivers can't map
>>> interrupts without it (can't test unless I isolate the drivers and
>>> enable them one by one -- something I'll try later on).
>>>
>>> I'm at a loss right now... my hunch is that it's potentially a bad
>>> interaction between the snd_emu10kx driver and another driver on the
>>> same PCI bus (which is just the ACPI and uhci drivers), but I can't
>>> test these claims. There are other funky things about my system that
>>> have changed over the past couple of kernel versions, like front USB
>>> ports could charge my iPhone, and now they don't... and the fact that
>>> ACPI blanking via nvidia now works again... so something may have
>>> changed on the backend, but I'm not 100% sure on what I should isolate
>>> as the root cause, yet.
>>>       
>> Grr... it's `healed' itself again. I'll watch out for potential
>> catalysts to the issue in the future.
>>     
>     Ok. Damn issue came back and here's what happened. Rebooted
> several times with the same kernel and slight modifications, loading
> and unloading snd_emu10kx and sound, testing out snd_emu10k1, and no
> dice. The buzz was bad and it was driving me insane. Again, line-in
> functioned just fine, so I didn't know what the heck was going. I was
> getting desperate, so I finally broke down and booted the Gentoo Linux
> livecd. PCM worked just fine. Then I got irritated enough and finally
> just built the module and the sound support directly into the kernel
> and everything is hunky dorey again. Does anyone have a stab in the
> dark as to what's going on? Is it a potential bus or interrupt
> conflict / race condition that gets alleviated when support is nailed
> into the kernel? Or are other folks as stumped as I am, s.t. I should
> just try emailing current@ instead to see if someone maybe knows
> what's going on there :(...?
> Thanks,
> -Garrett
> _______________________________________________
> freebsd-multimedia at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-multimedia
> To unsubscribe, send any mail to "freebsd-multimedia-unsubscribe at freebsd.org"
>   
I have the same problem.
I'll try compiling the driver in the kernel.
Thank you!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-multimedia/attachments/20100517/2c771c54/signature.pgp