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

[Takashi Iwai]

At Tue, 13 Oct 2009 17:40:48 +0800,
<LoganLi at viatech.com.cn> wrote:
> 
> > -----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?

Well, currently the individual secondary SPDIF is a basic problem,
and isn't so easily solvable in the codec-specific way.
We can have PCM substreams, but it's not exposed explicitly as
really individual substreams, not the mixed one.  So, this is a mixed
issue between the driver and the user-space API.

Some ideas are in my mind to extend the information query, but I've
been busy for other tasks, it's been postponed.


thanks,

Takashi