November 2013 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Segfaults in snd_pcm_area_silence() when using softvol
by Tanu Kaskinen 18 May '14

18 May '14

Hi, A bug was reported to pulseaudio about a segfault in alsa-lib code when using softvol: https://bugs.freedesktop.org/show_bug.cgi?id=51060 . It has been observed by several people, and this mail was prompted by the last bug comment, which rightly recommends getting in touch with the alsa developers: > I've had this problem too and the problem only occurs with > -ftree-vectorize. > > It looks to me as if this is a gcc bug, as it produces a "movdqa" or > "vmovdqa" instruction which is used with an unaligned pointer. > > Now, I have no clue why gcc assumes the pointer would be an aligned > one, maybe it is even right and something else is wrong, but I haven't > spent too much time digging into this. > > (note that it still happens with gcc 4.7 and the current 4.8 > development one) > > Also, this bug should probably be brought up with the alsa guys as > well, as I don't think pulseaudio is at fault here. Here's the stack trace for your convenience (see the linked bug for more details) #0 snd_pcm_area_silence (dst_area=0x7fffe875bb00, dst_offset=<optimized out>, samples=2, format=SND_PCM_FORMAT_S16_LE) at pcm.c:2549 #1 0x00007fffe87b4398 in snd_pcm_areas_silence (dst_areas=0x5555557fa100, dst_offset=891, channels=2, frames=439, format=SND_PCM_FORMAT_S16_LE) at pcm.c:2662 #2 0x00007fffe87f9bdb in softvol_convert_stereo_vol (svol=0x555555813cf0, dst_areas=0x5555557fa0e0, dst_offset=891, src_areas=0x5555557fa0e0, src_offset=<optimized out>, channels=2, frames=439) at pcm_softvol.c:286 #3 0x00007fffe87fae58 in snd_pcm_softvol_write_areas (pcm=0x55555581db60, areas=0x5555557fa0e0, offset=891, size=439, slave_areas=0x5555557fa0e0, slave_offset=891, slave_sizep=0x7fffe875bcd0) at pcm_softvol.c:607 #4 0x00007fffe87c6fc7 in snd_pcm_plugin_mmap_commit (pcm=0x55555581db60, offset=<optimized out>, size=439) at pcm_plugin.c:424 #5 0x00007fffe87b9676 in snd_pcm_mmap_commit (pcm=<optimized out>, offset=<optimized out>, frames=<optimized out>) at pcm.c:6584 #6 0x00007fffe8a74876 in mmap_write (on_timeout=false, polled=false, sleep_usec=<synthetic pointer>, u=0x5555557e6d40) at modules/alsa/alsa-sink.c:636 #7 thread_func (userdata=0x5555557e6d40) at modules/alsa/alsa-sink.c:1694 #8 0x00007ffff722c039 in internal_thread_func (userdata=0x55555587ef80) at pulsecore/thread-posix.c:83 #9 0x00007ffff4a24e2c in ?? () from /lib64/libpthread.so.0 #10 0x00007ffff3ccc1dd in clone () from /lib64/libc.so.6 -- Tanu

2 1

[alsa-devel] [PATCH v3 0/5] ALSA: hda - hdmi: ATI/AMD multi-channel and HBR support
by Anssi Hannula 14 May '14

14 May '14

Hi all! Here's another revision of the ATI/AMD multichannel+HBR patchset. Changes: - added customizable callbacks instead of polluting generic code - fixed wrong codec id in rev3+ check (as previously noted) - cosmetics I've only tested this on NVIDIA/Intel, but I'd guess at least Peter should be able to test this on AMD in a few days or so. The earlier revisions were tested to fully work. Combined patch can be found at: http://onse.fi/files/atihdmi5.patch However, this patchset is on top recent sound-next commits so it does not directly apply on older kernels. Olivier, I hope you will be able to test this at some point as well (same things as last time), even though it will be a bit more work :) Anssi Hannula (5): ALSA: hda - hdmi: Allow HDA patches to customize more operations ALSA: hda - hdmi: Add ATI/AMD multi-channel audio support ALSA: hda - hdmi: Add ELD emulation for ATI/AMD codecs ALSA: hda - hdmi: Add HBR bitstreaming support for ATI/AMD HDMI codecs ALSA: hda - hdmi: Disable ramp-up/down for non-PCM on AMD codecs sound/pci/hda/hda_eld.c | 151 +++++++++++ sound/pci/hda/hda_local.h | 4 + sound/pci/hda/patch_hdmi.c | 643 +++++++++++++++++++++++++++++++++++++-------- 3 files changed, 689 insertions(+), 109 deletions(-) -- Anssi Hannula

9 70

[alsa-devel] Ambiguous DAPM widget names and DPCM
by Daniel Mack 21 Mar '14

21 Mar '14

