March 2016 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH] sound/usb: fix to release stream resources from media_snd_device_delete()
by Shuah Khan 22 Mar '16

22 Mar '16

Fix to release stream resources from media_snd_device_delete() before media device is unregistered. Without this change, stream resource free is attempted after the media device is unregistered which would result in use-after-free errors. Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> --- - Ran bind/unbind loop (1000 iteration) test on snd-usb-audio while running mc_nextgen_test loop (1000 iterations) in parallel. - Ran bind/unbind and rmmod/modprobe tests on both drivers. Also generated graphs when after bind/unbind, rmmod/modprobe. Graphs look good. - Note: Please apply the following patch to fix memory leak: sound/usb: Fix memory leak in media_snd_stream_delete() during unbind https://lkml.org/lkml/2016/3/16/1050 sound/usb/media.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/usb/media.c b/sound/usb/media.c index de4a815..e35af88 100644 --- a/sound/usb/media.c +++ b/sound/usb/media.c @@ -301,6 +301,13 @@ int media_snd_device_create(struct snd_usb_audio *chip, void media_snd_device_delete(struct snd_usb_audio *chip) { struct media_device *mdev = chip->media_dev; + struct snd_usb_stream *stream; + + /* release resources */ + list_for_each_entry(stream, &chip->pcm_list, list) { + media_snd_stream_delete(&stream->substream[0]); + media_snd_stream_delete(&stream->substream[1]); + } media_snd_mixer_delete(chip); -- 2.5.0

2 9

[alsa-devel] [PATCH V2 0/6] alsabat: clean structure and tinyalsa support
by han.lu＠intel.com 22 Mar '16

22 Mar '16

From: "Lu, Han" <han.lu(a)intel.com> 1. refactoring alsa process to make structure simpler and cleaner, use general functions and unified return value for convenience of maintaining; 2. add tinyalsa support, user can choose tinyalsa with "configure --enable-tinyalsa" option. By default ALSA lib is used. The purpose is for alsabat to run on tinyalsa platforms such as Android and some IoT devices. Lu, Han (6): alsabat: refactoring alsa capture thread alsabat: use general function for wav header update alsabat: clean return value for playback and capture threads alsabat: use general data generator function alsabat: move alsa process to a single block alsabat: add tinyalsa support bat/Makefile.am | 12 +- bat/alsa.c | 217 +++++++++++--------------- bat/alsabat.1 | 3 + bat/bat.c | 58 +++---- bat/common.c | 68 +++++++++ bat/common.h | 17 ++- bat/signal.c | 13 +- bat/tinyalsa.c | 460 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ bat/tinyalsa.h | 20 +++ configure.ac | 17 +++ 10 files changed, 711 insertions(+), 174 deletions(-) create mode 100644 bat/tinyalsa.c create mode 100644 bat/tinyalsa.h -- 2.5.0

2 7

[alsa-devel] [PATCH 0/6] *** alsabat: clean structure and tinyalsa support ***
by han.lu＠intel.com 22 Mar '16

22 Mar '16

From: "Lu, Han" <han.lu(a)intel.com> 1. Clean structure, use general function to replace local processes. 2. Add tinyalsa support, configure will read environment and decide to link to ALSA lib or tinyalsa lib. Lu, Han (6): alsabat: clean file process on capture thread loop alsabat: use common wav process function in playback loop alsabat: clean return value of playback and capture loops alsabat: use common data generator function alsabat: move alsa process to alsa.c alsabat: add tinyalsa support bat/Makefile.am | 12 +- bat/alsa.c | 217 +++++++++++--------------- bat/alsabat.1 | 3 + bat/bat.c | 58 +++---- bat/common.c | 68 +++++++++ bat/common.h | 17 ++- bat/signal.c | 13 +- bat/tinyalsa.c | 460 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ bat/tinyalsa.h | 20 +++ configure.ac | 4 + 10 files changed, 698 insertions(+), 174 deletions(-) create mode 100644 bat/tinyalsa.c create mode 100644 bat/tinyalsa.h -- 2.5.0

3 10

[alsa-devel] [PATCH] ALSA: timer: fix another ioctl compatibility bug
by Takashi Sakamoto 22 Mar '16

