Bug in setting channels, related to recent ELD/EDID changes?

Bug in setting channels, related to recent ELD/EDID changes?

[VDR User]

Hi.  After updating my stable kernel from 2.6.35.7 to 2.6.36.2, I get
a problem when tuning HDTV channels that use surround sound.  The
error I get is as follows:

audio_alsa_out: Cannot set number of channels to 6 (err=-22:Invalid argument)
audio_out: open failed!

With the following xine error:
---------------------- (ERROR) ----------------------
The audio device is unavailable. Please verify if another program
already uses it.

['Audio device unavailable' '']
------------------ (END OF ERROR) -------------------

This problem did not exist in 2.6.35.7 alsa drivers (using
snd-hda-intel).  I have noticed that there has been recent changes
associated with ELD/EDID that sets limitations on channels.  First of
all I think this is a horrible idea since many devices don't even
contain correct EDID.  It's simply too unreliable to use.  Secondly,
could the above problem be related to those changes?

If anyone knows a fix for this or can point me in the right direction
(aside of going back to 2.6.35.7), PLEASE fill me in.

Here are some system specs:
debian testing
kernel snd-hda-intel driver used for hdmi audio on nvidia gt240 video card
hdmi going to 7.1 surround sound receiver & setup

Any help is greatly appreciated!

Best regards,
Derek

Re: Bug in setting channels, related to recent ELD/EDID changes?

[Anssi Hannula]

On 23.12.2010 04:22, VDR User wrote:
> Hi.  After updating my stable kernel from 2.6.35.7 to 2.6.36.2, I get
> a problem when tuning HDTV channels that use surround sound.  The
> error I get is as follows:
> 
> audio_alsa_out: Cannot set number of channels to 6 (err=-22:Invalid argument)
> audio_out: open failed!
> 
> With the following xine error:
> ---------------------- (ERROR) ----------------------
> The audio device is unavailable. Please verify if another program
> already uses it.
> 
> ['Audio device unavailable' '']
> ------------------ (END OF ERROR) -------------------

What are the contents of /proc/asound/NVidia/eld* and
/proc/asound/NVidia/codec* ?

> This problem did not exist in 2.6.35.7 alsa drivers (using
> snd-hda-intel).  I have noticed that there has been recent changes
> associated with ELD/EDID that sets limitations on channels.  First of
> all I think this is a horrible idea since many devices don't even
> contain correct EDID.  It's simply too unreliable to use.

Well, I haven't yet seen any EDID which contained incorrect audio
information. Also, in case we find no information in the ELD, all
channels and formats are allowed.

> Secondly,
> could the above problem be related to those changes?

It could.

> If anyone knows a fix for this or can point me in the right direction
> (aside of going back to 2.6.35.7), PLEASE fill me in.
> 
> Here are some system specs:
> debian testing
> kernel snd-hda-intel driver used for hdmi audio on nvidia gt240 video card
> hdmi going to 7.1 surround sound receiver & setup
> 
> Any help is greatly appreciated!
> 
> Best regards,
> Derek


-- 
Anssi Hannula

Re: Bug in setting channels, related to recent ELD/EDID changes?

[VDR User]

On Wed, Dec 22, 2010 at 9:48 PM, Anssi Hannula <anssi.hannula@iki.fi> wrote:
> On 23.12.2010 04:22, VDR User wrote:
>> Hi.  After updating my stable kernel from 2.6.35.7 to 2.6.36.2, I get
>> a problem when tuning HDTV channels that use surround sound.  The
>> error I get is as follows:
>>
>> audio_alsa_out: Cannot set number of channels to 6 (err=-22:Invalid argument)
>> audio_out: open failed!
>>
>> With the following xine error:
>> ---------------------- (ERROR) ----------------------
>> The audio device is unavailable. Please verify if another program
>> already uses it.
>>
>> ['Audio device unavailable' '']
>> ------------------ (END OF ERROR) -------------------
>
> What are the contents of /proc/asound/NVidia/eld* and
> /proc/asound/NVidia/codec* ?

