February 2020 - Alsa-devel - mailman.alsa-project.org

[PATCH] ASoC: soc-core: fix for_rtd_codec_dai_rollback() macro
by Pierre-Louis Bossart 20 Feb '20

20 Feb '20

The use of parentheses to protect the argument is fine for (i)++ but not for (--i). Fixes: 83f94a2e293d61 ("ASoC: soc-core: add snd_soc_close_delayed_work()") Cc: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- include/sound/soc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index f0e4f36f83bf..8a2266676b2d 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -1157,7 +1157,7 @@ struct snd_soc_pcm_runtime { ((i) < rtd->num_codecs) && ((dai) = rtd->codec_dais[i]); \ (i)++) #define for_each_rtd_codec_dai_rollback(rtd, i, dai) \ - for (; ((--i) >= 0) && ((dai) = rtd->codec_dais[i]);) + for (; (--(i) >= 0) && ((dai) = rtd->codec_dais[i]);) void snd_soc_close_delayed_work(struct snd_soc_pcm_runtime *rtd); -- 2.20.1

3 2

[PATCH] ASoC: dpcm: remove confusing trace in dpcm_get_be()
by Jerome Brunet 20 Feb '20

20 Feb '20

Now that dpcm_get_be() is used in dpcm_end_walk_at_be(), it is not a error if this function does not find a BE for the provided widget. Remove the related dev_err() trace which is confusing since things might be working as expected. When called from dpcm_add_paths(), it is an error if dpcm_get_be() fails to find a BE for the provided widget. The necessary error trace is already done in this case. Fixes: 027a48387183 ("ASoC: soc-pcm: use dpcm_get_be() at dpcm_end_walk_at_be()") Cc: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> --- sound/soc/soc-pcm.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 63f67eb7c077..aff27c8599ef 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -1270,9 +1270,7 @@ static struct snd_soc_pcm_runtime *dpcm_get_be(struct snd_soc_card *card, } } - /* dai link name and stream name set correctly ? */ - dev_err(card->dev, "ASoC: can't get %s BE for %s\n", - stream ? "capture" : "playback", widget->name); + /* Widget provided is not a BE */ return NULL; } -- 2.24.1

4 3

[PATCH] ASoC: tas2562: Add support for ISENSE and VSENSE
by Dan Murphy 20 Feb '20

20 Feb '20