22 Mar '16

Hi, In ALSA timer interface, I found another compatibility bug to different ABIs. This patch is to fix it. I note that the bug is in really, really-minor functionality and no drivers use it, therefore it has little impact to this subsystem. This patch is just for manners between kernel/userspace interfaces. To check the compatibility, I wrote a series of easy and small programs for each ALSA interface. It's available in my repository on github. https://github.com/takaswie/alsa-ioctl-test As long as I tested with these programs, this patch is the last fix for the compatibility issues which comes from differences of data model. On the other hand, I confirmed that each compatibility layer is not fully compatible to core implementation. For example, ioctl() with SNDRV_PCM_IOCTL_WRITEI_FRAMES and argument filled by zero for PCM capture character device (not for playback device) returns different error codes for each of x86/x86_64 binary. I think this should be fixed, but don't start to work for it yet. Regards Takashi Sakamoto (1): ALSA: timer: fix ioctl compatibility for different data models sound/core/timer_compat.c | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) -- 2.7.3

2 3

[alsa-devel] [PATCH 0/7] Intel HD-audio HDMI codec driver rewrites
by Takashi Iwai 22 Mar '16

22 Mar '16

Hi, here is a patch series for rewrite / cleanup of Intel HD-audio codec driver. The main purpose of this patchset is to re-add the support of i915 ELD notification for old chipsets. For that, it starts from the cleanup of the HDMI codec driver code to get rid of excessive usages of is_*() macros. Then the fixes for supporting the old chips in HDA core side and HDMI codec driver side. Although this could be included for 4.6, my current plan is to postpone this for 4.7. Takashi === Takashi Iwai (7): ALSA: hda - Split out Intel-specific codes from patch_generic_hdmi() ALSA: hda - Apply AMP fix in hdmi_setup_audio_infoframe() generically ALSA: hda - Override HDMI setup_stream ops for Intel HSW+ ALSA: hda - Introduce pin_cvt_fixup() ops to hdmi parser ALSA: hda - Use eld notifier for Intel SandyBridge and IvyBridge HDMI/DP ALSA: hda - Add the pin / port mapping on Intel ILK and VLV ALSA: hda - Enable i915 ELD notifier for Intel IronLake and Baytrail include/sound/hda_i915.h | 10 +- sound/hda/hdac_i915.c | 45 ++++-- sound/pci/hda/patch_hdmi.c | 373 ++++++++++++++++++++++++++++++--------------- 3 files changed, 293 insertions(+), 135 deletions(-) -- 2.7.4

1 7

[alsa-devel] [PATCH 0/3] *** Some trival fixes on alsabat ***
by han.lu＠intel.com 21 Mar '16

21 Mar '16

From: "Lu, Han" <han.lu(a)intel.com> Fix misusing of errno, fopen, prints and return value Lu, Han (3): alsabat: fix misusing of errno alsabat: fix fopen and messages alsabat: use variable for thread return value bat/alsa.c | 50 ++++++++++++++++++++++++++------------------------ bat/analyze.c | 6 +++--- bat/bat.c | 39 ++++++++++++++++++++++----------------- bat/common.c | 1 - 4 files changed, 51 insertions(+), 45 deletions(-) -- 2.5.0

2 4

[alsa-devel] [PATCH 0/2] ASoC: codecs: add support for TAS5720 digital amplifier
by Andreas Dannenberg 21 Mar '16

21 Mar '16

Driver for TI's TAS5720L/M digital audio amplifiers. The driver should be pretty standard except the optional interrupt-based fault reporting. Some background on the fault reporting since that might be a discussion of interest. The code should have that documented rather well but I wanted to bring it up right away. The TAS5720 devices can report conditions such as over-current (short), over temp, and others that can be important to know in a real-world system. However the device lacks a way to mask the generation of fault interrupts except by shutting it down, which can lead to cases where the device generates SAIF-fault host interrupts every 300us! This is clearly a lot of overhead to be thrown at the SoC (and my bench testing has demonstrated that) so after trying different things to tame this behavior I ended up implementing method to disable/enable the interrupts in the driver itself in combination with rate-limiting the processing of those events. The fact of processing interrupts in a threaded fashion (IRQF_ONESHOT) alone was not enough under certain conditions to prevent the SoC from not being able to get to all interrupts even with an empty threaded handler, and it would freeze and eventually the Kernel would disable the interrupt ("no one cared"). The scheme currently implemented seems to work reliably cycling different audio files over hours also forcing error conditions. But if anybody has a "cleaner" idea how to rate-limit IRQs on a very low level (currently done in the IRQ handler function) I'm absolutely open to suggestions. This all may not be an issue at all when using a faster/lower-latency SoC than what I'm using (BeagleBone Black) but the fact that IRQF_ONESHOT alone was not enough to prevent the system to be brought to its knees (again, even with an empty threaded handler) was a bit of a surprise to me. -- Andreas Dannenberg Texas Instruments Inc Andreas Dannenberg (2): ASoC: codecs: add TA5720 digital amplifier DT bindings ASoC: codecs: add support for TAS5720 digital amplifier .../devicetree/bindings/sound/tas5720.txt | 37 ++ sound/soc/codecs/Kconfig | 10 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/tas5720.c | 733 +++++++++++++++++++++ sound/soc/codecs/tas5720.h | 90 +++ 5 files changed, 872 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/tas5720.txt create mode 100644 sound/soc/codecs/tas5720.c create mode 100644 sound/soc/codecs/tas5720.h -- 2.6.4

2 4

[alsa-devel] New snd-hda warning spew
by Ville Syrjälä 21 Mar '16

21 Mar '16