Booted into 2.6.35.7 with receiver ON:
$ cat /proc/asound/NVidia_1/eld*
monitor_present         1
eld_valid               1
monitor_name            SONY AVAMP

connection_type         HDMI
eld_version             [0x2] CEA-861D or below
edid_version            [0x3] CEA-861-B, C or D
manufacture_id          0xd94d
product_id              0xfb01
port_id                 0x20000
support_hdcp            0
support_ai              0
audio_sync_delay        0
speakers                [0x5f] FL/FR LFE FC RL/RR RC RLC/RRC
sad_count               6
sad0_coding_type        [0x1] LPCM
sad0_channels           2
sad0_rates              [0x1ee0] 44100 48000 88200 176400 192000 384000
sad0_bits               [0xe0000] 16 20 24
sad1_coding_type        [0x1] LPCM
sad1_channels           6
sad1_rates              [0x1ee0] 44100 48000 88200 176400 192000 384000
sad1_bits               [0xe0000] 16 20 24
sad2_coding_type        [0x1] LPCM
sad2_channels           8
sad2_rates              [0x1ee0] 44100 48000 88200 176400 192000 384000
sad2_bits               [0xe0000] 16 20 24
sad3_coding_type        [0x2] AC-3
sad3_channels           6
sad3_rates              [0xe0] 44100 48000 88200
sad3_max_bitrate        680000
sad4_coding_type        [0x7] DTS
sad4_channels           6
sad4_rates              [0x6e0] 44100 48000 88200 176400 192000
sad4_max_bitrate        1536000
sad5_coding_type        [0xa] E-AC-3/DD+ (Dolby Digital Plus)
sad5_channels           8
sad5_rates              [0xc0] 48000 88200

Booted into 2.6.35.7 with receiver OFF:
$ cat /proc/asound/NVidia_1/eld*
monitor_present         1
eld_valid               1
monitor_name            SONY AVAMP

connection_type         HDMI
eld_version             [0x2] CEA-861D or below
edid_version            [0x3] CEA-861-B, C or D
manufacture_id          0xd94d
product_id              0xfb01
port_id                 0x20000
support_hdcp            0
support_ai              0
audio_sync_delay        0
speakers                [0xffff] FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC
FLW/FRW FLH/FRH TC FCH
sad_count               1
sad0_coding_type        [0x1] LPCM
sad0_channels           2
sad0_rates              [0xe0] 44100 48000 88200
sad0_bits               [0x20000] 16

$ cat /proc/asound/NVidia_1/codec*
Codec: Nvidia GPU 0a HDMI/DP
Address: 1
Function Id: 0x1
Vendor Id: 0x10de000a
Subsystem Id: 0x10de0101
Revision Id: 0x100100
No Modem Function Group found
Default PCM:
    rates [0x0]:
    bits [0x0]:
    formats [0x0]:
Default Amp-In caps: N/A
Default Amp-Out caps: N/A
GPIO: io=0, o=0, i=0, unsolicited=0, wake=0
Node 0x04 [Audio Output] wcaps 0x72b1: 8-Channels Digital Stripe CP
  Control: name="IEC958 Playback Con Mask", index=0, device=0
  Control: name="IEC958 Playback Pro Mask", index=0, device=0
  Control: name="IEC958 Playback Default", index=0, device=0
  Control: name="IEC958 Playback Switch", index=0, device=0
  Device: name="NVIDIA HDMI", type="HDMI", device=3
  Converter: stream=6, channel=0
  Digital: Enabled
  Digital category: 0x0
  PCM:
    rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000
    bits [0xe]: 16 20 24
    formats [0x5]: PCM AC3
  Unsolicited: tag=00, enabled=0
