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

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

[PATCH 0/3] ASoC: snprintf() usage fixes
by Takashi Iwai 19 Feb '20

19 Feb '20

Hi, this is a series of patches I spotted during debugging other code. Intel skl and ASoC PCM core invokes succeeding calls of snprintf() with the incorrect expectation of the return value, which may lead to a buffer overflow. The first patch is yet another bug I found during working on this, and it's rather a real bug that can be seen clearly. Takashi === Takashi Iwai (3): ASoC: intel: skl: Fix pin debug prints ASoC: intel: skl: Fix possible buffer overflow in debug outputs ASoC: pcm: Fix possible buffer overflow in dpcm state sysfs output sound/soc/intel/skylake/skl-debug.c | 32 +++++++++++++++++--------------- sound/soc/soc-pcm.c | 16 ++++++++-------- 2 files changed, 25 insertions(+), 23 deletions(-) -- 2.16.4

3 7

[PATCH v2] ASoC: MT6660 update to 1.0.8_G
by Jeff Chang 19 Feb '20

19 Feb '20

From: Jeff Chang <jeff_chang(a)richtek.com> 1. add mt6660_component_settign for Component INIT Setting Signed-off-by: Jeff Chang <jeff_chang(a)richtek.com> --- sound/soc/codecs/mt6660.c | 78 +++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 75 insertions(+), 3 deletions(-) changelogs between v2 & v1 - remove parse DT and apply function about Chip INIT SETTING. - use hard coding for MT6660 Component INIT SETTING. diff --git a/sound/soc/codecs/mt6660.c b/sound/soc/codecs/mt6660.c index a36c416..88cf228 100644 --- a/sound/soc/codecs/mt6660.c +++ b/sound/soc/codecs/mt6660.c @@ -9,7 +9,6 @@ #include <linux/i2c.h> #include <linux/pm_runtime.h> #include <linux/delay.h> -#include <linux/debugfs.h> #include <sound/soc.h> #include <sound/tlv.h> #include <sound/pcm_params.h> @@ -225,14 +224,87 @@ static int _mt6660_chip_power_on(struct mt6660_chip *chip, int on_off) 0x01, on_off ? 0x00 : 0x01); } +struct reg_table { + uint32_t addr; + uint32_t mask; + uint32_t val; +}; + +static const struct reg_table mt6660_setting_table[] = { + { 0x20, 0x80, 0x00 }, + { 0x30, 0x01, 0x00 }, + { 0x50, 0x1c, 0x04 }, + { 0xB1, 0x0c, 0x00 }, + { 0xD3, 0x03, 0x03 }, + { 0xE0, 0x01, 0x00 }, + { 0x98, 0x44, 0x04 }, + { 0xB9, 0xff, 0x82 }, + { 0xB7, 0x7777, 0x7273 }, + { 0xB6, 0x07, 0x03 }, + { 0x6B, 0xe0, 0x20 }, + { 0x07, 0xff, 0x70 }, + { 0xBB, 0xff, 0x20 }, + { 0x69, 0xff, 0x40 }, + { 0xBD, 0xffff, 0x17f8 }, + { 0x70, 0xff, 0x15 }, + { 0x7C, 0xff, 0x00 }, + { 0x46, 0xff, 0x1d }, + { 0x1A, 0xffffffff, 0x7fdb7ffe }, + { 0x1B, 0xffffffff, 0x7fdb7ffe }, + { 0x51, 0xff, 0x58 }, + { 0xA2, 0xff, 0xce }, + { 0x33, 0xffff, 0x7fff }, + { 0x4C, 0xffff, 0x0116 }, + { 0x16, 0x1800, 0x0800 }, + { 0x68, 0x1f, 0x07 }, +}; + +static int mt6660_component_setting(struct snd_soc_component *component) +{ + struct mt6660_chip *chip = snd_soc_component_get_drvdata(component); + int ret = 0; + size_t i = 0; + + ret = _mt6660_chip_power_on(chip, 1); + if (ret < 0) { + dev_err(component->dev, "%s chip power on failed\n", __func__); + return ret; + } + + for (i = 0; i < ARRAY_SIZE(mt6660_setting_table); i++) { + ret = snd_soc_component_update_bits(component, + mt6660_setting_table[i].addr, + mt6660_setting_table[i].mask, + mt6660_setting_table[i].val); + if (ret < 0) { + dev_err(component->dev, "%s update 0x%02x failed\n", + __func__, mt6660_setting_table[i].addr); + return ret; + } + } + + ret = _mt6660_chip_power_on(chip, 0); + if (ret < 0) { + dev_err(component->dev, "%s chip power off failed\n", __func__); + return ret; + } + + return 0; +} + static int mt6660_component_probe(struct snd_soc_component *component) { struct mt6660_chip *chip = snd_soc_component_get_drvdata(component); + int ret; dev_dbg(component->dev, "%s\n", __func__); snd_soc_component_init_regmap(component, chip->regmap); - return 0; + ret = mt6660_component_setting(component); + if (ret < 0) + dev_err(chip->dev, "mt6660 component setting failed\n"); + + return ret; } static void mt6660_component_remove(struct snd_soc_component *component) @@ -506,4 +578,4 @@ module_i2c_driver(mt6660_i2c_driver); MODULE_AUTHOR("Jeff Chang <jeff_chang(a)richtek.com>"); MODULE_DESCRIPTION("MT6660 SPKAMP Driver"); MODULE_LICENSE("GPL"); -MODULE_VERSION("1.0.7_G"); +MODULE_VERSION("1.0.8_G"); -- 2.7.4

2 1