We have a few new WARN spews from snd-hda causing some grief in i915 CI. This one happens on ILK and BYT. Looks like it happens 100% of the time on driver load: [ 18.809850] ------------[ cut here ]------------ [ 18.809866] WARNING: CPU: 0 PID: 39 at sound/hda/hdac_i915.c:129 pin2port+0x25/0x30 [snd_hda_core]() [ 18.809869] Modules linked in: ax88179_178a usbnet mii intel_powerclamp coretemp crct10dif_pclmul i915 snd_hda_codec_hdmi snd_hda_codec_generic crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm mei_me mei lpc_ich sdhci_pci sdhci mmc_core e1000e ptp pps_core [ 18.809903] CPU: 0 PID: 39 Comm: kworker/0:1 Not tainted 4.5.0-gfxbench+ #1 [ 18.809905] Hardware name: Hewlett-Packard HP EliteBook 8440p/172A, BIOS 68CCU Ver. F.24 09/13/2013 [ 18.809912] Workqueue: events azx_probe_work [snd_hda_intel] [ 18.809915] 0000000000000000 ffff8800b646b9e8 ffffffff813fef15 0000000000000000 [ 18.809920] ffffffffa00f277c ffff8800b646ba20 ffffffff81078a21 ffff8800b2436000 [ 18.809924] ffff8800b24755e8 ffff8800b24755f0 0000000000000100 ffff8800aed08330 [ 18.809929] Call Trace: [ 18.809936] [<ffffffff813fef15>] dump_stack+0x67/0x92 [ 18.809942] [<ffffffff81078a21>] warn_slowpath_common+0x81/0xc0 [ 18.809945] [<ffffffff81078b15>] warn_slowpath_null+0x15/0x20 [ 18.809953] [<ffffffffa00f12d5>] pin2port+0x25/0x30 [snd_hda_core] [ 18.809960] [<ffffffffa00f1378>] snd_hdac_acomp_get_eld+0x38/0x70 [snd_hda_core] [ 18.809966] [<ffffffffa017da52>] hdmi_present_sense+0x92/0x370 [snd_hda_codec_hdmi] [ 18.809971] [<ffffffffa017e0ff>] generic_hdmi_build_controls+0x11f/0x200 [snd_hda_codec_hdmi] [ 18.809985] [<ffffffffa01105b1>] snd_hda_codec_build_controls+0x191/0x1d0 [snd_hda_codec] [ 18.809993] [<ffffffffa0110881>] ? snd_hda_codec_build_pcms+0xe1/0x1a0 [snd_hda_codec] [ 18.809999] [<ffffffffa010b442>] hda_codec_driver_probe+0x82/0x100 [snd_hda_codec] [ 18.810005] [<ffffffff8153d729>] driver_probe_device+0x229/0x450 [ 18.810008] [<ffffffff8153da7d>] __device_attach_driver+0x6d/0x80 [ 18.810011] [<ffffffff8153da10>] ? driver_allows_async_probing+0x30/0x30 [ 18.810015] [<ffffffff8153b4b8>] bus_for_each_drv+0x58/0x90 [ 18.810018] [<ffffffff8153d3c8>] __device_attach+0xb8/0x130 [ 18.810022] [<ffffffff8153dc0e>] device_initial_probe+0xe/0x10 [ 18.810025] [<ffffffff8153c76e>] bus_probe_device+0x9e/0xb0 [ 18.810028] [<ffffffff8153a5a1>] device_add+0x421/0x5f0 [ 18.810035] [<ffffffff817c2599>] ? mutex_unlock+0x9/0x10 [ 18.810041] [<ffffffffa00eba7f>] snd_hdac_device_register+0xf/0x40 [snd_hda_core] [ 18.810048] [<ffffffffa010b1f6>] snd_hda_codec_configure+0x36/0x180 [snd_hda_codec] [ 18.810057] [<ffffffffa01150c3>] azx_codec_configure+0x23/0x40 [snd_hda_codec] [ 18.810062] [<ffffffffa0134707>] azx_probe_work+0x567/0x870 [snd_hda_intel] [ 18.810067] [<ffffffff81093c8b>] process_one_work+0x1cb/0x680 [ 18.810070] [<ffffffff81093c06>] ? process_one_work+0x146/0x680 [ 18.810073] [<ffffffff81094189>] worker_thread+0x49/0x490 [ 18.810076] [<ffffffff81094140>] ? process_one_work+0x680/0x680 [ 18.810081] [<ffffffff8109a87a>] kthread+0xea/0x100 [ 18.810085] [<ffffffff817c5407>] ? _raw_spin_unlock_irq+0x27/0x50 [ 18.810090] [<ffffffff8109a790>] ? kthread_create_on_node+0x1f0/0x1f0 [ 18.810093] [<ffffffff817c60bf>] ret_from_fork+0x3f/0x70 [ 18.810097] [<ffffffff8109a790>] ? kthread_create_on_node+0x1f0/0x1f0 [ 18.810277] ---[ end trace 2d4983bcfed2cd4b ]--- This other one was seen at least on on SKL: [ 124.808525] ------------[ cut here ]------------ [ 124.808545] WARNING: CPU: 3 PID: 173 at sound/hda/hdac_i915.c:91 snd_hdac_display_power+0xf1/0x110 [snd_hda_core]() [ 124.808551] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp i915 crct10dif_pclmul snd_hda_intel crc32_pclmul snd_hda_codec ghash_clmulni_intel snd_hwdep snd_hda_core snd_pcm mei_me mei i2c_hid sdhci_pci e1000e ptp sdhci pps_core mmc_core [ 124.808603] CPU: 3 PID: 173 Comm: kworker/3:2 Tainted: G W 4.5.0-gfxbench+ #1 [ 124.808608] Hardware name: /NUC6i5SYB, BIOS SYSKLi35.86A.0028.2015.1112.1822 11/12/2015 [ 124.808616] Workqueue: pm pm_runtime_work [ 124.808639] 0000000000000000 ffff88026423fbb8 ffffffff813fef15 0000000000000000 [ 124.808644] ffffffffa00f877c ffff88026423fbf0 ffffffff81078a21 0000000000000000 [ 124.808648] ffff880085a11148 ffff880085586ab8 ffff8800861b8000 0000000000000000 [ 124.808652] Call Trace: [ 124.808656] [<ffffffff813fef15>] dump_stack+0x67/0x92 [ 124.808660] [<ffffffff81078a21>] warn_slowpath_common+0x81/0xc0 [ 124.808662] [<ffffffff81078b15>] warn_slowpath_null+0x15/0x20 [ 124.808668] [<ffffffffa00f77e1>] snd_hdac_display_power+0xf1/0x110 [snd_hda_core] [ 124.808673] [<ffffffffa015039d>] azx_intel_link_power+0xd/0x10 [snd_hda_intel] [ 124.808680] [<ffffffffa011e32a>] azx_link_power+0x1a/0x30 [snd_hda_codec] [ 124.808684] [<ffffffffa00f21f9>] snd_hdac_link_power+0x29/0x40 [snd_hda_core] [ 124.808690] [<ffffffffa01192a6>] hda_codec_runtime_suspend+0x76/0xa0 [snd_hda_codec] [ 124.808697] [<ffffffffa0119230>] ? hda_codec_runtime_resume+0x50/0x50 [snd_hda_codec] [ 124.808701] [<ffffffff8154719d>] __rpm_callback+0x2d/0x70 [ 124.808704] [<ffffffff815471ff>] rpm_callback+0x1f/0x80 [ 124.808710] [<ffffffffa0119230>] ? hda_codec_runtime_resume+0x50/0x50 [snd_hda_codec] [ 124.808713] [<ffffffff81547764>] rpm_suspend+0x134/0x7f0 [ 124.808716] [<ffffffff810c80a9>] ? __lock_is_held+0x49/0x70 [ 124.808719] [<ffffffff81548129>] rpm_idle+0x209/0x530 [ 124.808722] [<ffffffff815494f9>] pm_runtime_work+0xa9/0xc0 [ 124.808725] [<ffffffff81093c8b>] process_one_work+0x1cb/0x680 [ 124.808728] [<ffffffff81093c06>] ? process_one_work+0x146/0x680 [ 124.808731] [<ffffffff81094189>] worker_thread+0x49/0x490 [ 124.808733] [<ffffffff81094140>] ? process_one_work+0x680/0x680 [ 124.808735] [<ffffffff81094140>] ? process_one_work+0x680/0x680 [ 124.808738] [<ffffffff8109a87a>] kthread+0xea/0x100 [ 124.808742] [<ffffffff817c53d7>] ? _raw_spin_unlock_irq+0x27/0x50 [ 124.808745] [<ffffffff8109a790>] ? kthread_create_on_node+0x1f0/0x1f0 [ 124.808749] [<ffffffff817c607f>] ret_from_fork+0x3f/0x70 [ 124.808752] [<ffffffff8109a790>] ? kthread_create_on_node+0x1f0/0x1f0 [ 124.808755] ---[ end trace 2b97e417eb08d213 ]--- -- Ville Syrjälä Intel OTC

