On Wed, Oct 14, 2009 at 9:24 PM, Robert Hancock <hancockrwd@xxxxxxxxx> wrote: > On Wed, Oct 14, 2009 at 9:45 AM, Takashi Iwai <tiwai@xxxxxxx> wrote: >> At Tue, 13 Oct 2009 21:52:02 -0600, >> Robert Hancock wrote: >>> >>> On Tue, Oct 13, 2009 at 3:40 AM, <LoganLi@xxxxxxxxxxxxxx> wrote: >>> >> >> > What is the problem, specifically? >>> >> >> >>> >> >> With the latest patch I do get the optical output lighting >>> >> up and the >>> >> >> receiver detects a PCM signal, but it seems to be just >>> >> silence coming >>> >> >> through. (In previous iterations the SPDIF digital converter wasn't >>> >> >> being enabled automatically so it didn't get even that far.) >>> >> > >>> >> > You can fiddle with hda-verb to issue digital-converter verbs. >>> >> > Possibly you need to flip the digital-enable bit to send >>> >> the values... >>> >> >>> >> Well, I think I tried all combinations of the flags on the digital >>> >> converter in hda_analyzer without any luck. I'm assuming it's >>> >> something else (presumably codec-specific) that hda_analyzer doesn't >>> >> know about.. >>> >> >>> > >>> > Hi, Robert >>> > We cannot duplicate bug of SPDIF Out cannot work on VT1828S board. >>> > You said it's fine in Windows, right? >>> >>> Ahh, I see the problem. I think it's related to what we were talking >>> about with the second SPDIF output: If I play back on subdevice 1 I >>> don't get any output. But if I force playing on substream 1 instead of >>> the default 0 (i.e. hw:0,1,1) then I get audio. I'm assuming that >>> substream 0 is the codec's HDMI output (which actually doesn't exist >>> on this motherboard). >>> >>> It appears whether or not the "iec958" alias that PulseAudio uses when >>> selecting "Output Digital Stereo" profile actually ends up using >>> substream 1 instead of 0 is based on luck. as it sometimes works and >>> sometimes doesn't. Having different substreams go different places is >>> pretty non-intuitive and it seems software doesn't expect this >>> behavior. I think that the SPDIF and HDMI outputs really should be >>> separate subdevices (i.e. hw:0,1 and hw:0,2 or something) instead, >>> unless something makes this impossible. If the aliases for iec958 and >>> hdmi were set up to point to the correct subdevice then everything >>> would work as it should.. >> >> Yes, it's possible to assign two different devices if the pin-config >> of each digital output is set up properly for SPDIF and HDMI. >> It won't be too difficult to fix, but I have little time now. > > Actually, I just checked the version of patch_via.c that's in the > sound git tree and it doesn't seem to have this problem with SPDIF > output. (I believe the version I was using had one of the second-SPDIF > patches that was dropped.) There are still 2 substreams it appears, > but both seem to output to SPDIF.. Another followup: I've seen the following in dmesg: hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. ALSA sound/pci/hda/hda_intel.c:683: No response from codec, disabling MSI: last cmd=0x024f0c00 ALSA sound/pci/hda/hda_intel.c:698: azx_get_response timeout, switching to polling mode: last cmd=0x024f0c00 Any way to tell what was going on here? _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