Hi Mark, Hi Liam, I spent some hours reverse-engineering the DPCM code, and I plan to prepare a patch to add some documentation once I've assembled a fully working setup. However, I have a general question regarding DAPM widget names. DPCM uses DAPM widgets and routes in order to determine the FE <-> BE connections at runtime. The problem with this is that widget names are very ambiguous, as the automatically created widgets for DAIs are named after their stream_name properties, which contain "Playback" or "Capture" for all components in my case. Hence, the code which walks the connections (snd_soc_dapm_dai_get_connected_widgets()) will most likely match the wrong one (which has empty sound/sink lists), which results in a failure like this: [ 16.606268] fe: ASoC: fe no valid playback route I hacked the names of all components so they are unique, but even then, the problem is that snd_soc_dapm_new_dai_widgets() is called twice for the CPU DAI, once from soc_probe_platform(), and later from soc_probe_link_dais(), and both calls would create DAPM widgets with identical names, resulting in the same problem as described above. I don't know how to handle this, but I believe that nobody was really hit by this issue yet, as DPCM doesn't seem to be used widely, at least not by any machine code in mainline. One idea would be to change the automatically generated names of DAI widgets in order to make them unique, or re-factor the lookup routines. Any opinion on that? Do I miss a general consideration here? With more hacks in place, the setup somehow succeeds, but when the stream is opened, we'll hit a BUG() in sound/core/pcm_memory.c, because the FE device's DMA type is undefined. But that's another topic I'll address later. Thanks, Daniel

5 9

Re: [alsa-devel] Zoom R16
by Jason Mancine 11 Mar '14

11 Mar '14

Can't seem to compile 3.11 or 3.12 for the distro I am using (AVLInux)... tested it in Ubuntu Studio 13.10 and the quirk didn't seem to have any effect. The output of lsusb is the same, but the device doesn't show up as a sound card. On Sun, Nov 24, 2013 at 9:18 AM, Daniel Mack <daniel(a)zonque.org> wrote: > On Sun, Nov 24, 2013 at 09:03:47AM -0500, Jason Mancine wrote: > > Thanks, I will give it a try. By recent kernel do you mean latest > mainline > > or should my distro's 3.6.11 be new enough? > > Anything >= 3.11 should do. > > In further replies, please do not drop the alsa-devel mailing list. > > > Thanks, > Daniel >

3 15

[alsa-devel] Update patch for codecs alias name for Dell
by Kailang 05 Mar '14

05 Mar '14

Hi Takashi, Dell assigned more codecs for alias name. I update in attach patch. Thanks. Kailang

3 7

[alsa-devel] Unsupported Valley View 'LPE' adapter?
by Adam Williamson 27 Feb '14

27 Feb '14

Hi, folks. I recently bought a Dell Venue 8 Pro - a Bay Trail / Valley View-based Intel tablet - to try and get Fedora running on it. Among the many things I'm currently fighting :) , the sound doesn't work. snd-hda-intel is not loaded at all, and there are no audio devices present at any level. In Windows' Device Manager I see an 'Intel SST Audio Device' with PCI ID 0x86:0f28 . Indeed, the PCI ID database has this listed as "ValleyView LPE Audio Controller" - http://pci-ids.ucw.cz/read/PC/8086/0f28 . But hda-intel does not have 0f28 as a supported device. The commit for 'Bay Trail' audio support added the ID 0f04: https://lkml.org/lkml/2013/5/16/38 So...what is this 0f28? Is support for it going to be added? Is there any info I can provide to help? (I can boot Linux on the tablet and get info out of it _just barely_, but it's pretty painful - there's no wifi and an install to 'disk' (really a usb stick) doesn't work too well, so I'm stuck working in a live image with no network). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

6 13

[alsa-devel] [PATCH RFC 0/9] Beaglebone-Black HDMI audio
by Jyri Sarha 24 Jan '14

24 Jan '14

This set of patches implements PCM HDMI audio driver for Beaglebone-Black HDMI output. The patches have been rebased on top of: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound topic/davinci There is couple of earlier RFC versions of the clk patch floating around, but the one here is the latest version. I'll send the associated dts changes shortly as a separate patch. Best regards, Jyri Jyri Sarha (9): clk: add gpio controlled clock ASoC: davinci-evm: Add named clock reference to DT bindings ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus ASoC: hdmi-codec: Add devicetree binding with documentation ASoC: hdmi-codec: Add SNDRV_PCM_FMTBIT_32_LE playback format ASoC: davinci: HDMI audio build for AM33XX and TDA998x drm/tilcdc: Add I2C HDMI audio config for tda998x ARM: OMAP2+: omap2plus_defconfig: Enable tilcdc and TDA998X HDMI support ARM: OMAP2+: omap2plus_defconfig: Enable BeagleBone Black HDMI audio support .../devicetree/bindings/clock/gpio-clock.txt | 21 ++ .../bindings/sound/davinci-evm-audio.txt | 12 +- Documentation/devicetree/bindings/sound/hdmi.txt | 17 ++ arch/arm/configs/omap2plus_defconfig | 5 + drivers/clk/Makefile | 1 + drivers/clk/clk-gpio.c | 209 ++++++++++++++++++ drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 ++- include/linux/clk-provider.h | 25 +++ sound/soc/codecs/hdmi.c | 12 +- sound/soc/davinci/Kconfig | 12 ++ sound/soc/davinci/Makefile | 1 + sound/soc/davinci/davinci-evm.c | 227 +++++++++++++++++++- 12 files changed, 558 insertions(+), 8 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/gpio-clock.txt create mode 100644 Documentation/devicetree/bindings/sound/hdmi.txt create mode 100644 drivers/clk/clk-gpio.c -- 1.7.9.5

