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

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

[Logan Li]

Following patch series mainly includes:
 - support VT1718S, VT2002P, VT1812S, VT1716S, ...
 - support smart 5.1
 - add jack detection for VT1708
 - power saving functions

Re: [PATCH 0/30] ALSA: HDA VIA: patch series

[Robert Hancock]

On Sat, Oct 10, 2009 at 5:07 AM, Logan Li <loganli@viatech.com.cn> wrote:
> Following patch series mainly includes:
>  - support VT1718S, VT2002P, VT1812S, VT1716S, ...
>  - support smart 5.1
>  - add jack detection for VT1708
>  - power saving functions

OK, this patch set fixes the problem with being unable to open the
mixer, and it looks like the SPDIF digital converter entries are being
enabled automatically so I get a signal indication on my receiver.
Still not getting any actual SPDIF audio through the receiver though,
unfortunately. Also it appears that the 48000 fixed sample rate limit
for SPDIF outputs is still there for the newly added codec types, I'd
say it should be removed for them as well..

Re: [PATCH 0/30] ALSA: HDA VIA: patch series

[Takashi Iwai]

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.

On most machines, it's not too big deal to have it the secondary digital
as a slave.  If this really matters, we can add another hint to make
the individual digital substreams conditionally.

Anyway, please check the latest sound GIT tree (or alsa-driver snapshot)
whether it works.  I only tested the compilation, so far.


thanks,

Takashi

Re: [PATCH 0/30] ALSA: HDA VIA: patch series

[Robert Hancock]

On Sun, Oct 11, 2009 at 10:18 AM, Takashi Iwai <tiwai@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?

Hopefully VIA will also look into the SPDIF no-output problem I have
with VT1828S..

>
> On most machines, it's not too big deal to have it the secondary digital
> as a slave.  If this really matters, we can add another hint to make
> the individual digital substreams conditionally.
>
> Anyway, please check the latest sound GIT tree (or alsa-driver snapshot)
> whether it works.  I only tested the compilation, so far.
>
>
> thanks,
>
> Takashi
>

Re: [PATCH 0/30] ALSA: HDA VIA: patch series

[Takashi Iwai]

At Sun, 11 Oct 2009 10:56:48 -0600,
Robert Hancock wrote:
> 
> On Sun, Oct 11, 2009 at 10:18 AM, Takashi Iwai <tiwai@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.

> Hopefully VIA will also look into the SPDIF no-output problem I have
> with VT1828S..

What is the problem, specifically?


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 0/30] ALSA: HDA VIA: patch series

[Robert Hancock]

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@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.

>
>> 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.)

Re: [PATCH 0/30] ALSA: HDA VIA: patch series

[Takashi Iwai]

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@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...


thanks,

Takashi

Re: [PATCH 0/30] ALSA: HDA VIA: patch series

[Robert Hancock]

On Sun, Oct 11, 2009 at 11:29 PM, Takashi Iwai <tiwai@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@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..

Re: [PATCH 0/30] ALSA: HDA VIA: patch series

[LoganLi]

> -----Original Message-----
> From: Robert Hancock [mailto:hancockrwd@gmail.com] 
> Sent: Tuesday, October 13, 2009 10:41 AM
> To: Takashi Iwai
> Cc: Logan Li; alsa-devel@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@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@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?

Re: [PATCH 0/30] ALSA: HDA VIA: patch series

[Takashi Iwai]

At Tue, 13 Oct 2009 17:40:48 +0800,
<LoganLi@viatech.com.cn> wrote:
> 
> > -----Original Message-----
> > From: Robert Hancock [mailto:hancockrwd@gmail.com] 
> > Sent: Tuesday, October 13, 2009 10:41 AM
> > To: Takashi Iwai
> > Cc: Logan Li; alsa-devel@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@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@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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 0/30] ALSA: HDA VIA: patch series

[Robert Hancock]

On Tue, Oct 13, 2009 at 3:40 AM,  <LoganLi@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..

Re: [PATCH 0/30] ALSA: HDA VIA: patch series

[Takashi Iwai]

At Tue, 13 Oct 2009 21:52:02 -0600,
Robert Hancock wrote:
> 
> On Tue, Oct 13, 2009 at 3:40 AM,  <LoganLi@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.

BTW, I'll be off from tomorrow for a while (two weeks) to attend
conferences in Tokyo and a few days battery-charging there.
So replies will be delayed.


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 0/30] ALSA: HDA VIA: patch series

[Robert Hancock]

On Wed, Oct 14, 2009 at 9:45 AM, Takashi Iwai <tiwai@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@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..

Re: [PATCH 0/30] ALSA: HDA VIA: patch series

[Robert Hancock]

On Wed, Oct 14, 2009 at 9:24 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
> On Wed, Oct 14, 2009 at 9:45 AM, Takashi Iwai <tiwai@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@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?