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

[alsa-devel] [PATCH] ALSA: hda/realtek - There is no loopback mixer in the ALC234/274/294
by Hui Wang 26 Jun '17

26 Jun '17

We have a Lenovo machine with the codec ALC294 on it, without the patch, the Node 0x0b is regarded as the loopback mixer, but the Node 0x0b in this codec is "Vendor Defined Widget" instead of the audio mixer, please see the log below: Node 0x0b [Vendor Defined Widget] wcaps 0xf00000: Mono Control: name="Beep Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=4, ofs=0 Control: name="Beep Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=4, ofs=0 And I have consulted with Realtek, so far the ALC234/274/294 all don't have loopback mixer. Cc: Kailang Yang <kailang(a)realtek.com> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index c4a1b49..bc00a37 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6696,6 +6696,7 @@ static int patch_alc269(struct hda_codec *codec) case 0x10ec0274: case 0x10ec0294: spec->codec_variant = ALC269_TYPE_ALC294; + spec->gen.mixer_nid = 0; /* ALC2x4 does not have any loopback mixer path */ alc_update_coef_idx(codec, 0x6b, 0x0018, (1<<4) | (1<<3)); /* UAJ MIC Vref control by verb */ break; case 0x10ec0700: -- 2.7.4

2 1

[alsa-devel] [RFC 0/x v2] ASoC: replace platform to component
by Kuninori Morimoto 26 Jun '17

26 Jun '17

Hi Mark, Lars-Peter These are v2 of platform replace patch-set. Big difference is that from version, rtd can have component list. As you know, current rtd has platform, codec, and this patch replace rtd->platform into component list. We can replace codec in same style in the future. This patch-set adds new snd_soc_rtdcom_lookup(). So, current struct snd_soc_platform *platform = rtd->platform; will be replaced into struct snd_soc_component *component = snd_soc_rtdcom_lookup(rtd, DRIVER_NAME); 1 rtd doesn't detect same component multiple times, I guess. Thus, lookup by driver name should be OK. Current framework is listing component to card (it was originally codec) by component_dev_list. And it is used in soc-pcm.c list_for_each_entry(component, &rtd->card->component_dev_list, card_list) { ... } But it is not correct I think. card can have multiple runtimes, and runtime can have multiple components. Thus, I think we can do below case ? Card -+-> runtime1 -> component1 + component2 +-> runtime2 -> component1 + component2 +-> runtime3 -> component1 + component3 Current list_for_each_entry() will call component1/2/3, but runtime1 needs component1/2 only, for example. It is connecting all components to card by component_dev_list. OTOH, all runtimes are listed to card by rtd_list. This patch lists component to runtime. I think we can replace component_dev_list into for_each_rtdcom(rtd, rtdcom) { component = rtdcom->component; ... } 1) - 5) : prepare to replace 6) - 8) : sample of platform -> component replace 9) : remove platform Kuninori Morimoto (9): 1) ASoC: soc-core: add component remove/unregister_exp/lookup functions 2) ASoC: soc-devres: use expanded unregister on devm register component 3) ASoC: soc-core: add snd_soc_rtdcom_xxx() 4) ASoC: snd_soc_component_driver has snd_pcm_ops 5) ASoC: snd_soc_component_driver has snd_compr_ops 6) ASoC: replace platform to component on rsnd 7) ASoC: replace platform to component on soc-utils 8) ASoC: replace platform to component on soc-generic-dmaengine-pcm 9) ASoC: remove platform related things Best regards --- Kuninori Morimoto

1 9

[alsa-devel] additional high input device for snd-dice (A&H Zed R16)
by Allan Klinbail 26 Jun '17

26 Jun '17

