August 2010 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Auto-muting line-outs?
by David Henningsson 03 Aug '10

03 Aug '10

I'm getting bug reports from downstream about auto-muting not working, and when looking at some of them I find that the reason is that they have a headphone + line-out combination instead of headphone + speaker. Looking at commits such as 2a2ed0df, this is intentional. I'm not sure what the majority of users want or expect in this case though, of course the users who like it the way it is, aren't raising their voices. :-) Anyway, for users that really want auto-muting for their line-outs, would a suitable workaround to recommend them, be to tweak user_pin_config, turning the line-out into a speaker-out, or would that have undesirable side effects? -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

3 3

[PATCH] Include stdlib.h, needed for calloc
by David Henningsson 03 Aug '10

03 Aug '10

Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- hda-spec.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hda-spec.c b/hda-spec.c index 6c4f045..2ff8b21 100644 --- a/hda-spec.c +++ b/hda-spec.c @@ -23,6 +23,7 @@ #include <stdio.h> #include <errno.h> #include <string.h> +#include <stdlib.h> #include "hda-types.h" #include "hda-log.h" -- 1.7.0.4 --------------060309010103090609080103--

1 0

[alsa-devel] ALC269 mixer nodes
by David Henningsson 03 Aug '10

03 Aug '10

Here's yet another ALC269 which I'm unsure of how to fix the right way. There is no way to enable the microphone, and I think the trouble has to do with that the auto parser does not check whether the node is a mixer or a selector. It might be that the "alc269" vs "alc269vb" detection is wrong as well (btw, what does vb stand for?). I unfortunately do not have the full alsa-info output, but the codec-proc is here: http://launchpadlibrarian.net/49076615/Card0.Codecs.codec.2.txt and PCI IDs: http://launchpadlibrarian.net/49076618/PciMultimedia.txt Thanks in advance, -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

2 4

[alsa-devel] [PATCH 1/2] FIX to not expose SPDIF on Thinkpad X301, since it does not have the ability to use SPDIF
by Jerone Young 03 Aug '10

03 Aug '10

Sorry about the last two times. Something was really going wrong. The Lenovo X301 does not have the ability to connect to a docking station to use the SPDIF port. It also does not have the ability to do SPDIF though the headphone jack or Display Port jacks. This patch fixes it so this is not exposed for the X301 and users do think it has the ability to do SPDIF. I tested both headphone & display port jacks and it is not there. I have tested this patch and it works great. Also to add the other Thinkpads have different subsystem codec IDs. Here are examples: X301: http://launchpadlibrarian.net/31561902/Card0.Codecs.codec.0.txt X200: http://launchpadlibrarian.net/49055036/Card0.Codecs.codec.0.txt W500: http://launchpadlibrarian.net/36276057/Card0.Codecs.codec.0.txt Signed-off-by: Jerone Young <jerone.young(a)canonical.com> diff --git a/pci/hda/patch_conexant.c b/pci/hda/patch_conexant.c index c49030b..efca393 100644 --- a/pci/hda/patch_conexant.c +++ b/pci/hda/patch_conexant.c @@ -2004,6 +2004,11 @@ static int patch_cxt5051(struct hda_codec *codec) break; case CXT5051_LENOVO_X200: spec->init_verbs[0] = cxt5051_lenovo_x200_init_verbs; + /* Thinkpad X301 does not have S/PDIF wired and no ability + to use a docking station. */ + if (codec->subsystem_id == 0x17aa211f) { + spec->multiout.dig_out_nid = 0; + } break; case CXT5051_F700: spec->init_verbs[0] = cxt5051_f700_init_verbs;

2 1

[alsa-devel] [PATCH 2/2] Fix Thinkpad X300 so SPDIF is not exposed
by Jerone Young 03 Aug '10

03 Aug '10

Just as with the X301. The X300 does not have a way to do SPDIF either. It does not have a dock connector, nor does it have the SPDIF through the headphone jack. This patch fixes it so X300 does not show SPDIF, since it cannot do it. To add all Lenovo Thinkpads had different codec subsytem IDs: X300: http://launchpadlibrarian.net/34862838/Card0.Codecs.codec.0.txt Signed-off-by: Jerone Young <jerone.young(a)canonical.com> diff --git a/pci/hda/patch_analog.c b/pci/hda/patch_analog.c index afbe314..1fe6c77 100644 --- a/pci/hda/patch_analog.c +++ b/pci/hda/patch_analog.c @@ -3662,7 +3662,14 @@ static int patch_ad1984(struct hda_codec *codec) codec->patch_ops.build_pcms = ad1984_build_pcms; break; case AD1984_THINKPAD: - spec->multiout.dig_out_nid = AD1884_SPDIF_OUT; + if (codec->subsystem_id == 0x17aa20fb) { + /* Thinpad X300 does not have the ability to do SPDIF, + or attach to docking station to use SPDIF */ + spec->multiout.dig_out_nid = 0; + } + else { + spec->multiout.dig_out_nid = AD1884_SPDIF_OUT; + } spec->input_mux = &ad1984_thinkpad_capture_source; spec->mixers[0] = ad1984_thinkpad_mixers; spec->init_verbs[spec->num_init_verbs++] = ad1984_thinkpad_init_verbs;

1 0

[alsa-devel] [PATCH] [RESEND] FIX to not expose SPDIF on Thinkpad X301, since it does not have the ability to use SPDIF
by Jerone Young 03 Aug '10

03 Aug '10

The Lenovo X301 does not have the ability to connect to a docking station to use the SPDIF port. It also does not have the ability to do SPDIF though the headphone jack or Display Port jacks. This patch fixes it so this is not exposed for the X301 and users do think it has the ability to do SPDIF. I tested both headphone & display port jacks and it is not there. I have tested this patch and it works great. Also to add the other Thinkpads have different subsystem codec IDs. Here are examples: X301: http://launchpadlibrarian.net/31561902/Card0.Codecs.codec.0.txt X200: http://launchpadlibrarian.net/49055036/Card0.Codecs.codec.0.txt W500: http://launchpadlibrarian.net/36276057/Card0.Codecs.codec.0.txt Signed-off-by: Jerone Young <jerone.young(a)canonical.com> diff --git a/pci/hda/patch_conexant.c b/pci/hda/patch_conexant.c index c49030b..abc320a 100644 @@ -2004,6 +2006,11 @@ static int patch_cxt5051(struct hda_codec *codec) break; case CXT5051_LENOVO_X200: spec->init_verbs[0] = cxt5051_lenovo_x200_init_verbs; + /* Thinkpad X301 does not have S/PDIF wired and no ability + to use a docking station. */ + if (codec->subsystem_id == 0x17aa211f) { + spec->multiout.dig_out_nid = 0; + } break; case CXT5051_F700: spec->init_verbs[0] = cxt5051_f700_init_verbs;

3 4

[alsa-devel] How to handle HBR pass-through? (new PCM_FORMAT?)
by Anssi Hannula 03 Aug '10

03 Aug '10

Hi all! Passing through compressed audio via a digital link (S/PDIF, HDMI) is done by encapsulating the audio in a constant-bitrate IEC-61937 format, which is then passed to alsa as a normal 16bit PCM stream. However, there is a new complication: Codecs that require an iec60958 frame rate higher than 192kHz (currently TrueHD/MLP and DTS-HD) need to be transmitted in HDMI (note that these can't be transmitted in normal S/PDIF at all) in a slightly different way. The transmission via HDMI is essentially the same as transmission of 8-channel PCM stream with sample rate of iec60958_frame_rate/4 (e.g. 192kHz for TrueHD), with the samples inside a HBR packet instead of standard audio sample packet. What this means is that if just the needed HBR bits are set in the audio driver, one can play back e.g. TrueHD by passing the IEC-61937 stream to ALSA as 192kHz 8-channel 16-bit PCM data; of course normal 8-channel PCM playback wouldn't work anymore then. So the driver would need to know if this is 8- channel PCM or 8-channel compressed audio. Which brings us to my question: How should the user be able to do this, i.e. inform the driver whether this is 8-channel PCM data or compressed audio data? One easy option would be to have a separate IEC61937_HBR format in ALSA which could be used for IEC-61937 streams represented as 8x 16-bit channels. If that would be considered too specific, we could add a more generic IEC61937 format, which is the same as above except that "normal" ( = "2 channel") IEC-61937 streams could be used as well. However, as normal IEC-61937 streams can be used with S/PDIF as well, we'd AFAICS need to add such format bit to all S/PDIF drivers or have a no-op converter to the more widely supported 16- bit PCM format. Technically, I guess, IEC61937 data should be considered 8-bit or 32-bit (which is the amount of data in a single IEC-60958 frame) 1-channel stream, but that would mean the needed sample rate values would be far higher, which would be confusing since 16-bit PCM samples would not be supported at those rates. Another possible option could be to have some ALSA device flag like AESx now are (I'm not sure how those are handled, maybe it wouldn't work). Or maybe we should have SND_PCM_SUBFORMAT_IEC61937 or SND_PCM_SUBFORMAT_NONPCM? What should be done? -- Anssi Hannula

3 6

[alsa-devel] [PATCH] FIX to not expose SPDIF on Thinkpad X301, since it does not have the ability to use SPDIF
by Jerone Young 03 Aug '10

03 Aug '10

The Lenovo X301 does not have the ability to connect to a docking station to use the SPDIF port. It also does not have the ability to do SPDIF though the headphone jack or Display Port jacks. This patch fixes it so this is not exposed for the X301 and users do think it has the ability to do SPDIF. I tested both headphone & display port jacks and it is not there. I have tested this patch and it works great. Also to add the other Thinkpads have different subsystem codec IDs. Here are examples: X301: http://launchpadlibrarian.net/31561902/Card0.Codecs.codec.0.txt X200: http://launchpadlibrarian.net/49055036/Card0.Codecs.codec.0.txt W500: http://launchpadlibrarian.net/36276057/Card0.Codecs.codec.0.txt Signed-off-by: Jerone Young <jerone.young(a)canonical.com> @@ -2004,6 +2006,11 @@ static int patch_cxt5051(struct hda_codec *codec) break; case CXT5051_LENOVO_X200: spec->init_verbs[0] = cxt5051_lenovo_x200_init_verbs; + /* Thinkpad X301 does not have S/PDIF wired and no ability + to use a docking station. */ + if (codec->subsystem_id == 0x17aa211f) { + spec->multiout.dig_out_nid = 0; + } break; case CXT5051_F700: spec->init_verbs[0] = cxt5051_f700_init_verbs;

2 1

[alsa-devel] [GIT PULL] ASoC updates for 2.6.36
by Liam Girdwood 02 Aug '10

02 Aug '10

Hi Takashi, More updates for 2.6.36. Btw, when are you thinking of doing a pull request for 2.6.36 ? I'm doing a multi-component patch series later today and if all goes well it would be nice to get it in for the 2.6.36 merge window. Thanks Liam --- The following changes since commit a7e7cd5bd7d1e0134032b8db5e64ceb9dac8b3ca: Kuninori Morimoto (1): ASoC: da7210: Add HeadPhone Playback Volume control are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc-2.6.git for-2.6.36 Peter Ujfalusi (7): ASoC: TWL4030: Capture route DAPM event fix ASoC: tlv320dac33: Revisit the FIFO Mode1 handling ASoC: tlv320dac33: Add support for automatic FIFO configuration ASoC: omap-mcbsp: Restructure the code within omap_mcbsp_dai_hw_params ASoC: omap-mcbsp: Code cleanup in omap_mcbsp_dai_hw_params ASoC: omap-mcbsp: Support for sDMA packet mode ASoC: omap-mcbsp: Remove period size constraint in THRESHOLD mode include/sound/tlv320dac33-plat.h | 2 + sound/soc/codecs/tlv320dac33.c | 125 ++++++++++++++++++++++------------ sound/soc/codecs/twl4030.c | 2 - sound/soc/omap/omap-mcbsp.c | 137 +++++++++++++++++++++----------------- 4 files changed, 158 insertions(+), 108 deletions(-)

4 6

[alsa-devel] [PATCH] pcm_plug: fix comparison always true
by Anssi Hannula 02 Aug '10

02 Aug '10

Signed-off-by: Anssi Hannula <anssi.hannula(a)iki.fi> --- Fixes an obvious mistake which I noticed while reading the code. Untested. src/pcm/pcm_plug.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/pcm/pcm_plug.c b/src/pcm/pcm_plug.c index 967cf46..e9d2923 100644 --- a/src/pcm/pcm_plug.c +++ b/src/pcm/pcm_plug.c @@ -485,7 +485,7 @@ static int snd_pcm_plug_change_format(snd_pcm_t *pcm, snd_pcm_t **new, snd_pcm_p /* No conversion is needed */ if (clt->format == slv->format && clt->rate == slv->rate && - clt->channels == clt->channels) + clt->channels == slv->channels) return 0; if (snd_pcm_format_linear(slv->format)) { -- 1.7.2

2 1