[alsa-devel] [PATCH 0/30] ALSA: HDA VIA: patch series
Following patch series mainly includes: - support VT1718S, VT2002P, VT1812S, VT1716S, ... - support smart 5.1 - add jack detection for VT1708 - power saving functions
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..
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
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
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
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 Iwaitiwai@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.)
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 Iwaitiwai@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
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 Iwaitiwai@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..
-----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
Iwaitiwai@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?
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
Iwaitiwai@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
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..
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
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..
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?
participants (4)
-
Logan Li -
LoganLi＠viatech.com.cn
-
Robert Hancock -
Takashi Iwai