Hi, I noticed on the changelog that some devices are able to access all channels without doing any .asoundrc funkiness. Form 4.6 kernel onwards - Add support for previously unavailable higher PCM channels on certain devices with high channel count, notably Focusrite Saffire PRO 40, Focusrite Liquid Saffire 56, and TC Electronic Studio Konnekt 48. These devices spread the PCM and MIDI channels across 2 tx + 2 rx IEEE 1394 channels instead of just 1 tx + 1 rx IEEE 1394 channel, as most other devices do. Pretty sure I've tested with 4.6 and wasn't able to achieve this with my device. But can test again with 4.8 if I am wrong. My device is an Allen and Heath Zed R16.. While latency performance in the way ALSA works is not satisfactory for my usage others may wish to use this device with ALSA for simplicity. (remove the need for FFADO entirely as there is no software mixer for this device and remove the need for any MIDI bridge) Currently under ALSA in 44.1k or 48k the device has 16 inputs and 16 outputs on the first firewire channel, and then and additional 10 ins and 10 outs on the second. If this is any help, here is the vendor info, as used by FFADO { # Allen and Heath Zed R16. Information from Brendan Pike. vendorid = 0x000004C4; modelid = 0x00000000; vendorname = "Allen and Heath"; modelname = "Zed R16"; driver = "DICE"; mixer = "Generic_Dice_EAP"; } On that latency topic- just voicing my opinion and I don't expect change. When the paradigm of using periods/frames and buffers is common across all OS and driver platforms, I don't believe that the driver should force developers to implement a new method, even if there are better ways of doing things. That might be okay for small open source projects, but bigger commercial applications would not be likely to maintain separate configuration options for Linux, they are more likely to drop Linux altogether if forced to adopt I also know that Takashi S, does not agree but as FFADO devs have agreed to keep the driver in FFADO I don't mind..

2 3

[alsa-devel] [PATCH] ASoC: nau8825: debug message of crosstalk bypass
by John Hsu 26 Jun '17

26 Jun '17

Add debug message for crosstalk function bypass. Signed-off-by: John Hsu <KCHSU0(a)nuvoton.com> Signed-off-by: John Hsu <supercraig0719(a)gmail.com> --- sound/soc/codecs/nau8825.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/codecs/nau8825.c b/sound/soc/codecs/nau8825.c index a8c7a55..80bae48 100644 --- a/sound/soc/codecs/nau8825.c +++ b/sound/soc/codecs/nau8825.c @@ -2440,6 +2440,8 @@ static void nau8825_print_device_properties(struct nau8825 *nau8825) nau8825->jack_insert_debounce); dev_dbg(dev, "jack-eject-debounce: %d\n", nau8825->jack_eject_debounce); + dev_dbg(dev, "crosstalk-bypass: %d\n", + nau8825->xtalk_bypass); } static int nau8825_read_device_properties(struct device *dev, -- 2.6.4

1 0

Re: [alsa-devel] Fix bug in arecord --max-file-time where the file size could overflow 32 bits
by John Sauter 24 Jun '17

24 Jun '17

> Date: Fri, 23 Jun 2017 18:35:03 +0000 > From: "Gilliland, Scott M" <scott.gilliland(a)gatech.edu> > To: "alsa-devel(a)alsa-project.org" <alsa-devel(a)alsa-project.org> > Subject: [alsa-devel] [PATCH] Fix bug in arecord --max-file-time > where > the file size could overflow 32 bits > Message-ID: > <CY4PR07MB3544F3467606CB0401C3F0918DD80(a)CY4PR07MB3544.namprd07. > prod.outlook.com> > > Content-Type: text/plain; charset="iso-8859-1" > > From: Scott Gilliland <scott.gilliland(a)gatech.edu> > > Fix bug in arecord --max-file-time where the file size could overflow > 32 bits > > Signed-off-by: Scott Gilliland <scott.gilliland(a)gatech.edu> > --- > aplay/aplay.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/aplay/aplay.c b/aplay/aplay.c > index f793c82..00af662 100644 > --- a/aplay/aplay.c > +++ b/aplay/aplay.c > @@ -3027,7 +3027,7 @@ static void capture(char *orig_name) > if (count == 0) > count = LLONG_MAX; > /* compute the number of bytes per file */ > - max_file_size = max_file_time * > + max_file_size = (long long) max_file_time * > snd_pcm_format_size(hwparams.format, > hwparams.rate * > hwparams.channels); > /* WAVE-file should be even (I'm not sure), but wasting one > byte > -- > 2.11.0 Thank you for fixing this bug, which I introduced in 2010 through failing to understand the type conversion rules of C. Acked-by: John Sauter <John_Sauter(a)systemeyescomputerstore.com> -- PGP fingerprint E24A D25B E5FE 4914 A603 49EC 7030 3EA1 9A0B 511E

1 0

[alsa-devel] [PATCH 0/2] Lenovo tablet fixes
by Pierre-Louis Bossart 23 Jun '17

23 Jun '17

2 patches to enable rt5670 on Baytrail and fix jack detection. There are likely follow-up patches or UCM updates needed since some users report additional problems with headphones and subwoofers [1] but this is already working for a number of people. [1] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96691 Pierre-Louis Bossart (2): ASoC: Intel: cht_bsw_rt5672: 19.2MHz clock for Baytrail platforms ASoC: codecs: rt5670: fix jd mode for Lenovo Miix 2 10 sound/soc/codecs/rt5670.c | 9 ++++ sound/soc/intel/boards/cht_bsw_rt5672.c | 89 +++++++++++++++++++++++++++++---- 2 files changed, 89 insertions(+), 9 deletions(-) -- 2.9.3

1 2

[alsa-devel] Bug in ALSA-utils/arecord with --max-file-time
by Gilliland, Scott M 23 Jun '17

23 Jun '17

Hi All, I seem to have found a minor bug in aplay, within alsa-utils 1.1.4. It's possible that I'm the first person who's ever hit it. This appears to be the correct place to report it; if not, I humbly apologize, and ask for direction on where to submit this. In aplay.c, around line 3030, we do this calculation: max_file_size = max_file_time * snd_pcm_format_size(hwparams.format, hwparams.rate * hwparams.channels); We do this to convert max_file_time from the '--max-file-time' parameter (an int) into max_file_size, a file length in bytes (a long long). Since snd_pcm_format_size() may return something 32-bit, this might overflow 32-bits when we do the multiplication, wasting the extra bytes of max_file_size. On my test case on an armv7l system, a 1800-second file at 192 KHz recorded in S24_3LE doesn't overflow, but recording in S32_LE does. I accidentally found an edge case. In case anyone wants to know, the failure mode is that arecord will repeatedly create 44 byte .wav files very quickly, since these are larger than the negative max file size. This continues until you have a directory full of thousands of 44-byte files. Hilarious. A simple change to cast max_file_time to a long long fixes this in my test case. There might be some cleaner solution, but this at least worked for me. max_file_size = (long long) max_file_time * snd_pcm_format_size(hwparams.format, hwparams.rate * hwparams.channels); Hopefully someone can vet this and carry it over to git. I've attached a patch file as well. -- Additionally, while working to report this, I noticed that the bug tracker link on the sidebar of https://www.alsa-project.org/main/index.php/Main_Page is a dead link. -Scott -- Scott Gilliland imtc.gatech.edu/people/scott-gilliland

2 3

Re: [alsa-devel] [PATCH] ASoC: rt5645: enable speaker protection features
by Mark Brown 23 Jun '17

23 Jun '17

On Fri, Jun 23, 2017 at 01:55:29PM +0000, Bard Liao wrote: > > On Fri, Jun 23, 2017 at 10:24:57AM +0800, Bard Liao wrote: > > You shouldn't be changing the register defaults away from the physical > > defaults, just do it with a normal register write. Changing the > > defaults will break cache resyncing. > Agree. The reason I did it is the register will also be modified by > regmap_register_patch. If it goes in via a normal write it'll still get restored, just as part of the regular cache writeout on resume.

1 0

[alsa-devel] Query regarding possibility of PM QoS unvote/vote when substream Pause/Resume called
by bgoswami＠codeaurora.org 23 Jun '17

23 Jun '17

Hi, Current ALSA core implementation has PM QoS vote/unvote calls in snd_pcm_hw_params() and snd_pcm_hw_free(). However, this might have an implication in terms of power, as PM QoS vote would still be valid for that substream, even when the substream is paused. Especially for those cases, where, to avoid missing the QoS, one or more CPU cores might be prevented from entering into lower power mode (or power-collapse), as it might take longer to bring those cores out of power collapse. This might be specially more prominent when the period size is smaller. So, in an effort to optimize power (by whatever smaller amount), I was wondering, if it is better to remove the PM QoS vote (pm_qos_remove_request) when Pause (SNDRV_PCM_TRIGGER_PAUSE_PUSH) is called from user space (using IOCTL) for a particular substream. Similarly, PM QoS vote can be added (pm_qos_add_request) back, when user space (using IOCTL) calls Resume (SNDRV_PCM_TRIGGER_PAUSE_RELEASE) for that same substream. I am looking for opinions from subject matter experts, to see if the proposed approach might have any unintended side-effects or any known limitation that I might be missing. Thanks and Regards, Banajit Goswami The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

2 1

[alsa-devel] [PATCH v2 0/3] ALSA: Add the explicit appl_ptr sync support
by Takashi Iwai 23 Jun '17

23 Jun '17

Hi, this is a revised patchset for supporting the explicit appl_ptr update. Since the protocol version from user-space needs to be stored locally for each opened file, the check of status/control mmap was slightly changed as well. But the basic strategy is same as the previous patchset. Note that this patchset doesn't solve the issue that appl_ptr update isn't properly notified to ack ops as Sakamoto-san pointed out previously. We'll still need to sort it out. But the hack I introduced here doesn't basically conflict with it, and it'll even make it easier to solve later, by the new USER_PVERSION ioctl. thanks, Takashi === Takashi Iwai (3): ALSA: pcm: Add the explicit appl_ptr sync support ALSA: pcm: Add an ioctl to specify the supported protocol version ALSA: pcm: Limit the appl_ptr sync workaround only for old user-space include/sound/pcm.h | 1 + include/uapi/sound/asound.h | 4 +++- sound/core/pcm_compat.c | 1 + sound/core/pcm_native.c | 34 ++++++++++++++++++++++++++++++++-- 4 files changed, 37 insertions(+), 3 deletions(-) -- 2.13.1

2 5