Node 0x05 [Pin Complex] wcaps 0x407381: 8-Channels Digital CP
  Pincap 0x09000094: OUT Detect HBR HDMI DP
  Pin Default 0x18560010: [Jack] Digital Out at Int HDMI
    Conn = Digital, Color = Unknown
    DefAssociation = 0x1, Sequence = 0x0
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=05, enabled=1
  Connection: 1
     0x04

I'm certain at the time I experienced this error, my receiver was
turned off, could this be the cause of the error?  If so, this really
needs to be fixed/reworked as many people don't have their receivers
on (to save power usage, noise, etc) unless they specifically
need/want it.  In the event a receiver is off and the user is trying
to watch something that requires more then 2 channels, he should
either turn the receiver on, or adjust the speaker arrangement in xine
to stereo -- however, what should not happen is the alsa driver
failing.  Maybe a better solution would be to log an error to syslog
or something rather then the driver itself returning an error?

Best regards,
Derek
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Bug in setting channels, related to recent ELD/EDID changes?

[Anssi Hannula]

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.


On 23.12.2010 09:13, VDR User wrote:
> On Wed, Dec 22, 2010 at 9:48 PM, Anssi Hannula <anssi.hannula@iki.fi> wrote:
>> On 23.12.2010 04:22, VDR User wrote:
>>> Hi.  After updating my stable kernel from 2.6.35.7 to 2.6.36.2, I get
>>> a problem when tuning HDTV channels that use surround sound.  The
>>> error I get is as follows:
>>>
>>> audio_alsa_out: Cannot set number of channels to 6 (err=-22:Invalid argument)
>>> audio_out: open failed!
>>>
>>> With the following xine error:
>>> ---------------------- (ERROR) ----------------------
>>> The audio device is unavailable. Please verify if another program
>>> already uses it.
>>>
>>> ['Audio device unavailable' '']
>>> ------------------ (END OF ERROR) -------------------
>>
>> What are the contents of /proc/asound/NVidia/eld* and
>> /proc/asound/NVidia/codec* ?
> 
> Booted into 2.6.35.7 with receiver ON:
> $ cat /proc/asound/NVidia_1/eld*
> monitor_present         1
> eld_valid               1
> monitor_name            SONY AVAMP
> 
> connection_type         HDMI
> eld_version             [0x2] CEA-861D or below
> edid_version            [0x3] CEA-861-B, C or D
> manufacture_id          0xd94d
> product_id              0xfb01
> port_id                 0x20000
> support_hdcp            0
> support_ai              0
> audio_sync_delay        0
> speakers                [0x5f] FL/FR LFE FC RL/RR RC RLC/RRC
> sad_count               6
> sad0_coding_type        [0x1] LPCM
> sad0_channels           2
> sad0_rates              [0x1ee0] 44100 48000 88200 176400 192000 384000
> sad0_bits               [0xe0000] 16 20 24
> sad1_coding_type        [0x1] LPCM
> sad1_channels           6
> sad1_rates              [0x1ee0] 44100 48000 88200 176400 192000 384000
> sad1_bits               [0xe0000] 16 20 24
> sad2_coding_type        [0x1] LPCM
> sad2_channels           8
> sad2_rates              [0x1ee0] 44100 48000 88200 176400 192000 384000
> sad2_bits               [0xe0000] 16 20 24
> sad3_coding_type        [0x2] AC-3
> sad3_channels           6
> sad3_rates              [0xe0] 44100 48000 88200
> sad3_max_bitrate        680000
> sad4_coding_type        [0x7] DTS
> sad4_channels           6
> sad4_rates              [0x6e0] 44100 48000 88200 176400 192000
> sad4_max_bitrate        1536000
> sad5_coding_type        [0xa] E-AC-3/DD+ (Dolby Digital Plus)
> sad5_channels           8
> sad5_rates              [0xc0] 48000 88200
> 
> Booted into 2.6.35.7 with receiver OFF:
> $ cat /proc/asound/NVidia_1/eld*
> monitor_present         1
> eld_valid               1
> monitor_name            SONY AVAMP
> 
> connection_type         HDMI
> eld_version             [0x2] CEA-861D or below
> edid_version            [0x3] CEA-861-B, C or D
> manufacture_id          0xd94d
> product_id              0xfb01
> port_id                 0x20000
> support_hdcp            0
> support_ai              0
> audio_sync_delay        0
> speakers                [0xffff] FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC
> FLW/FRW FLH/FRH TC FCH
> sad_count               1
> sad0_coding_type        [0x1] LPCM
> sad0_channels           2
> sad0_rates              [0xe0] 44100 48000 88200
> sad0_bits               [0x20000] 16
> 
> I'm certain at the time I experienced this error, my receiver was
> turned off, could this be the cause of the error?  If so, this really
> needs to be fixed/reworked as many people don't have their receivers
> on (to save power usage, noise, etc) unless they specifically
> need/want it.  In the event a receiver is off and the user is trying
> to watch something that requires more then 2 channels, he should
> either turn the receiver on, or adjust the speaker arrangement in xine
> to stereo -- however, what should not happen is the alsa driver
> failing.  Maybe a better solution would be to log an error to syslog
> or something rather then the driver itself returning an error?

