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

[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

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

20 Feb '20

alsa-project/alsa-lib issue #26 was opened from MusicMaker: In non blocked raw MIDI mode, 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

sytem reboots when initializing Edirol FA-101 firewire audio interface
by Steve Morris 20 Feb '20

20 Feb '20

Hi All, I'm running Arch Linux x86_64 My system consistently reboots when I power on my FA-101 when running kernels 5.5.1-4. Downgrading to 5.4.15 allows everything to work properly. Here's the outpu of: journalctl | grep -E 'Reboot|firewire|fw|bebob|alsa|jack' This is a good init under 5.4.15: -- Reboot -- powered on interface while running 5.4.15, initialized properly Feb 18 18:35:37 hostname kernel: firewire_ohci 0000:05:00.0: enabling device (0080 -> 0083) Feb 18 18:35:37 hostname kernel: firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 0, 4 IR + 8 IT contexts, quirks 0x11 Feb 18 18:35:37 hostname kernel: firewire_core 0000:05:00.0: created device fw0: GUID 0011223333666677, S400 Feb 18 18:35:37 hostname systemd-udevd[541]: controlC0: Process '/usr/bin/alsactl restore 0' failed with exit code 99. Feb 18 18:35:37 hostname systemd-udevd[541]: controlC1: Process '/usr/bin/alsactl restore 1' failed with exit code 99. Feb 18 18:35:38 hostname kernel: amdgpu: [powerplay] smu driver if version = 0x00000033, smu fw if version = 0x00000035, smu fw version = 0x002a3200 (42.50.0) Feb 18 18:36:08 hostname kernel: firewire_ohci 0000:05:00.0: isochronous cycle inconsistent Feb 18 18:36:08 hostname kernel: firewire_core 0000:05:00.0: created device fw1: GUID 0040ab0000c20bc1, S400 Feb 18 18:36:08 hostname kernel: firewire_core 0000:05:00.0: phy config: new root=ffc1, gap_count=5 Feb 18 18:36:10 hostname kernel: firewire_core 0000:05:00.0: BM lock failed (timeout), making local node (ffc0) root Feb 18 18:36:10 hostname kernel: firewire_core 0000:05:00.0: phy config: new root=ffc0, gap_count=5 Feb 18 18:36:12 hostname systemd-udevd[1532]: controlC2: Process '/usr/bin/alsactl restore 2' failed with exit code 99. Feb 18 18:36:15 hostname kernel: snd-bebob fw1.0: transaction failed: no ack Feb 18 18:36:15 hostname kernel: snd-bebob fw1.0: fail to get an input for MSU in plug 7: -5 Feb 18 18:36:15 hostname kernel: snd-bebob fw1.0: transaction failed: no ack Feb 18 18:36:15 hostname kernel: snd-bebob fw1.0: fail to get an input for MSU in plug 7: -5 This is a bad init under 5.5.4: -- Reboot -- Powered on interface when machine was running. Feb 18 18:13:37 hostname kernel: firewire_ohci 0000:05:00.0: enabling device (0080 -> 0083) Feb 18 18:13:37 hostname kernel: firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 0, 4 IR + 8 IT contexts, quirks 0x11 Feb 18 18:13:37 hostname kernel: firewire_core 0000:05:00.0: created device fw0: GUID 0011223333666677, S400 Feb 18 18:13:37 hostname kernel: audit: type=1130 audit(1582078417.360:3): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=ufw comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Feb 18 18:13:37 hostname audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=ufw comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Feb 18 18:13:37 hostname systemd-udevd[539]: controlC0: Process '/usr/bin/alsactl restore 0' failed with exit code 99. Feb 18 18:13:37 hostname systemd-udevd[530]: controlC1: Process '/usr/bin/alsactl restore 1' failed with exit code 99. Feb 18 18:13:38 hostname kernel: amdgpu: [powerplay] smu driver if version = 0x00000033, smu fw if version = 0x00000035, smu fw version = 0x002a3200 (42.50.0) Feb 18 18:19:45 hostname kernel: firewire_core 0000:05:00.0: phy config: new root=ffc1, gap_count=5 Feb 18 18:19:48 hostname kernel: firewire_core 0000:05:00.0: phy config: new root=ffc1, gap_count=5 Feb 18 18:19:48 hostname kernel: firewire_core 0000:05:00.0: created device fw1: GUID 0040ab0000c20bc1, S400 Feb 18 18:19:52 hostname systemd-udevd[1682]: controlC2: Process '/usr/bin/alsactl restore 2' failed with exit code 99. Feb 18 18:20:08 hostname kernel: snd-bebob fw1.0: transaction failed: no ack Feb 18 18:20:08 hostname kernel: snd-bebob fw1.0: fail to get an input for MSU in plug 7: -5 Feb 18 18:20:08 hostname kernel: snd-bebob fw1.0: transaction failed: no ack Feb 18 18:20:08 hostname kernel: snd-bebob fw1.0: fail to get an input for MSU in plug 7: -5 Feb 18 18:20:12 hostname kernel: firewire_core 0000:05:00.0: phy config: new root=ffc1, gap_count=5 Feb 18 18:21:24 hostname kernel: firewire_ohci 0000:05:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0001 address=0xd5080000 flags=0x0000] Followed by 125 more O_PAGE_FAULT and then the reboot, I'll be happy to provide additional information if needed. Steve

2 1