Prev: PCI quirk: AMD 780: work around wrong vendor ID on APC bridge
Next: [PATCH] NFS: Add a missing unlock into nfs_access_cache_shrinker()
From: Clemens Ladisch on 26 May 2010 10:00 Jan Engelhardt wrote: > On Wednesday 2010-05-26 14:10, Takashi Iwai wrote: >>> /proc/asound/cards: >>> 0 [SB ]: HDA-Intel - HDA ATI SB >>> HDA ATI SB at 0xf0500000 irq 16 >>> 1 [HDMI]: HDA-Intel - HDA ATI HDMI >>> HDA ATI HDMI at 0xf0110000 irq 19 >>> >>> The soundcard responsible for the internal speaker is the 01:05.1/"HDMI" >>> one. >> >>Hmm? HDMI output as the "internal" speaker is abnormal. >> >>> Under Windows XP, I see the following mixer elements for it: >>> >>> * Master Volume >>> * Wave >>> * SW Synth >>> * CD Player >>> >>> Subsequently, there is sound (once I bump the volumes on these). >> >>There are definitely for the onboard sound, not for HDMI. > > The "SB" card has many more mixers (counting 10) and Windows XP also > shows about that many for SB. But neither in Linux nor Windows does > the SB card have any effect; I do have to turn the bars of the "HDMI" > one. > > Abnormal, well. It's (semi-)embedded, what did you expect. It is extremely unlike that your embedded device has separate chips to decode the HDMI sound signal and then convert it to analog, when the same is already available with the normal HDA device. Your alsa-info output shows that there is an ALC262 codec connected to the "SB" device; this chip wouldn't have been put there if it didn't have a function. Try unmuting and raising both the Master and Beep controls. The Windows mixer elements are software-emulated and shown for all devices. (I don't know why the only working device is labeled "HDMI", maybe someone just mixed up the HDA devices.) Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Takashi Iwai on 26 May 2010 10:00 At Wed, 26 May 2010 15:47:26 +0200 (CEST), Jan Engelhardt wrote: > > > On Wednesday 2010-05-26 14:39, Takashi Iwai wrote: > >> > > >> >There are definitely for the onboard sound, not for HDMI. > >> > >> The "SB" card has many more mixers (counting 10) and Windows XP also > >> shows about that many for SB. But neither in Linux nor Windows does > >> the SB card have any effect; I do have to turn the bars of the "HDMI" > >> one. > >> > >> Abnormal, well. It's (semi-)embedded, what did you expect. > > > >Wow, then is the HDMI cable connected inside the device? > > Possibly. It looks quite embedded behind the casing - no recognizable > connectors, just soldering and wiring onto headers. > > >Anyway, "IEC958 Playback Switch" should be turned on for HDMI. > > > > % amixer -c1 IEC958 on > > Well that does nothing. As there is no PCM channel for it, there is no > /dev/snd/pcmC1*, and thus mplayer - or any other progarm - won't even > try to output anything. There is /dev/snd/pcmC1D3p. This should corresponds to HDMI output. Try "aplay -vv -Dhdmi:1 foo.wav" or so. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jan Engelhardt on 27 May 2010 06:40 On Wednesday 2010-05-26 15:58, Clemens Ladisch wrote: >Jan Engelhardt wrote: >> On Wednesday 2010-05-26 14:10, Takashi Iwai wrote: >>>> /proc/asound/cards: >>>> 0 [SB ]: HDA-Intel - HDA ATI SB >>>> HDA ATI SB at 0xf0500000 irq 16 >>>> 1 [HDMI]: HDA-Intel - HDA ATI HDMI >>>> HDA ATI HDMI at 0xf0110000 irq 19 >>>> >>>> The soundcard responsible for the internal speaker is the 01:05.1/"HDMI" >>>> one. >>> >>>Hmm? HDMI output as the "internal" speaker is abnormal. >> >> The "SB" card has many more mixers (counting 10) and Windows XP also >> shows about that many for SB. But neither in Linux nor Windows does >> the SB card have any effect; I do have to turn the bars of the "HDMI" >> one. >> >> Abnormal, well. It's (semi-)embedded, what did you expect. > >It is extremely unlike that your embedded device has separate chips to >decode the HDMI sound signal and then convert it to analog, when the >same is already available with the normal HDA device. > >Your alsa-info output shows that there is an ALC262 codec connected >to the "SB" device; this chip wouldn't have been put there if it didn't >have a function. > >Try unmuting and raising both the Master and Beep controls. I unmuted everything and bumped the sliders to 100% but that does not change a thing unfortunately; opening the right device (C1D3p) using the suggested `aplay -vv -Dhdmi:1` or `mplayer -ao alsa:device=hw=1.3` does not make any noise either. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Clemens Ladisch on 27 May 2010 07:50 Jan Engelhardt wrote: > On Wednesday 2010-05-26 15:58, Clemens Ladisch wrote: > > Try unmuting and raising both the Master and Beep controls. > > I unmuted everything and bumped the sliders to 100% but that does not > change a thing unfortunately; opening the right device (C1D3p) ... Please do not assume that the "HDMI" device is the right one, since you never got either one to work in Linux. You did try playing through the "SB" card, didn't you? It is possible that an embedded device like this requires some custom initialization. Can you find out if the Windows driver is the standard Microsoft driver or Samsung's? Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Clemens Ladisch on 27 May 2010 08:40
Clemens Ladisch wrote: > Please do not assume that the "HDMI" device is the right one, since you > never got either one to work in Linux. Hmm, that computer is separate from the actual LCD, which has an HDMI input, so it's possible that the HDMI output would be correct. In that case, it's likely that you've run into this bug: https://bugs.freedesktop.org/show_bug.cgi?id=28030 You might try the patch mentioned there, or radeonhd, or fglrx. HTH Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |