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

[LoganLi at viatech.com.cn]

> -----Original Message-----
> From: Robert Hancock [mailto:hancockrwd at gmail.com] 
> Sent: Tuesday, October 13, 2009 10:41 AM
> To: Takashi Iwai
> Cc: Logan Li; alsa-devel at alsa-project.org; Lydia Wang; Harald Welte
> Subject: Re: [PATCH 0/30] ALSA: HDA VIA: patch series
> 
> On Sun, Oct 11, 2009 at 11:29 PM, Takashi Iwai <tiwai at suse.de> wrote:
> > At Sun, 11 Oct 2009 13:51:28 -0600,
> > Robert Hancock wrote:
> >>
> >> On 10/11/2009 01:27 PM, Takashi Iwai wrote:
> >> > At Sun, 11 Oct 2009 10:56:48 -0600,
> >> > Robert Hancock wrote:
> >> >>
> >> >> On Sun, Oct 11, 2009 at 10:18 AM, Takashi 
> Iwai<tiwai at suse.de>  wrote:
> >> >>> At Sat, 10 Oct 2009 19:07:09 +0800,
> >> >>> Logan Li wrote:
> >> >>>>
> >> >>>> Following patch series mainly includes:
> >> >>>>   - support VT1718S, VT2002P, VT1812S, VT1716S, ...
> >> >>>>   - support smart 5.1
> >> >>>>   - add jack detection for VT1708
> >> >>>>   - power saving functions
> >> >>>
> >> >>> Thanks for the patches.  They are all well formatted now.
> >> >>>
> >> >>> I applied your patches except for 17,
> >> >>>         ALSA: HDA VIA: Add 2nd S/PDIF out for VT1708S 
> and VT1702
> >> >>> as Robert reported a regression.
> >> >>>
> >> >>> This is likely because of the behavior change by this 
> patch.  Now
> >> >>> the second SPDIF has to be specified manually with the explicit
> >> >>> substream number.  This itself is fine, but I see the 
> problem with
> >> >>> pulseaudio, for example.  There is no good way to 
> specify this substream
> >> >>> automatically for PA with some symbols like "spdif" or "hdmi".
> >> >>>
> >> >>> This is basically a problem of the current ALSA core 
> and HD-audio core
> >> >>> implementation.  So, we should solve all together.
> >> >>
> >> >> Actually, the latest posted version didn't have the 
> mixer problem I
> >> >> had before (I haven't looked in detail at what was 
> different). But I
> >> >> agree using a different substream for a different 
> output isn't ideal
> >> >> since there's no way for software to detect that this 
> is the case. Can
> >> >> it be a separate PCM like hw:0,2 or something?
> >> >
> >> > It would work like hw:0,1,1.  But, this is exactly what 
> I mentioned in
> >> > the above.  The secondary SPDIF isn't specified as an intuitively
> >> > selectable PCM device.
> >>
> >> Well, if it was its own subdevice like hw:0,2 it would 
> have some hope of
> >> being detected by HAL, PulseAudio, etc. If it's just a 
> substream then I
> >> don't think that software can actually tell it's a 
> separate output and
> >> not just a HW mixing-type stream, etc.
> >
> > Right, that's the missing information.
> >
> >> >> Hopefully VIA will also look into the SPDIF no-output 
> problem I have
> >> >> with VT1828S..
> >> >
> >> > 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?
  About the 48k limit, I'll send a patch to remove it later, thank you for review!

Hi, Takashi
  So need I modify 2nd S/PDIF as separate PCM?