6 58

[alsa-devel] HD-audio runtime PM
by Takashi Iwai 24 Jan '14

24 Jan '14

Hi, after my previous fix, the runtime PM seems working stably finally. However, there seem still some glitches: 1. The wakeup via jack or HDMI/DP detection doesn't seem to work on my test machines. WAKEEN is set properly. And its value can be read correctly at the point of runtime resume, too. 2. We don't change the device to D3 in runtime suspend. So I guess we save little power as of now. Actually, setting to D3 and resuming to D0 works fine, as far as I tested -- except for HDMI/DP ELD read out on Haswell. Although ELD read doesn't give any errors, the received bytes are corrupted. In my case, the read starts from offset 0x1c. The HDMI can be still played even at that state, but then it falls back to the stereo 2ch mode, of course. The tests were performed on both Haswell (DP and LynxPoint-LP) and IvyBridge (PantherPoint) machines. The first problem has been present, and it's also the behavior of some old chips where the codec can't go to sleep with unsol wakeup. So, in this regard, it's no regression, per se. But certainly it's no good thing. I thought Mengdong once made WAKEEN working. Mengdong, do you remember what was the condition? Could you check whether the latest kernel (at best sound git tree for-linus branch) still works? About the second point: we should do D3 if we do care power, and that's the very right reason for runtime PM. But the ELD issue is a bad bug, and it makes me wonder whether it's a graphics driver side issue or a codec side. As a quick workaround, we can implement D3 on controllers but for Haswell HDMI/DP. In anyway, this is no urgent issue, clearly targeted for 3.14. The whole patch series are found in my sound-unstable git tree test/hda branch. git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git thanks, Takashi

4 28

Re: [alsa-devel] snd-usb: "delay: estimated 0, actual 352"
by Takashi Iwai 08 Jan '14

08 Jan '14

At Thu, 6 Sep 2012 15:17:58 +0200, Markus Trippelsdorf wrote: > > On 2012.09.06 at 15:08 +0200, Takashi Iwai wrote: > > At Thu, 6 Sep 2012 11:43:48 +0200, > > Markus Trippelsdorf wrote: > > > > > > On 2012.09.06 at 10:21 +0200, Takashi Iwai wrote: > > > > At Thu, 06 Sep 2012 09:35:26 +0200, > > > > Takashi Iwai wrote: > > > > > > > > In short, a patch like below may fix the issue (note: completely > > > > untested!) > > > > > > No it doesn't, unfortunately... > > > > OK, I start tracking down the problem a bit more deeply now. > > > > The issue happens when the first two URBs are passed to > > retire_playback_urb(). These are URBs filled before start_endpoints() > > are set, so they contain actually zero size. Even though these are > > a sort of dummy packets, the driver still tries to check with the > > queued delay account, and gives bogus errors. > > > > So, essentially the messages are harmless and nothing to worry too > > much, but surely it doesn't look sexy. > > > > The patch below should fix the problem. Please give it a try. > > Yes, your patch finally fixes the problem. > Thank you Takashi-san. Thanks for your quick test! If Daniel has no objection with that patch, I'm going to merge it. Takashi

3 2

[alsa-devel] [Patch v2 1/2] ASoC: atmel: sam9x5_wm8731: fix oops when unload module
by Bo Shen 31 Dec '13

31 Dec '13

As the priv is not assigned to card->drvdata, it is NULL, so when unload module, it will cause NULL pointer oops. Assign priv to card->drvdata to fix this issue. Signed-off-by: Bo Shen <voice.shen(a)atmel.com> --- Change in v2: - using snd_soc_card_set_drvdata() --- sound/soc/atmel/sam9x5_wm8731.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/atmel/sam9x5_wm8731.c b/sound/soc/atmel/sam9x5_wm8731.c index 992ae38..1b37228 100644 --- a/sound/soc/atmel/sam9x5_wm8731.c +++ b/sound/soc/atmel/sam9x5_wm8731.c @@ -97,6 +97,8 @@ static int sam9x5_wm8731_driver_probe(struct platform_device *pdev) goto out; } + snd_soc_card_set_drvdata(card, priv); + card->dev = &pdev->dev; card->owner = THIS_MODULE; card->dai_link = dai; -- 1.7.9.5

3 6