At Mon, 23 Mar 2009 08:24:45 -0700, Russ Dill wrote: > > On Mon, Mar 23, 2009 at 7:57 AM, Takashi Iwai <tiwai@xxxxxxx> wrote: > > At Mon, 23 Mar 2009 07:42:25 -0700, > > Russ Dill wrote: > >> > >> [1 <text/plain; UTF-8 (quoted-printable)>] > >> On Mon, Mar 23, 2009 at 6:40 AM, Takashi Iwai <tiwai@xxxxxxx> wrote: > >> > At Mon, 23 Mar 2009 06:36:06 -0700, > >> > Russ Dill wrote: > >> >> > >> >> On Mon, Mar 23, 2009 at 5:51 AM, Takashi Iwai <tiwai@xxxxxxx> wrote: > >> >> > At Mon, 23 Mar 2009 04:54:34 -0700, > >> >> > Russ Dill wrote: > >> >> >> > >> >> >> On Mon, Mar 23, 2009 at 3:54 AM, Takashi Iwai <tiwai@xxxxxxx> wrote: > >> >> >> > At Sat, 21 Mar 2009 22:23:15 -0700, > >> >> >> > Russ Dill wrote: > >> >> >> >> > >> >> >> >> GIven the recent changes in gnome land (pulseaudio), I'd like to be > >> >> >> >> able to get alsa support for my hardware fixed up. My biggest > >> >> >> >> annoyance right now is that when I plug headphones in, it doesn't mute > >> >> >> >> the speakers. Another issue I have is that I'd like to have support > >> >> >> >> for audio out on HDMI (which is supported by Vista). On with the show. > >> >> >> > > >> >> >> > Try the later version of alsa-driver or kernel, and pass model=auto. > >> >> >> > As default model=acer is chosen for ALC883 with Acer vendor SSID, > >> >> >> > and it's known that it doesn't match with the recent Acer laptops > >> >> >> > at all. The BIOS auto-parsing mode would work better recently. > >> >> >> > >> >> >> I still get dmesg errors (audio does play though): > >> >> >> > >> >> >> [229513.339812] hda-intel: Invalid position buffer, using LPIB read > >> >> >> method instead. > >> >> >> [229513.436583] hda-intel: IRQ timing workaround is activated for card > >> >> >> #0. Suggest a bigger bdl_pos_adj. > >> >> > > >> >> > These are no errors. You can ignore for now. > >> >> > >> >> ok, but the "azx_get_response timeout" ones seem to be as audio > >> >> glitches when the occur. > >> > > >> > Does it happen with model=auto? The driver doesn't work without that > >> > option, as I mentioned. > >> > > >> >> > Which alsa-driver are you using now? At best, try the latest > >> >> > alsa-driver snapshot from > >> >> > ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-snapshot.tar.gz > >> >> > or the sound git tree at > >> >> > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git > >> >> > >> >> I'm currently using whatever comes in 2.6.28 with ubuntu. I'll try out > >> >> the git tree. > >> > > >> > Bah, that's way too old to debug... > >> > > >> >> >> The Center mixer control now controls my left laptop speaker and the > >> >> >> LFE mixer control controls the right speaker. The Surround control > >> >> >> that used to control the laptop speakers now does nothing. > >> >> >> > >> >> >> Attempting to MUTE the LFE channel, the audio skipped a bit and I got: > >> >> >> > >> >> >> [229698.556044] hda_intel: azx_get_response timeout, switching to > >> >> >> polling mode: last cmd=0x10db0001 > >> >> >> [229699.561017] hda_intel: azx_get_response timeout, switching to > >> >> >> single_cmd mode: last cmd=0x10db0001 > >> >> >> > >> >> >> My system just hung (likely due to wireless drivers) and I rebooted > >> >> >> and with model=auto again, the mixer controls are different. There is > >> >> >> no LFE or Center controls, but there is an added Headphone volume > >> >> >> control (which does nothing). Front controls the headphone volume, > >> >> >> nothing controls the speaker volume. > >> >> >> > >> >> >> I've been unable to hear digital output (mplayer -ao alsa:device=iec958). > >> >> > > >> >> > The device is likely not "iec958" but "hdmi". > >> >> > >> >> no such device exists with model=auto (or without setting model). > >> > > >> > Yes, too old version :) > >> > > >> >> >> My laptop has an internal microphone, two internal speakers, a > >> >> >> headphone jack, a mic in jack, a line in jack, and digital audio out > >> >> >> via hdmi. > >> >> > > >> >> > And alsa-info output? Use model=auto from now on. > >> >> > The default model (acer) doesn't work obviously for your laptop. > >> >> > >> >> It was attached to the previous email > >> > > >> > Ah, overlooked. Thanks. > >> > > >> > But better the one from the latest driver... > >> > > >> > > >> > Takashi > >> > > >> > >> OK, I've bolted your master branch in your git tree onto my kernel: > >> > >> [10580.958816] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, > >> low) -> IRQ 16 > >> [10581.101270] input: HDA Digital PCBeep as > >> /devices/pci0000:00/0000:00:14.2/input/input8 > >> > >> My mixer controls are very similar to what I got before, except now > >> Front controls both the front speakers, and the headphones. Plugging > >> in and unplugging the headphone jack still has no effect. > > > > See below. > > > >> There is also a "Beep" control now. > > > > It's a new feature in the new version. > > > >> There is still no PCM device labled hdmi, and outputting to iec958 > >> device doesn't get me any audio output via HDMI. > > > > Right, it's apparently not set by BIOS, so the driver can't detect > > it. > > > > How is the HDMI connected? Is it from the graphic chip/board > > or any other route? In the latter case, an HDMI transmitter (codec) > > is connected to the main audio controller, typically in the 4th slot > > (codec#3). In the former case, it usually appears as an individual > > PCI device. > > There are no other sound related PCI devices, and my graphics chip is > an R500 which doesn't support audio, so it must be coming from a > digital interface of SB450. > > > If the SPDIF digital device is supposed to be HDMI, then it's a bug of > > BIOS. In that case, using "iec958" is the right choice. > > But I haven't been able to get it working under Linux. Then something is still missing... > > Anyway, you could build the driver with --with-debug=verbose configure > > option and try to pass probe_mask=0x1ff. This will force to probe > > all codec slots. See kernel messages. > > I must be building differently, I'll translate that to > CONFIG_SND_DEBUG=y and CONFIG_SND_DEBUG_VEBOSE=y. Where is the > configure script? It was about alsa-driver tarball. If you build directly from sound.git tree (I suppose right?), these two kconfigs correspond. > [13329.546638] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, > low) -> IRQ 16 > [13329.546650] hda_intel: codec_mask forced to 0xff > [13330.581024] hda_intel: azx_get_response timeout, switching to > polling mode: last cmd=0x200f0000 > [13331.585015] hda_intel: Codec #2 probe error; disabling it... > [13332.620024] hda_intel: Codec #3 probe error; disabling it... > [13332.756133] input: HDA Digital PCBeep as > /devices/pci0000:00/0000:00:14.2/input/input9 So, it's not in the codec slot#3, too. > >> I can still get: > >> > >> > >> [11025.533020] hda_intel: azx_get_response timeout, switching to > >> polling mode: last cmd=0x106f000a > >> [11026.537063] hda_intel: azx_get_response timeout, switching to > >> single_cmd mode: last cmd=0x106f000a > > > > Hm. Judging from alsa-info output, the verb looks correct, it's PCM > > parameter inquiry against the widget 0x06. So, your hardware is > > really flaky. What happens if you add > > codec->bus->needs_damn_long_delay = 1; > > in patch_realtek.c:patch_alc883() ? > > Doesn't seem to have an effect, its easy to reproduce my switching a > control while music is playing. > > [13932.100052] hda_intel: azx_get_response timeout, switching to > single_cmd mode: last cmd=0x10db2001 Hmm. What about setting enable_msi=1? > >> [11027.813799] hda-intel: IRQ timing workaround is activated for card > >> #0. Suggest a bigger bdl_pos_adj. > > > > This should be the side-effect of the codec communication error above. > > > >> while playing audio. > > > >> I've attached the associated alsa-info.txt > > ... > >> control.4 { > >> comment.access 'read write' > >> comment.type BOOLEAN > >> comment.count 2 > >> iface MIXER > >> name 'Headphone Playback Switch' > >> value.0 false > >> value.1 false > > > > Unmute "Headphone" switch. > > I've tried, hotplugging the headphones has no effect whether or not > this switch is on or off. I guess the communication with the codec gets already screwed up, thus it couldn't be handled properly any more. I'm not sure what is the reason, but what I can say is that ATI controller is pretty unstable regarding HD-audio. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
