Buzzing snd_emu10kx enabled card with r206173
Mark Stapper
stark at mapper.nl
Tue May 25 10:07:15 UTC 2010
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?
-------------- 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/20100525/0973c53a/signature.pgp
More information about the freebsd-multimedia
mailing list