A/V receivers showing TV information is indeed something that wasn't
thought about :(

-- 
Anssi Hannula

Re: Bug in setting channels, related to recent ELD/EDID changes?

[VDR User]

On Sun, Jan 2, 2011 at 2:16 AM, Anssi Hannula <anssi.hannula@iki.fi> 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.
>
>
> On 23.12.2010 09:13, VDR User wrote:
>> On Wed, Dec 22, 2010 at 9:48 PM, Anssi Hannula <anssi.hannula@iki.fi> wrote:
>>> On 23.12.2010 04:22, VDR User wrote:
>>>> Hi.  After updating my stable kernel from 2.6.35.7 to 2.6.36.2, I get
>>>> a problem when tuning HDTV channels that use surround sound.  The
>>>> error I get is as follows:
>>>>
>>>> audio_alsa_out: Cannot set number of channels to 6 (err=-22:Invalid argument)
>>>> audio_out: open failed!
>>>>
>>>> With the following xine error:
>>>> ---------------------- (ERROR) ----------------------
>>>> The audio device is unavailable. Please verify if another program
>>>> already uses it.
>>>>
>>>> ['Audio device unavailable' '']
>>>> ------------------ (END OF ERROR) -------------------
>>>
>>> What are the contents of /proc/asound/NVidia/eld* and
>>> /proc/asound/NVidia/codec* ?
>>
>> Booted into 2.6.35.7 with receiver ON:
>> $ cat /proc/asound/NVidia_1/eld*
>> monitor_present         1
>> eld_valid               1
>> monitor_name            SONY AVAMP
>>
>> connection_type         HDMI
>> eld_version             [0x2] CEA-861D or below
>> edid_version            [0x3] CEA-861-B, C or D
>> manufacture_id          0xd94d
>> product_id              0xfb01
>> port_id                 0x20000
>> support_hdcp            0
>> support_ai              0
>> audio_sync_delay        0
>> speakers                [0x5f] FL/FR LFE FC RL/RR RC RLC/RRC
>> sad_count               6
>> sad0_coding_type        [0x1] LPCM
>> sad0_channels           2
>> sad0_rates              [0x1ee0] 44100 48000 88200 176400 192000 384000
>> sad0_bits               [0xe0000] 16 20 24
>> sad1_coding_type        [0x1] LPCM
>> sad1_channels           6
>> sad1_rates              [0x1ee0] 44100 48000 88200 176400 192000 384000
>> sad1_bits               [0xe0000] 16 20 24
>> sad2_coding_type        [0x1] LPCM
>> sad2_channels           8
>> sad2_rates              [0x1ee0] 44100 48000 88200 176400 192000 384000
>> sad2_bits               [0xe0000] 16 20 24
>> sad3_coding_type        [0x2] AC-3
>> sad3_channels           6
>> sad3_rates              [0xe0] 44100 48000 88200
>> sad3_max_bitrate        680000
>> sad4_coding_type        [0x7] DTS
>> sad4_channels           6
>> sad4_rates              [0x6e0] 44100 48000 88200 176400 192000
>> sad4_max_bitrate        1536000
>> sad5_coding_type        [0xa] E-AC-3/DD+ (Dolby Digital Plus)
>> sad5_channels           8
>> sad5_rates              [0xc0] 48000 88200
>>
>> Booted into 2.6.35.7 with receiver OFF:
>> $ cat /proc/asound/NVidia_1/eld*
>> monitor_present         1
>> eld_valid               1
>> monitor_name            SONY AVAMP
>>
>> connection_type         HDMI
>> eld_version             [0x2] CEA-861D or below
>> edid_version            [0x3] CEA-861-B, C or D
>> manufacture_id          0xd94d
>> product_id              0xfb01
>> port_id                 0x20000
>> support_hdcp            0
>> support_ai              0
>> audio_sync_delay        0
>> speakers                [0xffff] FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC
>> FLW/FRW FLH/FRH TC FCH
>> sad_count               1
>> sad0_coding_type        [0x1] LPCM
>> sad0_channels           2
>> sad0_rates              [0xe0] 44100 48000 88200
>> sad0_bits               [0x20000] 16
>>
>> I'm certain at the time I experienced this error, my receiver was
>> turned off, could this be the cause of the error?  If so, this really
>> needs to be fixed/reworked as many people don't have their receivers
>> on (to save power usage, noise, etc) unless they specifically
>> need/want it.  In the event a receiver is off and the user is trying
>> to watch something that requires more then 2 channels, he should
>> either turn the receiver on, or adjust the speaker arrangement in xine
>> to stereo -- however, what should not happen is the alsa driver
>> failing.  Maybe a better solution would be to log an error to syslog
>> or something rather then the driver itself returning an error?
>
> A/V receivers showing TV information is indeed something that wasn't
> thought about :(

This has certainly caused problems.  Anyone thought of a way to
resolve it, or better yet reversed the patch that created the
situation?

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

Re: Bug in setting channels, related to recent ELD/EDID changes?

[James Courtier-Dutton]

On 4 January 2011 16:41, VDR User <user.vdr@gmail.com> wrote:
>>
>> A/V receivers showing TV information is indeed something that wasn't
>> thought about :(
>
> This has certainly caused problems.  Anyone thought of a way to
> resolve it, or better yet reversed the patch that created the
> situation?
>

I think this is related to general hot-plug support in ALSA.
If you plug in a USB speakers, ALSA should detect new speakers and
have a way of informing applications about it.
When you unplug USB speakers, ALSA should detect the lack of speakers
and have a way of informing application about it.
In the same way the if you power on a HDMI amp, instead of just two
speakers (in the TV), we now have 5.1 speakers.
ALSA should have a way to inform applications of the changes.

I do not think ALSA alone can handle these hot plug/unplug events. It
has to be applications that are made to understand these events and
adjust accordingly.
Before now, ALSA has had to be told manually how many speakers a user
has attached, E.g. Stereo, 5.1 etc.
With modern sound devices, this information is available automatically
from the hardware and changes without notice.

So, I propose that an API should be added to achieve this.
So, instead of the application setting the speaker arrangement, the
speaker arrangement is set in ALSA, and the application requests
information about it.
When the application writes sound samples to the sound card and the
speaker arrangement has changed, ALSA should use a specific error
number reported back so the application knows that it should re-check
the speaker-arrangement API and re-open the sound card with the new
details.

Kind Regards

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

Re: Bug in setting channels, related to recent ELD/EDID changes?

[VDR User]

On Tue, Jan 4, 2011 at 10:46 AM, James Courtier-Dutton
<james.dutton@gmail.com> wrote:
>>> A/V receivers showing TV information is indeed something that wasn't
>>> thought about :(
>>
>> This has certainly caused problems.  Anyone thought of a way to
>> resolve it, or better yet reversed the patch that created the
>> situation?
>
> I think this is related to general hot-plug support in ALSA.
> If you plug in a USB speakers, ALSA should detect new speakers and
> have a way of informing applications about it.
> When you unplug USB speakers, ALSA should detect the lack of speakers
> and have a way of informing application about it.
> In the same way the if you power on a HDMI amp, instead of just two
> speakers (in the TV), we now have 5.1 speakers.
> ALSA should have a way to inform applications of the changes.
>
> I do not think ALSA alone can handle these hot plug/unplug events. It
> has to be applications that are made to understand these events and
> adjust accordingly.
> Before now, ALSA has had to be told manually how many speakers a user
> has attached, E.g. Stereo, 5.1 etc.
> With modern sound devices, this information is available automatically
> from the hardware and changes without notice.
>
> So, I propose that an API should be added to achieve this.
> So, instead of the application setting the speaker arrangement, the
> speaker arrangement is set in ALSA, and the application requests
> information about it.
> When the application writes sound samples to the sound card and the
> speaker arrangement has changed, ALSA should use a specific error
> number reported back so the application knows that it should re-check
> the speaker-arrangement API and re-open the sound card with the new
> details.

That sounds like a great solution and hopefully it be considered
when/if steps are taken to fix this problem.  Unfortunately thus far
it seems the preference is to ignore it.  That being the case, will
someone please post a patch that reverses the change that caused this
problem in the first place?

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

Re: Bug in setting channels, related to recent ELD/EDID changes?

[VDR User]

On Tue, Jan 4, 2011 at 10:46 AM, James Courtier-Dutton
<james.dutton@gmail.com> wrote:
>>> A/V receivers showing TV information is indeed something that wasn't
>>> thought about :(
>>
>> This has certainly caused problems.  Anyone thought of a way to
>> resolve it, or better yet reversed the patch that created the
>> situation?
>>
>
> I think this is related to general hot-plug support in ALSA.
> If you plug in a USB speakers, ALSA should detect new speakers and
> have a way of informing applications about it.
> When you unplug USB speakers, ALSA should detect the lack of speakers
> and have a way of informing application about it.
> In the same way the if you power on a HDMI amp, instead of just two
> speakers (in the TV), we now have 5.1 speakers.
> ALSA should have a way to inform applications of the changes.
>
> I do not think ALSA alone can handle these hot plug/unplug events. It
> has to be applications that are made to understand these events and
> adjust accordingly.
> Before now, ALSA has had to be told manually how many speakers a user
> has attached, E.g. Stereo, 5.1 etc.
> With modern sound devices, this information is available automatically
> from the hardware and changes without notice.
>
> So, I propose that an API should be added to achieve this.
> So, instead of the application setting the speaker arrangement, the
> speaker arrangement is set in ALSA, and the application requests
> information about it.
> When the application writes sound samples to the sound card and the
> speaker arrangement has changed, ALSA should use a specific error
> number reported back so the application knows that it should re-check
> the speaker-arrangement API and re-open the sound card with the new
> details.

Will someone please elaborate on when/how/if this will ever be
addressed?  It's a significant problem.

If none of the devs intend to fix this problem, PLEASE provide a patch
that restores alsa's old behavior before the bug was introduced.

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

Re: Bug in setting channels, related to recent ELD/EDID changes?

[Takashi Iwai]

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


Takashi

---
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index d1b1b57..27e8597 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -827,7 +827,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 (eld->eld_valid && eld->sad_count > 0) {
 		hdmi_eld_update_pcm_info(eld, hinfo, codec_pars);
 		if (hinfo->channels_min > hinfo->channels_max ||
 		    !hinfo->rates || !hinfo->formats)

Re: Bug in setting channels, related to recent ELD/EDID changes?

[Anssi Hannula]

(restored CC I removed, sorry about that)

On 10.01.2011 22:36, 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.

Well, I don't like this at all for two reasons:

1) This common use case worked with earlier kernel revisions: You could
start playback of a video / TV channel, then go sit on a couch and start
up the A/V receiver to get surround sound. Now it is broken.

2) There is no way this can be fixed in the libalsa-using application
either, as it doesn't receive a notification when more channels become
available after it has already fallbacked to stereo.

So we got something reasonable that worked before but not with 2.6.36+.

> Then, how can you
> know that more channels will be available in future at all?

We don't. However, we don't know that about any analog line-outs either,
yet we always allow all channels no matter what amount of speakers are
plugged in (AFAIK)  (assuming jack detection support).

> 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.
> 
> 
> Takashi
> 
>>
>>> Takashi
>>>
>>> ---
>>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
>>> index d1b1b57..27e8597 100644
>>> --- a/sound/pci/hda/patch_hdmi.c
>>> +++ b/sound/pci/hda/patch_hdmi.c
>>> @@ -827,7 +827,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 (eld->eld_valid && eld->sad_count > 0) {
>>>  		hdmi_eld_update_pcm_info(eld, hinfo, codec_pars);
>>>  		if (hinfo->channels_min > hinfo->channels_max ||
>>>  		    !hinfo->rates || !hinfo->formats)
>>>
>>
>>
>> -- 
>> Anssi Hannula
>>


-- 
Anssi Hannula

Re: Bug in setting channels, related to recent ELD/EDID changes?

[Takashi Iwai]

At Tue, 11 Jan 2011 18:33:53 +0200,
Anssi Hannula wrote:
> 
> (restored CC I removed, sorry about that)
> 
> On 10.01.2011 22:36, 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.
> 
> Well, I don't like this at all for two reasons:
> 
> 1) This common use case worked with earlier kernel revisions: You could
> start playback of a video / TV channel, then go sit on a couch and start
> up the A/V receiver to get surround sound. Now it is broken.

Yeah, this is a drawback of the "fix", though.  In the earlier driver
version, if you send incompatible setups that don't match with the
actual device, it simply doesn't work.  Now it makes working.

> 2) There is no way this can be fixed in the libalsa-using application
> either, as it doesn't receive a notification when more channels become
> available after it has already fallbacked to stereo.
> 
> So we got something reasonable that worked before but not with 2.6.36+.

It depends on the definition "reasonable" :)

> > Then, how can you
> > know that more channels will be available in future at all?
> 
> We don't. However, we don't know that about any analog line-outs either,
> yet we always allow all channels no matter what amount of speakers are
> plugged in (AFAIK)  (assuming jack detection support).

But there have been already systems which PCM configuration changes
dynamically.  So, sane apps are supposed to re-open if needed
(e.g. multi-channel open failed).

Anyway, reverting the whole idea seems like nonsense as well, since
the current behavior works more or less for many other cases.
An easy solution would be to add a module option as I posted.  In that
way, you can switch the behavior dynamically.  For ones who require
the static configuration, set the option to true.  For others, set the
option false.


Takashi

> > 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.
> > 
> > 
> > Takashi
> > 
> >>
> >>> Takashi
> >>>
> >>> ---
> >>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> >>> index d1b1b57..27e8597 100644
> >>> --- a/sound/pci/hda/patch_hdmi.c
> >>> +++ b/sound/pci/hda/patch_hdmi.c
> >>> @@ -827,7 +827,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 (eld->eld_valid && eld->sad_count > 0) {
> >>>  		hdmi_eld_update_pcm_info(eld, hinfo, codec_pars);
> >>>  		if (hinfo->channels_min > hinfo->channels_max ||
> >>>  		    !hinfo->rates || !hinfo->formats)
> >>>
> >>
> >>
> >> -- 
> >> Anssi Hannula
> >>
> 
> 
> -- 
> Anssi Hannula
> 

Re: Bug in setting channels, related to recent ELD/EDID changes?

[Anssi Hannula]

On 11.01.2011 18:42, Takashi Iwai wrote:
> At Tue, 11 Jan 2011 18:33:53 +0200,
> Anssi Hannula wrote:
>>
>> (restored CC I removed, sorry about that)
>>
>> On 10.01.2011 22:36, 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.
>>
>> Well, I don't like this at all for two reasons:
>>
>> 1) This common use case worked with earlier kernel revisions: You could
>> start playback of a video / TV channel, then go sit on a couch and start
>> up the A/V receiver to get surround sound. Now it is broken.
> 
> Yeah, this is a drawback of the "fix", though.  In the earlier driver
> version, if you send incompatible setups that don't match with the
> actual device, it simply doesn't work.  Now it makes working.
> 
>> 2) There is no way this can be fixed in the libalsa-using application
>> either, as it doesn't receive a notification when more channels become
>> available after it has already fallbacked to stereo.
>>
>> So we got something reasonable that worked before but not with 2.6.36+.
> 
> It depends on the definition "reasonable" :)
> 
>>> Then, how can you
>>> know that more channels will be available in future at all?
>>
>> We don't. However, we don't know that about any analog line-outs either,
>> yet we always allow all channels no matter what amount of speakers are
>> plugged in (AFAIK)  (assuming jack detection support).
> 
> But there have been already systems which PCM configuration changes
> dynamically.  So, sane apps are supposed to re-open if needed
> (e.g. multi-channel open failed).

