June 2014 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH] pcm: Fix channel map query when there are lots of maps
by Anssi Hannula 08 Jun '14

08 Jun '14

On most HDA Intel HDMI devices, the channel map list is approx. 500 ints in size, making the 256-sized buffer used by snd_pcm_query_chmaps_from_hw() too small and causing the query to fail (NULL result to caller, ENOMEM). Bump the buffer size to 2048 ints. Signed-off-by: Anssi Hannula <anssi.hannula(a)iki.fi> --- Found while writing XBMC support. I don't like just bumping the buffer size, so I hope you have some idea of a better solution? I guess one way would be just to retry with a dynamically allocated bigger buffer on ENOMEM, if there is nothing better... src/pcm/pcm_hw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/pcm/pcm_hw.c b/src/pcm/pcm_hw.c index 9ff83a9..ed83197 100644 --- a/src/pcm/pcm_hw.c +++ b/src/pcm/pcm_hw.c @@ -1051,7 +1051,7 @@ snd_pcm_query_chmaps_from_hw(int card, int dev, int subdev, { snd_ctl_t *ctl; snd_ctl_elem_id_t *id; - unsigned int tlv[256], *start; + unsigned int tlv[2048], *start; snd_pcm_chmap_query_t **map; int i, ret, nums; -- 1.8.4.5

2 2

[alsa-devel] On HD codec valid command working only on hwdep hda-verb and embedded on function snd_hda_multi_out_analog_open
by asd 08 Jun '14

08 Jun '14

Hi On patch_realtek can't run snd_hda_write.Only situations when run snd_hda_write is to run inside off snd_hda_multi_out_analog_open function (suppose to when sream is on codec is weak up and become online.

2 1

[alsa-devel] [PATCH] ASoC: Intel: Show Baytrail SST DSP firmware details during init
by Jarkko Nikula 06 Jun '14

06 Jun '14