Add additional support for ISENSE and VSENSE feature for the TAS2562. This feature monitors the output to the loud speaker attempts to eliminate IR drop errors due to packaging. This feature is defined in Section 8.4.5 IV Sense of the data sheet. Signed-off-by: Dan Murphy <dmurphy(a)ti.com> --- sound/soc/codecs/tas2562.c | 32 +++++++++++++++++++++++++++----- sound/soc/codecs/tas2562.h | 6 +++--- 2 files changed, 30 insertions(+), 8 deletions(-) diff --git a/sound/soc/codecs/tas2562.c b/sound/soc/codecs/tas2562.c index 5b4803a76719..b2682c2360b6 100644 --- a/sound/soc/codecs/tas2562.c +++ b/sound/soc/codecs/tas2562.c @@ -383,18 +383,34 @@ static int tas2562_dac_event(struct snd_soc_dapm_widget *w, struct snd_soc_component *component = snd_soc_dapm_to_component(w->dapm); struct tas2562_data *tas2562 = snd_soc_component_get_drvdata(component); + int ret; switch (event) { case SND_SOC_DAPM_POST_PMU: - dev_info(tas2562->dev, "SND_SOC_DAPM_POST_PMU\n"); + ret = snd_soc_component_update_bits(component, + TAS2562_PWR_CTRL, + TAS2562_MODE_MASK, + TAS2562_MUTE); + if (ret) + goto end; break; case SND_SOC_DAPM_PRE_PMD: - dev_info(tas2562->dev, "SND_SOC_DAPM_PRE_PMD\n"); + ret = snd_soc_component_update_bits(component, + TAS2562_PWR_CTRL, + TAS2562_MODE_MASK, + TAS2562_SHUTDOWN); + if (ret) + goto end; break; default: - break; + dev_err(tas2562->dev, "Not supported evevt\n"); + return -EINVAL; } +end: + if (ret < 0) + return ret; + return 0; } @@ -416,7 +432,6 @@ static const struct snd_kcontrol_new tas2562_snd_controls[] = { static const struct snd_soc_dapm_widget tas2562_dapm_widgets[] = { SND_SOC_DAPM_AIF_IN("ASI1", "ASI1 Playback", 0, SND_SOC_NOPM, 0, 0), SND_SOC_DAPM_MUX("ASI1 Sel", SND_SOC_NOPM, 0, 0, &tas2562_asi1_mux), - SND_SOC_DAPM_AIF_IN("DAC IN", "Playback", 0, SND_SOC_NOPM, 0, 0), SND_SOC_DAPM_DAC_E("DAC", NULL, SND_SOC_NOPM, 0, 0, tas2562_dac_event, SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD), SND_SOC_DAPM_SWITCH("ISENSE", TAS2562_PWR_CTRL, 3, 1, &isense_switch), @@ -431,7 +446,7 @@ static const struct snd_soc_dapm_route tas2562_audio_map[] = { {"ASI1 Sel", "Left", "ASI1"}, {"ASI1 Sel", "Right", "ASI1"}, {"ASI1 Sel", "LeftRightDiv2", "ASI1"}, - { "DAC", NULL, "DAC IN" }, + { "DAC", NULL, "ASI1 Sel" }, { "OUT", NULL, "DAC" }, {"ISENSE", "Switch", "IMON"}, {"VSENSE", "Switch", "VMON"}, @@ -472,6 +487,13 @@ static struct snd_soc_dai_driver tas2562_dai[] = { .rates = SNDRV_PCM_RATE_8000_192000, .formats = TAS2562_FORMATS, }, + .capture = { + .stream_name = "ASI1 Capture", + .channels_min = 0, + .channels_max = 2, + .rates = SNDRV_PCM_RATE_8000_192000, + .formats = TAS2562_FORMATS, + }, .ops = &tas2562_speaker_dai_ops, }, }; diff --git a/sound/soc/codecs/tas2562.h b/sound/soc/codecs/tas2562.h index 62e659ab786d..6f55ebcf19ea 100644 --- a/sound/soc/codecs/tas2562.h +++ b/sound/soc/codecs/tas2562.h @@ -40,7 +40,7 @@ #define TAS2562_RESET BIT(0) -#define TAS2562_MODE_MASK 0x3 +#define TAS2562_MODE_MASK GENMASK(1,0) #define TAS2562_ACTIVE 0x0 #define TAS2562_MUTE 0x1 #define TAS2562_SHUTDOWN 0x2 @@ -73,8 +73,8 @@ #define TAS2562_TDM_CFG2_RXWLEN_24B BIT(3) #define TAS2562_TDM_CFG2_RXWLEN_32B (BIT(2) | BIT(3)) -#define TAS2562_VSENSE_POWER_EN BIT(2) -#define TAS2562_ISENSE_POWER_EN BIT(3) +#define TAS2562_VSENSE_POWER_EN 2 +#define TAS2562_ISENSE_POWER_EN 3 #define TAS2562_TDM_CFG5_VSNS_EN BIT(6) #define TAS2562_TDM_CFG5_VSNS_SLOT_MASK GENMASK(5, 0) -- 2.25.0

2 3

[alsa-devel] Implicit feedback solution for Boss GT-1 and maybe other devices
by Mike Oliphant 20 Feb '20

20 Feb '20

I received a very helpful email response to my previous thread about trying to get the Boss GT-1 pedalboard working reliably, and as a result I now have a working solution. The issue seems to be that the GT-1 does not send any capture data until it gets some playback data first. This block in the "snd_usb_endpoint_start()" function in endpoint.c: "if (snd_usb_endpoint_implicit_feedback_sink(ep)) { ... }" causes the system to wait to send output until some capture urbs are received. As a result, both sides end up waiting on the other, and nothing happens. Simply commenting out that "if" block makes the GT-1 work perfectly with implicit feedback enabled. I plan to submit a patch for this after I do a bit of legwork to see if the fix works for other recent Boss devices (Katana, other GT devices, etc.). Perhaps making the relevant "if" block conditional on a flag, with a USB_ID switch statement to set the flag? Any feedback would be welcome. Thanks, Mike

2 1

Enable Headset Mic for Dell desktop
by Kailang 20 Feb '20

20 Feb '20

Hi Takashi, Attach patch was supported headset Mic. BR, Kailang

1 0

usage of snd_rawmidi_status_get_avail()
by GitHub issues - edited 20 Feb '20

20 Feb '20

alsa-project/alsa-lib issue #26 was edited from MusicMaker: In non blocked raw MIDI, is snd_rawmidi_status_get_avail supposed to return the number of available bytes that can be read using a snd_rawmidi_read. (port is opened for input only) It seems get_avail always returns 0 even there is MIDI data when using a read. Else is there a(nother) way to find the number of unread received bytes in the buffer? snd_rawmidi_status_alloca (&status); snd_rawmidi_status(client, status); snd_rawmidi_status_get_avail(status); Issue URL : https://github.com/alsa-project/alsa-lib/issues/26 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

usage of snd_rawmidi_status_get_avail()
by GitHub issues - edited 20 Feb '20

20 Feb '20

alsa-project/alsa-lib issue #26 was edited from MusicMaker: In non blocked raw MIDI, is snd_rawmidi_status_get_avail supposed to return the number of available bytes that can be read using a snd_rawmidi_read. (port is opened for read only) It seems get_avail always returns 0 even there is MIDI data when using a read. Else is there a(nother) way to find the number of unread received bytes in the buffer? snd_rawmidi_status_alloca (&status); snd_rawmidi_status(client, status); snd_rawmidi_status_get_avail(status); Issue URL : https://github.com/alsa-project/alsa-lib/issues/26 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

usage of snd_rawmidi_status_get_avail()
by GitHub issues - edited 20 Feb '20

20 Feb '20

alsa-project/alsa-lib issue #26 was edited from MusicMaker: In non blocked raw MIDI, is snd_rawmidi_status_get_avail supposed to return the number of available bytes that can be read via snd_rawmidi_read. (port is opened for read only) It seems get_avail always returns 0 even there is MIDI data when using a read. Else is there a(nother) way to find the number of unread received bytes in the buffer? snd_rawmidi_status_alloca (&status); snd_rawmidi_status(client, status); snd_rawmidi_status_get_avail(status); Issue URL : https://github.com/alsa-project/alsa-lib/issues/26 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

usage of snd_rawmidi_status_get_avail()
by GitHub issues - edited 20 Feb '20

20 Feb '20

alsa-project/alsa-lib issue #26 was edited from MusicMaker: In non blocked raw MIDI, is snd_rawmidi_status_get_avail supposed to return the number of available bytes than can read via snd_rawmidi_read. (port is opened for read only) It seems get_avail always returns 0 even there is MIDI data when using a read. Else is there a(nother) way to find the number of unread received bytes in the buffer? snd_rawmidi_status_alloca (&status); snd_rawmidi_status(client, status); snd_rawmidi_status_get_avail(status); Issue URL : https://github.com/alsa-project/alsa-lib/issues/26 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

usage of snd_rawmidi_status_get_avail()
by GitHub issues - edited 20 Feb '20

20 Feb '20

alsa-project/alsa-lib issue #26 was edited from MusicMaker: In non blocked raw MIDI, is snd_rawmidi_status_get_avail supposed to return the number of available bytes than can read via snd_rawmidi_read. (port is opened for read only) It seems always return 0 even there is MIDI data when using a read. Else is there a(nother) way to find the number of unread received bytes in the buffer? snd_rawmidi_status_alloca (&status); snd_rawmidi_status(client, status); snd_rawmidi_status_get_avail(status); Issue URL : https://github.com/alsa-project/alsa-lib/issues/26 Repository URL: https://github.com/alsa-project/alsa-lib

1 0