Re: Buzzing snd_emu10kx enabled card with r206173
- From: Garrett Cooper <yanefbsd@xxxxxxxxx>
- Date: Tue, 25 May 2010 11:05:46 -0700
On Tue, May 25, 2010 at 3:06 AM, Mark Stapper <stark@xxxxxxxxx> wrote:
On 18/05/2010 08:14, Mark Stapper wrote:
On 18/05/2010 00:22, Garrett Cooper wrote:I compiled the emu10kx driver into the kernel.
On Mon, May 17, 2010 at 11:21 AM, Mark Stapper <stark@xxxxxxxxx> wrote:Thanks for the info.
On 12/04/2010 16:29, Garrett Cooper wrote:FWIW I've compiled the driver into the kernel for several
On Tue, Apr 6, 2010 at 3:39 AM, Garrett Cooper <yanefbsd@xxxxxxxxx> wrote:I have the same problem.
On Mon, Apr 5, 2010 at 12:26 PM, Garrett Cooper <yanefbsd@xxxxxxxxx> wrote:Ok. Damn issue came back and here's what happened. Rebooted
On Mon, Apr 5, 2010 at 11:22 AM, Garrett Cooper <yanefbsd@xxxxxxxxx> wrote:Grr... it's `healed' itself again. I'll watch out for potential
Hi,Some more information:
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@xxxxxxxxxxxxxxx:/usr/obj/usr/src/sys/BAYONETTA amd64
# pciconf -lv | grep -A 4 emu
emu10kx0@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
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.
catalysts to the issue in the future.
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'll try compiling the driver in the kernel.
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
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
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
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: Buzzing snd_emu10kx enabled card with r206173
- From: Mark Stapper
- Re: Buzzing snd_emu10kx enabled card with r206173
- From: Mark Stapper
- Re: Buzzing snd_emu10kx enabled card with r206173
- References:
- Re: Buzzing snd_emu10kx enabled card with r206173
- From: Mark Stapper
- Re: Buzzing snd_emu10kx enabled card with r206173
- Prev by Date: Re: Kernel panic when unpluggin AC adaptor
- Next by Date: Re: FreeBSD 8.1 prerelease "security.jail.mount_allowed" is broken?
- Previous by thread: Re: Buzzing snd_emu10kx enabled card with r206173
- Next by thread: Re: Buzzing snd_emu10kx enabled card with r206173
- Index(es):
Relevant Pages
|