DSP initialization complete message IPC_IA_FW_INIT_CMPLT is a large message carrying firmware details in mailbox. Read and show those details during init in order to be able to get that information to QA reports. Signed-off-by: Jarkko Nikula <jarkko.nikula(a)linux.intel.com> --- sound/soc/intel/sst-baytrail-ipc.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/sound/soc/intel/sst-baytrail-ipc.c b/sound/soc/intel/sst-baytrail-ipc.c index d207b22ea330..67673a2c0f41 100644 --- a/sound/soc/intel/sst-baytrail-ipc.c +++ b/sound/soc/intel/sst-baytrail-ipc.c @@ -122,6 +122,26 @@ struct sst_byt_tstamp { u32 channel_peak[8]; } __packed; +struct sst_byt_fw_version { + u8 build; + u8 minor; + u8 major; + u8 type; +} __packed; + +struct sst_byt_fw_build_info { + u8 date[16]; + u8 time[16]; +} __packed; + +struct sst_byt_fw_init { + struct sst_byt_fw_version fw_version; + struct sst_byt_fw_build_info build_info; + u16 result; + u8 module_id; + u8 debug_info; +} __packed; + /* driver internal IPC message structure */ struct ipc_message { struct list_head list; @@ -868,6 +888,7 @@ int sst_byt_dsp_init(struct device *dev, struct sst_pdata *pdata) { struct sst_byt *byt; struct sst_fw *byt_sst_fw; + struct sst_byt_fw_init init; int err; dev_dbg(dev, "initialising Byt DSP IPC\n"); @@ -929,6 +950,15 @@ int sst_byt_dsp_init(struct device *dev, struct sst_pdata *pdata) goto boot_err; } + /* show firmware information */ + sst_dsp_inbox_read(byt->dsp, &init, sizeof(init)); + dev_info(byt->dev, "FW version: %02x.%02x.%02x.%02x\n", + init.fw_version.major, init.fw_version.minor, + init.fw_version.build, init.fw_version.type); + dev_info(byt->dev, "Build type: %x\n", init.fw_version.type); + dev_info(byt->dev, "Build date: %s %s\n", + init.build_info.date, init.build_info.time); + pdata->dsp = byt; byt->fw = byt_sst_fw; -- 2.0.0.rc2

2 2

[alsa-devel] Add support of alc667 and more codec rename
by Kailang 06 Jun '14

06 Jun '14

Hi Takashi, Attach has 3 patches. Many Thanks. BR, Kailang

2 1

[alsa-devel] [PATCH 0/5] ARM: atmel: switch audio to CCF
by Bo Shen 06 Jun '14

06 Jun '14

As the sama5d3xek and at91sam9n12ek have switch to CCF, in order to support audio, also switch it to CCF. This patch series based on next-2014-0604 tag. Bo Shen (5): ASoC: atmel_wm8904: switch to CCF ASoC: wm8904: switch to CCF dt: wm8904: add device tree binding document ARM: atmel: sama5d3xek: switch sound to CCF ARM: atmel: at91sam9n12ek: switch sound to CCF Documentation/devicetree/bindings/sound/wm8904.txt | 32 ++++++++++++++ arch/arm/boot/dts/at91sam9n12ek.dts | 2 + arch/arm/boot/dts/sama5d3xmb.dtsi | 2 + sound/soc/atmel/atmel_wm8904.c | 50 ---------------------- sound/soc/codecs/wm8904.c | 13 ++++++ 5 files changed, 49 insertions(+), 50 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/wm8904.txt -- 1.8.5.2

2 10

[alsa-devel] [PATCH v2 1/2] ASoC: export dapm_kcontrol_set/get_value functions
by Vinod Koul 06 Jun '14

06 Jun '14

The DSPs like Intel ones use the DPCM to represent the DSP toplogy. So when DAPM triggers the widget, the DSP needs to know the kcontrol values and pass on to DSP firmware, so export these for driver use Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- include/sound/soc-dapm.h | 3 +++ sound/soc/soc-dapm.c | 6 ++++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h index 75020f5..abda467 100644 --- a/include/sound/soc-dapm.h +++ b/include/sound/soc-dapm.h @@ -368,6 +368,9 @@ int dapm_regulator_event(struct snd_soc_dapm_widget *w, struct snd_kcontrol *kcontrol, int event); int dapm_clock_event(struct snd_soc_dapm_widget *w, struct snd_kcontrol *kcontrol, int event); +bool dapm_kcontrol_set_value(const struct snd_kcontrol *kcontrol, + unsigned int value); +unsigned int dapm_kcontrol_get_value(const struct snd_kcontrol *kcontrol); /* dapm controls */ int snd_soc_dapm_put_volsw(struct snd_kcontrol *kcontrol, diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 98c1dc6..d831e73 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -327,14 +327,15 @@ static struct list_head *dapm_kcontrol_get_path_list( list_for_each_entry(path, dapm_kcontrol_get_path_list(kcontrol), \ list_kcontrol) -static unsigned int dapm_kcontrol_get_value(const struct snd_kcontrol *kcontrol) +unsigned int dapm_kcontrol_get_value(const struct snd_kcontrol *kcontrol) { struct dapm_kcontrol_data *data = snd_kcontrol_chip(kcontrol); return data->value; } +EXPORT_SYMBOL_GPL(dapm_kcontrol_get_value); -static bool dapm_kcontrol_set_value(const struct snd_kcontrol *kcontrol, +bool dapm_kcontrol_set_value(const struct snd_kcontrol *kcontrol, unsigned int value) { struct dapm_kcontrol_data *data = snd_kcontrol_chip(kcontrol); @@ -349,6 +350,7 @@ static bool dapm_kcontrol_set_value(const struct snd_kcontrol *kcontrol, return true; } +EXPORT_SYMBOL_GPL(dapm_kcontrol_set_value); /** * snd_soc_dapm_kcontrol_codec() - Returns the codec associated to a kcontrol -- 1.7.0.4

3 12

[alsa-devel] r8a7790 only has audio when clock is forced on
by Violeta Menendez Gonzalez 06 Jun '14

06 Jun '14

Hi all, We have a problem where audio on r8a7790 is not working due to it not sending interrupts. We've verified that the pins and the clocks are working and correctly configured. The codec is starting and producing correct bit and word clock signals We've made a hack to force /mstp10_clks /on that makes the audio work. Further investigation showed that it's only needed to force SSI(ALL) on, but, as far as we know, the manual doesn't say anything about it having to be kept on. We've also debugged this hack and saw that the registers have correct values. These are some of the debugging messages we have when the audio fails: Playing WAVE '../audio/r.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo cpg_mstp_clock_endisable: index 5, enable 1 cpg_mstp_clock_endisable: index 5, value read from group->smstpcr 0002ffe0 cpg_mstp_clock_endisable: index 5, value write in group->smstpcr 0002ffc0 cpg_mstp_clock_endisable: index 15, enable 1 cpg_mstp_clock_endisable: index 15, value read from group->smstpcr 0002ffc0 cpg_mstp_clock_endisable: index 15, value written in group->smstpcr 00027fc0 aplay: pcm_writecpg_mstp_clock_endisable: index 15, enable 0 cpg_mstp_clock_endisable: index 15, value read from group->smstpcr 00027fc0 cpg_mstp_clock_endisable: index 15, value write in group->smstpcr 0002ffc0 :1710: write errcpg_mstp_clock_endisable: index 5, enable 0 cpg_mstp_clock_endisable: index 5, value read from group->smstpcr 0002ffc0 cpg_mstp_clock_endisable: index 5, value write in group->smstpcr 0002ffe0 or: Input/output error This shows that the SSI (ALL) clock in bit 5 being enabled before the SSI0 and that it is also disabled in the reverse sequence as expected. Not sure what to do next or what the problem could be. Any new ideas are welcome, Thanks! -- Violeta Menéndez González http://www.codethink.co.uk/ Software Engineer Codethink - Providing Genius

6 13

[alsa-devel] [PATCH 00/11] ASoC: Add support for DAPM at the component level
by Lars-Peter Clausen 06 Jun '14

06 Jun '14

Hi, This series is the next step in componentization. It moves the DAPM support to the component level. This will allow any component to have DAPM widgets and routes, which was previously only possible for CODECs, and will allow any component to have DAPM widgets with controls (i.e. Mixers and MUXs), which was previously only possible for CODECs. At the end of this patchset the DAPM code will have (almost) no dependency on snd_soc_codec or snd_soc_platform and the dependency on snd_soc_component is confined to 4 small helper functions. The only reason why there is still snd_soc_codec/snd_soc_platform dependent code is because there are still a lot of drivers which use widget->codec/platform and dapm->codec/platform. So those still need to be initialized. This will be cleaned up in a separate series and once that's done the codec and platform fields will be removed from the widget and DAPM context struct. One of the major problems of moving DAPM to the component level is that the DAPM context is directly embedded in the snd_soc_codec and snd_soc_platform structs and there are many drivers directly accessing that embedded field. This means it is not possible to move the field without causing a bit of code churn in the drivers. The patch series solves this by adding two fields to the component struct. One pointer to a DAPM context, which points to the DAPM context that is used by the component. And one DAPM context, which is used as the default if no other DAPM context was provided. Neither of the fields is accessed directly, instead a inline helper function is added that returns the DAPM context for a component. This will make it possible to eventually seamlessly switch over once all direct references to CODEC and platform DAPM contexts have been eliminated. Depends on topic/component, topic/core, topic/dapm and topic/dt - Lars Lars-Peter Clausen (11): ASoC: Move name_prefix from CODEC to component ASoC: Move name and id from CODEC/platform to component ASoC: Split component registration into two steps ASoC: Auto disconnect pins from all DAPM contexts ASoC: Add helper functions to cast from DAPM context to CODEC/platform ASoC: Add a set_bias_level() callback to the DAPM context struct ASoC: Add DAPM support at the component level ASoC: Use component DAPM context for platforms ASoC: Add component level stream_event() and seq_notifier() support ASoC: Add component level set_bias_level() support ASoC: dapm: Remove DAI DAPM context include/sound/soc-dai.h | 1 - include/sound/soc-dapm.h | 6 +- include/sound/soc.h | 78 ++++++++-- include/trace/events/asoc.h | 6 +- sound/soc/codecs/tlv320dac33.c | 2 +- sound/soc/soc-cache.c | 7 +- sound/soc/soc-compress.c | 8 +- sound/soc/soc-core.c | 328 ++++++++++++++++++++++------------------- sound/soc/soc-dapm.c | 180 ++++++++++++---------- sound/soc/soc-pcm.c | 4 +- 10 files changed, 365 insertions(+), 255 deletions(-) -- 1.8.0

3 15

[alsa-devel] [PATCH] ALSA: hda - add two new pin tables
by Hui Wang 06 Jun '14

06 Jun '14

These two new pin tables can fix headset mic problems for several new Dell machines. And also delete some machines from old quirk table since the existing pin talbes already cover them. Signed-off-by: Hui Wang <hui.wang(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 47 +++++++++++++++++++++++++++++++++++++------ 1 file changed, 41 insertions(+), 6 deletions(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 12fb411..003ba10 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4741,18 +4741,12 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1028, 0x0614, "Dell Inspiron 3135", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x0615, "Dell Vostro 5470", ALC290_FIXUP_SUBWOOFER_HSJACK), SND_PCI_QUIRK(0x1028, 0x0616, "Dell Vostro 5470", ALC290_FIXUP_SUBWOOFER_HSJACK), - SND_PCI_QUIRK(0x1028, 0x062c, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x0638, "Dell Inspiron 5439", ALC290_FIXUP_MONO_SPEAKERS_HSJACK), SND_PCI_QUIRK(0x1028, 0x063f, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x064a, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x064b, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE), - SND_PCI_QUIRK(0x1028, 0x064d, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x0668, "Dell", ALC255_FIXUP_DELL2_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x0669, "Dell", ALC255_FIXUP_DELL2_MIC_NO_PRESENCE), - SND_PCI_QUIRK(0x1028, 0x0674, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE), - SND_PCI_QUIRK(0x1028, 0x067e, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE), - SND_PCI_QUIRK(0x1028, 0x067f, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE), - SND_PCI_QUIRK(0x1028, 0x0680, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x0684, "Dell", ALC269_FIXUP_DELL2_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x15cc, "Dell X5 Precision", ALC269_FIXUP_DELL2_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x15cd, "Dell X5 Precision", ALC269_FIXUP_DELL2_MIC_NO_PRESENCE), @@ -4977,6 +4971,26 @@ static const struct snd_hda_pin_quirk alc269_pin_fixup_tbl[] = { #endif .pins = (const struct hda_pintbl[]) { {0x12, 0x90a60160}, + {0x14, 0x90170120}, + {0x17, 0x90170140}, + {0x18, 0x40000000}, + {0x19, 0x411111f0}, + {0x1a, 0x411111f0}, + {0x1b, 0x411111f0}, + {0x1d, 0x41163b05}, + {0x1e, 0x411111f0}, + {0x21, 0x0321102f}, + }, + .value = ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, + }, + { + .codec = 0x10ec0255, + .subvendor = 0x1028, +#ifdef CONFIG_SND_DEBUG_VERBOSE + .name = "Dell", +#endif + .pins = (const struct hda_pintbl[]) { + {0x12, 0x90a60160}, {0x14, 0x90170130}, {0x17, 0x40000000}, {0x18, 0x411111f0}, @@ -6014,6 +6028,27 @@ static const struct snd_hda_pin_quirk alc662_pin_fixup_tbl[] = { .name = "Dell", #endif .pins = (const struct hda_pintbl[]) { + {0x12, 0x99a30140}, + {0x14, 0x90170110}, + {0x15, 0x0321101f}, + {0x16, 0x03011020}, + {0x18, 0x40000008}, + {0x19, 0x411111f0}, + {0x1a, 0x411111f0}, + {0x1b, 0x411111f0}, + {0x1d, 0x41000001}, + {0x1e, 0x411111f0}, + {0x1f, 0x411111f0}, + }, + .value = ALC668_FIXUP_AUTO_MUTE, + }, + { + .codec = 0x10ec0668, + .subvendor = 0x1028, +#ifdef CONFIG_SND_DEBUG_VERBOSE + .name = "Dell", +#endif + .pins = (const struct hda_pintbl[]) { {0x12, 0x99a30150}, {0x14, 0x90170110}, {0x15, 0x0321101f}, -- 1.8.1.2

2 1

[alsa-devel] Recording support for Roland SD-50 USB Audio device
by François Isabelle 05 Jun '14

05 Jun '14

Hi. I'm unable to record using the Roland SD-50 on Linux. My alsa configuration is available at the following address: http://www.alsa-project.org/db/?f=19aeffd0d30e952fdd12d589929fbe2a0f98ad7f There is something odd with playback as well. With the sound control panel ( unity-control-center ). The test output only works when the SD-50 input is selected from the input tab. So, I'm pretty sure there is simply some mix up in the mixer configuration... and I'd like to contribute making it work. ( I have some programming stills :-) ) Although Alsa with Jack and Ardour makes a pretty decent and promising environment for audio production on Linux. It's hard to believe that device support is still an issue after more than 20 years of Linux, darn manufacturers ! On another note, if anyone has a good recommendation for USB Midi+Audio + Sound Module to replace this SD-50 on Linux , I'd be willing to hear about it... I want the sound module to be able to use it when not connected to a computer. I want USB because I don't want to take it off with the laptop as well. I really though the SD-50 would make my day... Thank you. François

3 8