> -----Original Message----- > From: Robert Hancock [mailto:hancockrwd@xxxxxxxxx] > Sent: Tuesday, October 13, 2009 10:41 AM > To: Takashi Iwai > Cc: Logan Li; alsa-devel@xxxxxxxxxxxxxxxx; 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@xxxxxxx> 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@xxxxxxx> 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? _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
