Buzzing snd_emu10kx enabled card with r206173

[Garrett Cooper]

On Tue, May 25, 2010 at 3:06 AM, Mark Stapper <stark at mapper.nl> wrote:
> On 18/05/2010 08:14, Mark Stapper wrote:
>> On 18/05/2010 00:22, Garrett Cooper wrote:
>>
>>> On Mon, May 17, 2010 at 11:21 AM, Mark Stapper <stark at mapper.nl> wrote:
>>>
>>>
>>>> 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
>>>>>
>>>>>
>>>> I have the same problem.
>>>> I'll try compiling the driver in the kernel.
>>>>
>>>>
>>>     FWIW I've compiled the driver into the kernel for several
>>> iterations now and it works like a champ, so there's something with
>>> the sound subsystem that isn't jiving properly when loading from
>>> modules...
>>> HTH,
>>> -Garrett
>>>
>>>
>> Thanks for the info.
>> I've noticed that when I load the kernel module at startup (by adding it
>> to loader.conf) chances of it working improve.
>> If I load it afterwards, the nice huff puff sounds come out of my
>> speaker again.
>> Compiling the new and improved kernel today.
>> Thanks for your help.
>> Greetz,
>> Mark
>>
>>
> I compiled the emu10kx driver into the kernel.
> That seemed to work, but now the hissing and buzzing is back.
> I really don't know what is going on anymore..
> Any thoughts?

What modules have you compiled and loaded?
Thanks,
-Garrett