Yep. It really should get a notification to allow switching to
multichannel later (dunno what that would look like, I don't know the
ALSA api well).

I guess something simpler (looking from the application side) would be
something to allow forcing open if the sink doesn't support the mode but
the card does.

> Anyway, reverting the whole idea seems like nonsense as well, since
> the current behavior works more or less for many other cases.
> An easy solution would be to add a module option as I posted.  In that
> way, you can switch the behavior dynamically.  For ones who require
> the static configuration, set the option to true.  For others, set the
> option false.

Yes, it would indeed be the easiest solution.

> 
> Takashi
> 
>>> 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.
>>>
>>>
>>> Takashi
>>>
>>>>
>>>>> Takashi
>>>>>
>>>>> ---
>>>>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
>>>>> index d1b1b57..27e8597 100644
>>>>> --- a/sound/pci/hda/patch_hdmi.c
>>>>> +++ b/sound/pci/hda/patch_hdmi.c
>>>>> @@ -827,7 +827,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 (eld->eld_valid && eld->sad_count > 0) {
>>>>>  		hdmi_eld_update_pcm_info(eld, hinfo, codec_pars);
>>>>>  		if (hinfo->channels_min > hinfo->channels_max ||
>>>>>  		    !hinfo->rates || !hinfo->formats)
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Anssi Hannula
>>>>
>>
>>
>> -- 
>> Anssi Hannula
>>


-- 
Anssi Hannula

Re: Bug in setting channels, related to recent ELD/EDID changes?

[Anssi Hannula]

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


-- 
Anssi Hannula

Re: Bug in setting channels, related to recent ELD/EDID changes?

[Takashi Iwai]

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

Re: Bug in setting channels, related to recent ELD/EDID changes?

[VDR User]

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

Re: Bug in setting channels, related to recent ELD/EDID changes?

[Anssi Hannula]

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=5eedd1422c2fc79c2f9ed8b71056b97570f95572

-- 
Anssi Hannula

Re: Bug in setting channels, related to recent ELD/EDID changes?

[VDR User]

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!
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Bug in setting channels, related to recent ELD/EDID changes?

[Takashi Iwai]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Bug in setting channels, related to recent ELD/EDID changes?

[VDR User]

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=5eedd1422c2fc79c2f9ed8b71056b97570f95572

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Bug in setting channels, related to recent ELD/EDID changes?

[Takashi Iwai]

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=5eedd1422c2fc79c2f9ed8b71056b97570f95572
> 
> 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel