Re: [alsa-devel] Bug in setting channels, related to recent ELD/EDID changes?
(restored CC I removed, sorry about that)
On 11.01.2011 09:15, Takashi Iwai wrote:
At Mon, 10 Jan 2011 21:36:10 +0100, Takashi Iwai wrote:
At Mon, 10 Jan 2011 21:58:26 +0200, Anssi Hannula wrote:
Takashi Iwai kirjoitti:
At Sun, 02 Jan 2011 12:16:44 +0200, Anssi Hannula wrote:
Hi!
Takashi, it seems the "allow all when not plugged in" behaviour you implemented in bbbe3390 is not enough to allow applications to open the device before the output device is ready. Switched-off A/V receivers may provide the information of the plugged-in television which usually restricts the max_channels to 2, causing applications to fail opening the device with more channels when a the A/V receiver is switched off.
Also, even if the application can gracefully fallback to stereo, AFAIK there is no method for an application to get informed when the limitation is lifted, so it can't automatically resume multichannel output when the A/V receiver is switched on again.
Based on this info, I guess the restrictions based on ELD should be removed :/ Unless you have some other ideas to fix the issue, of course.
What about the patch below? If it's unplugged, the valid flag should be cleared, so the next open fall backs to the default state (i.e. allows all).
But it is not unplugged. The multichannel-capable receiver forwards EDID of TV which doesn't allow more than 2 channels, when the receiver is swtiched off.
Well, in that case, this is the correct behavior, IMO. At this moment, setting channels to 2 is the right thing. Then, how can you know that more channels will be available in future at all?
What you want to have a static configuration way by ignoring the ELD information. But, the interface isn't pretty easy if it's implemented in control API, I suppose.
... or, maybe an easier option is to use the module parameter like the patch below. It can be changed dynamically via sysfs as well.
Better than nothing I guess.
Note that the condition is backwards in the below patch :)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index d1b1b57..4115a39 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -31,10 +31,14 @@ #include <linux/init.h> #include <linux/delay.h> #include <linux/slab.h> +#include <linux/moduleparam.h> #include <sound/core.h> #include "hda_codec.h" #include "hda_local.h"
+static bool static_hdmi_pcm; +module_param(static_hdmi_pcm, bool, 0644);
/*
- The HDMI/DisplayPort configuration can be highly dynamic. A graphics device
- could support two independent pipes, each of them can be connected to one or
@@ -827,7 +831,7 @@ static int hdmi_pcm_open(struct hda_pcm_stream *hinfo, *codec_pars = *hinfo;
eld = &spec->sink_eld[idx];
- if (eld->sad_count > 0) {
- if (static_hdmi_pcm && eld->sad_count > 0) { hdmi_eld_update_pcm_info(eld, hinfo, codec_pars); if (hinfo->channels_min > hinfo->channels_max || !hinfo->rates || !hinfo->formats)
At Tue, 11 Jan 2011 18:58:51 +0200, Anssi Hannula wrote:
(restored CC I removed, sorry about that)
On 11.01.2011 09:15, Takashi Iwai wrote:
At Mon, 10 Jan 2011 21:36:10 +0100, Takashi Iwai wrote:
At Mon, 10 Jan 2011 21:58:26 +0200, Anssi Hannula wrote:
Takashi Iwai kirjoitti:
At Sun, 02 Jan 2011 12:16:44 +0200, Anssi Hannula wrote:
Hi!
Takashi, it seems the "allow all when not plugged in" behaviour you implemented in bbbe3390 is not enough to allow applications to open the device before the output device is ready. Switched-off A/V receivers may provide the information of the plugged-in television which usually restricts the max_channels to 2, causing applications to fail opening the device with more channels when a the A/V receiver is switched off.
Also, even if the application can gracefully fallback to stereo, AFAIK there is no method for an application to get informed when the limitation is lifted, so it can't automatically resume multichannel output when the A/V receiver is switched on again.
Based on this info, I guess the restrictions based on ELD should be removed :/ Unless you have some other ideas to fix the issue, of course.
What about the patch below? If it's unplugged, the valid flag should be cleared, so the next open fall backs to the default state (i.e. allows all).
But it is not unplugged. The multichannel-capable receiver forwards EDID of TV which doesn't allow more than 2 channels, when the receiver is swtiched off.
Well, in that case, this is the correct behavior, IMO. At this moment, setting channels to 2 is the right thing. Then, how can you know that more channels will be available in future at all?
What you want to have a static configuration way by ignoring the ELD information. But, the interface isn't pretty easy if it's implemented in control API, I suppose.
... or, maybe an easier option is to use the module parameter like the patch below. It can be changed dynamically via sysfs as well.
Better than nothing I guess.
Note that the condition is backwards in the below patch :)
Oh yeah. I applied the fixed patch to sound git tree now.
thanks,
Takashi
First, THANK YOU for addressing this! However, I have a couple questions. Which solution was implemented; a true/false switch controlling the behavior between the old _working_ method, or the new ELD restricted one? Or, this module parameter thing that was mentioned?
As a user having to deal with the frustration of this problem, I absolutely think the true/false switch is the best solution as it's set-and-forget. Set it one time, get the behavior you _want_, and not have to bother with it again. With the module parameter thing, it sounds like you have to change module parameters according to what you want at the moment. Or is it that the true/false switch is controlled by a module param? Maybe I've misinterpreted it but it's not very clear.
So I grab alsa git, but how do I use the fix to restore the old behavior?
Thanks, Derek
On 11.01.2011 22:37, VDR User wrote:
First, THANK YOU for addressing this! However, I have a couple questions. Which solution was implemented; a true/false switch controlling the behavior between the old _working_ method, or the new ELD restricted one? Or, this module parameter thing that was mentioned?
As a user having to deal with the frustration of this problem, I absolutely think the true/false switch is the best solution as it's set-and-forget. Set it one time, get the behavior you _want_, and not have to bother with it again. With the module parameter thing, it sounds like you have to change module parameters according to what you want at the moment. Or is it that the true/false switch is controlled by a module param? Maybe I've misinterpreted it but it's not very clear.
Yes, it is a true/false switch controlled by a module parameter.
So I grab alsa git, but how do I use the fix to restore the old behavior?
Set the module parameter static_hdmi_pcm of snd-hda-codec-hdmi to 1.
For example, by adding this into /etc/modprobe.conf: options snd-hda-codec-hdmi static_hdmi_pcm=1
For the record, this is the commit: http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commitdiff;h...
On Tue, Jan 11, 2011 at 12:47 PM, Anssi Hannula anssi.hannula@iki.fi wrote:
As a user having to deal with the frustration of this problem, I absolutely think the true/false switch is the best solution as it's set-and-forget. Set it one time, get the behavior you _want_, and not have to bother with it again. With the module parameter thing, it sounds like you have to change module parameters according to what you want at the moment. Or is it that the true/false switch is controlled by a module param? Maybe I've misinterpreted it but it's not very clear.
Yes, it is a true/false switch controlled by a module parameter.
So I grab alsa git, but how do I use the fix to restore the old behavior?
Set the module parameter static_hdmi_pcm of snd-hda-codec-hdmi to 1.
For example, by adding this into /etc/modprobe.conf: options snd-hda-codec-hdmi static_hdmi_pcm=1
Got it, thanks for clearing that up. I've been testing it with the most recent stable kernel (2.6.37) and it seems to be working fine so that's great news! One last question, will this fix make it into the 2.6.37.x kernel tree or will it be 2.6.38?
Thanks for the help guys!
At Tue, 11 Jan 2011 22:37:49 -0800, VDR User wrote:
On Tue, Jan 11, 2011 at 12:47 PM, Anssi Hannula anssi.hannula@iki.fi wrote:
As a user having to deal with the frustration of this problem, I absolutely think the true/false switch is the best solution as it's set-and-forget. Set it one time, get the behavior you _want_, and not have to bother with it again. With the module parameter thing, it sounds like you have to change module parameters according to what you want at the moment. Or is it that the true/false switch is controlled by a module param? Maybe I've misinterpreted it but it's not very clear.
Yes, it is a true/false switch controlled by a module parameter.
So I grab alsa git, but how do I use the fix to restore the old behavior?
Set the module parameter static_hdmi_pcm of snd-hda-codec-hdmi to 1.
For example, by adding this into /etc/modprobe.conf: options snd-hda-codec-hdmi static_hdmi_pcm=1
Got it, thanks for clearing that up. I've been testing it with the most recent stable kernel (2.6.37) and it seems to be working fine so that's great news! One last question, will this fix make it into the 2.6.37.x kernel tree or will it be 2.6.38?
I marked the patches with Cc to stable now, so they'll be forwarded to stable kernel once after they get merged to the upstream.
thanks,
Takashi
On Tue, Jan 11, 2011 at 12:47 PM, Anssi Hannula anssi.hannula@iki.fi wrote:
First, THANK YOU for addressing this! However, I have a couple questions. Which solution was implemented; a true/false switch controlling the behavior between the old _working_ method, or the new ELD restricted one? Or, this module parameter thing that was mentioned?
As a user having to deal with the frustration of this problem, I absolutely think the true/false switch is the best solution as it's set-and-forget. Set it one time, get the behavior you _want_, and not have to bother with it again. With the module parameter thing, it sounds like you have to change module parameters according to what you want at the moment. Or is it that the true/false switch is controlled by a module param? Maybe I've misinterpreted it but it's not very clear.
Yes, it is a true/false switch controlled by a module parameter.
So I grab alsa git, but how do I use the fix to restore the old behavior?
Set the module parameter static_hdmi_pcm of snd-hda-codec-hdmi to 1.
For example, by adding this into /etc/modprobe.conf: options snd-hda-codec-hdmi static_hdmi_pcm=1
For the record, this is the commit: http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commitdiff;h...
This appears to not be working properly. Here are the test results:
cold boot pc, kernel 2.6.34.7, alsa kernel drivers, receiver off eld shows 2 channel stereo (from tv) available vdr tuned to hdtv with 5.1 surround audio: no errors from alsa, surround channels missing vdr tuned to hdtv with 5.1 surround audio, receiver turned on: no errors from alsa, surround channels working
cold boot pc, kernel 2.6.37, alsa snapshot drivers jan.22,2010, receiver off eld shows 2 channel stereo (from tv) available options snd-hda-codec-hdmi static_hdmi_pcm=1 vdr tuned to hdtv with 5.1 surround audio: no errors from alsa, some surround channels missing vdr tuned to hdtv with 5.1 surround audio, receiver turned on: no errors from alsa, some surround channels missing
cold boot pc, kernel 2.6.37, alsa snapshot drivers jan.22,2010, receiver on eld shows 8 channels (7.1) available vdr tuned to hdtv with 5.1 surround audio: no errors from alsa, some surround channels missing vdr tuned to hdtv with 5.1 surround audio, receiver turned on: no errors from alsa, some surround channels missing
The HD content I was using was the movie Watchmen. In all cases where "some surround channels missing", it was at a minimum whatever channel(s) carry the main audio for the talking/spoken dialog. All (as far as I know, but could be wrong) the background audio seemed to be present.
Could someone please take a look at the workaround patch. The new "static_hdmi_pcm" parameter when set to 1 is supposed to mimic the original alsa behavior prior to this eld restriction stuff being added but the patch appears to somehow have broken surround sound as described above.
Thanks for your help resolving this very frustrating problem! Derek
At Fri, 21 Jan 2011 18:53:31 -0800, VDR User wrote:
On Tue, Jan 11, 2011 at 12:47 PM, Anssi Hannula anssi.hannula@iki.fi wrote:
First, THANK YOU for addressing this! However, I have a couple questions. Which solution was implemented; a true/false switch controlling the behavior between the old _working_ method, or the new ELD restricted one? Or, this module parameter thing that was mentioned?
As a user having to deal with the frustration of this problem, I absolutely think the true/false switch is the best solution as it's set-and-forget. Set it one time, get the behavior you _want_, and not have to bother with it again. With the module parameter thing, it sounds like you have to change module parameters according to what you want at the moment. Or is it that the true/false switch is controlled by a module param? Maybe I've misinterpreted it but it's not very clear.
Yes, it is a true/false switch controlled by a module parameter.
So I grab alsa git, but how do I use the fix to restore the old behavior?
Set the module parameter static_hdmi_pcm of snd-hda-codec-hdmi to 1.
For example, by adding this into /etc/modprobe.conf: options snd-hda-codec-hdmi static_hdmi_pcm=1
For the record, this is the commit: http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commitdiff;h...
This appears to not be working properly. Here are the test results:
cold boot pc, kernel 2.6.34.7, alsa kernel drivers, receiver off eld shows 2 channel stereo (from tv) available vdr tuned to hdtv with 5.1 surround audio: no errors from alsa, surround channels missing vdr tuned to hdtv with 5.1 surround audio, receiver turned on: no errors from alsa, surround channels working
cold boot pc, kernel 2.6.37, alsa snapshot drivers jan.22,2010, receiver off eld shows 2 channel stereo (from tv) available options snd-hda-codec-hdmi static_hdmi_pcm=1 vdr tuned to hdtv with 5.1 surround audio: no errors from alsa, some surround channels missing vdr tuned to hdtv with 5.1 surround audio, receiver turned on: no errors from alsa, some surround channels missing
cold boot pc, kernel 2.6.37, alsa snapshot drivers jan.22,2010, receiver on eld shows 8 channels (7.1) available vdr tuned to hdtv with 5.1 surround audio: no errors from alsa, some surround channels missing vdr tuned to hdtv with 5.1 surround audio, receiver turned on: no errors from alsa, some surround channels missing
The HD content I was using was the movie Watchmen. In all cases where "some surround channels missing", it was at a minimum whatever channel(s) carry the main audio for the talking/spoken dialog. All (as far as I know, but could be wrong) the background audio seemed to be present.
Could someone please take a look at the workaround patch. The new "static_hdmi_pcm" parameter when set to 1 is supposed to mimic the original alsa behavior prior to this eld restriction stuff being added but the patch appears to somehow have broken surround sound as described above.
Could you put printk() appropriately for showing which values are requested and which runtime->hw values are actually set for each working and non-working case?
Takashi
participants (3)
-
Anssi Hannula -
Takashi Iwai -
VDR User