[alsa-devel] [PATCH 0/30] ALSA: HDA VIA: patch series

[Robert Hancock]

On Wed, Oct 14, 2009 at 9:24 PM, Robert Hancock <hancockrwd at gmail.com> wrote:
> On Wed, Oct 14, 2009 at 9:45 AM, Takashi Iwai <tiwai at suse.de> wrote:
>> At Tue, 13 Oct 2009 21:52:02 -0600,
>> Robert Hancock wrote:
>>>
>>> On Tue, Oct 13, 2009 at 3:40 AM,  <LoganLi at viatech.com.cn> 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?