4 23

[alsa-devel] amidi.c.patch review request
by Martin Tarenskeen 21 Mar '16

21 Mar '16

Hi, I improved my own patch to amidi.c As a result I can now succesfully fetch a SysEx dump from my Yamaha Reface DX, and it exits succesfully after the timeout that I specify using the -t option. Problem: My synth sends continuously not only 0xFE (Active Sensing) but also 0xF8 (Timing Clock). 24 times per quarter note to be exactly. With a fast tempo like 250 BPM this gives a 0xF8 byte every 10 ms. Until now when I tried to fetch a SysEx dump from my synth using amidi the data were polluted with lots of 0xF8 bytes and the -t option would not work. A bug I would say. The attached patch seems to solve this issue, but please comment and improve where needed. Please try with other synths also. Can someone submit my patch to the official sources? I don't know how to. See attached. -- Martin

2 1

Re: [alsa-devel] [Alsa-devel] [PATCH] amidi active sensing option
by Clemens Ladisch 21 Mar '16

21 Mar '16

Martin Tarenskeen wrote: > I searched on Google and found in the old alsa-devel archives the > anouncement of this option to enable/disable detecting Active Sensing > (0xfe) bytes with the amidi utility. > But not only 0xfe (Active Sensing) should be blocked by default, also > other Midi System Realtime messages. In other SysEx dump utilities > that I know there is a simialr option called something like > "rt-filter" or "realtime-filter". > [...] > I have attached my patch. Thank you for this improvement. However, the name of the option ("--active-sensing") is no longer correct, and the man page must be updated, too. Also, patches need a Signed-off-by line to indicate that the submitter accepts the DCO; see <http://elinux.org/Developer_Certificate_Of_Origin>. Regards, Clemens

1 0