April 2015 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH v2 1/3] ARM: shmobile: armadillo800eva: Properly specify HDMI audio link format
by Lars-Peter Clausen 29 Jan '16

29 Jan '16

The DAI link format should be specified for the whole link rather than just one component on the link. So move the format specification for the HDMI audio link from the CPU component to the link itself. Since the sh-mobile-hdmi DAI driver doesn't implement the set_fmt() callback in this case there is no functional difference between only specifying the the format for the CPU side or for the whole link, but the later it will allow us to remove support for just specifying the format for one component. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- No changes since v1. --- arch/arm/mach-shmobile/board-armadillo800eva.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c b/arch/arm/mach-shmobile/board-armadillo800eva.c index 6d949f1..75de26c 100644 --- a/arch/arm/mach-shmobile/board-armadillo800eva.c +++ b/arch/arm/mach-shmobile/board-armadillo800eva.c @@ -1040,9 +1040,9 @@ static struct asoc_simple_card_info fsi2_hdmi_info = { .card = "FSI2B-HDMI", .codec = "sh-mobile-hdmi", .platform = "sh_fsi2", + .daifmt = SND_SOC_DAIFMT_CBS_CFS, .cpu_dai = { .name = "fsib-dai", - .fmt = SND_SOC_DAIFMT_CBS_CFS, }, .codec_dai = { .name = "sh_mobile_hdmi-hifi", -- 1.8.0

5 15

[alsa-devel] [PATCH 0/4] ASoC: fix saif record unwork issue
by Dong Aisheng 16 Jan '16

16 Jan '16

This patch series mainly fixes the saif record unwork issue. The root cause consists of: 1) clk_prepare and clk_enable un-balanced 2) missed setting a proper initial clock rate for saif in dt 3) sgtl5000 dapm widget kcontrol does not work So can not test record on mx28evk. 4) missed setting clkmux mode for saif in dt With this patch series it can fix sgtl5000 widget kcontrol unwork and saif record unwork issue. BTW, just let people konw, i still met a few overruns during record, that's another issue and will be fixed in separte patches later. Patch based on sound-2.6/for-3.6. Dong Aisheng (4): ASoC: mxs-saif: fix clock prepare and enable unbalance issue ASoC: mxs-saif: set a base clock rate for EXTMASTER mode work ASoC: sgtl5000: remove unneeded snd_soc_dapm_new_widgets in probe ARM: mx28evk: add missed clkmux select for saif arch/arm/mach-mxs/mach-mxs.c | 3 +++ sound/soc/codecs/sgtl5000.c | 2 -- sound/soc/mxs/mxs-saif.c | 24 ++++++++++++++++++++++++ 3 files changed, 27 insertions(+), 2 deletions(-)

5 20

[alsa-devel] [PATCH] ARM: sun7i: Fix HDMI Audio driver's Alsa interface and do 8CH IEC60958 output
by thomas schorpp 13 Nov '15

13 Nov '15

Version 0.2 Users doc: All You need to get a HDMI- Pulseaudio Server on Your sunxi board to output Multichannel PCM is this line in default.pa, ttable pcms in asound.conf get ignored: +load-module module-alsa-sink device="hw:1,0" channels=8 channel_map="front-left,front-right,lfe,front-center,rear-left,rear-right,side-left,side-right" ### Automatically load driver modules depending on the hardware available .ifexists module-udev-detect.so load-module module-udev-detect Probe with speaker-test, You may need other channel mapping than I. If you run PA in system mode please read the security documentation before, see PA log for link. y tom

2 1

[alsa-devel] [PATCH 0/8] Add support for Wolfson WM8998 and WM1814 codecs
by Richard Fitzgerald 02 Oct '15

02 Oct '15

This set of patches adds support for the Wolfson Microelectronics WM8998 and WM1814 codecs. Richard Fitzgerald (8): mfd: arizona: Split INx_MODE into two fields ASoC: arizona: add defines for single-input gain control mfd: arizona: Add support for WM8998 and WM1814 gpio: arizona: add support for WM8998 and WM1814 regulator: arizona: add support for WM8998 and WM1814 extcon: arizona: Add support for WM8998 and WM1814 ASoC: wm8998: Initial WM8998 codec driver Documentation: Add WM8998/WM1814 device tree bindings Documentation/devicetree/bindings/mfd/arizona.txt | 3 + drivers/extcon/extcon-arizona.c | 33 +- drivers/gpio/gpio-arizona.c | 2 + drivers/mfd/Kconfig | 6 + drivers/mfd/Makefile | 3 + drivers/mfd/arizona-core.c | 106 ++- drivers/mfd/arizona-i2c.c | 8 + drivers/mfd/arizona-irq.c | 9 + drivers/mfd/arizona.h | 5 + drivers/mfd/wm8998-tables.c | 1592 +++++++++++++++++++++ drivers/regulator/arizona-ldo1.c | 2 + include/linux/mfd/arizona/core.h | 3 + include/linux/mfd/arizona/pdata.h | 5 +- include/linux/mfd/arizona/registers.h | 247 +++- sound/soc/codecs/Kconfig | 6 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/arizona.c | 7 + sound/soc/codecs/arizona.h | 7 +- sound/soc/codecs/wm8998.c | 1392 ++++++++++++++++++ sound/soc/codecs/wm8998.h | 23 + 20 files changed, 3432 insertions(+), 29 deletions(-) create mode 100644 drivers/mfd/wm8998-tables.c create mode 100644 sound/soc/codecs/wm8998.c create mode 100644 sound/soc/codecs/wm8998.h -- 1.7.2.5

6 22

[alsa-devel] No stream timing info with alsa pulse plugin?
by sqweek 24 Sep '15

24 Sep '15

Hi guys, I discovered on my machine that alsa_snd_pcm_status_get_tstamp (and also get_htstamp) stop working when my asoundrc invokes the pulse plugin. That is, normally they work fine but once the sound is going via pulse the returned time stamp is always zero. I'm trying to understand why that is. I couldn't really find any discussion of the pulse plugin on the archives so I'm not entirely sure I've found the right list; I was directed here via the pulseaudio bugzilla[1]. [1] https://bugs.freedesktop.org/show_bug.cgi?id=88503 Thanks for any assistance! -sqweek

4 3

[alsa-devel] Intel SST on a Bay Trail tablet
by Antonio Ospite 18 Sep '15

18 Sep '15

Hi, I am trying to get the Intel SST driver working on a Teclast X98 Air 3G [1], it's a Bay Trail tablet. The tests below have been made with 4.0.0-rc1 and the firmware files from https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tr… The DSDT on this device is quite broken, and I am patching it to get stuff working. The audio device works just fine under Android, I don't know if that's because the Android kernel is ignoring the DSDT and is hard-coding some platform data. Anyhow, with the untouched DSDT[2] I was getting this message in dmesg[3]: [ 11.344095] platform byt-rt5640: Driver byt-rt5640 requests probe deferral [ 11.404831] resource sanity check: requesting [mem 0x91000000-0x911fffff], which spans more than ADMA0F28:00 [mem 0x91000000-0x91000fff] [ 11.404833] ------------[ cut here ]------------ [ 11.404849] WARNING: CPU: 0 PID: 213 at arch/x86/mm/ioremap.c:197 __ioremap_caller+0x22c/0x350() ... I guessed this was because the DSDT defined an ADMA0F28 device with a memory resource overlapping with the LPMA device. So I removed the overlapping resources (ADMA0F28 and SSPX0000) in the DSDT and then the driver attempted to boot the audio device but failed with this message in dmesg[4]: [ 11.602291] baytrail-pcm-audio baytrail-pcm-audio: ipc: error DSP boot timeout ... Then I noticed that the Interrupt resources of the LPMA device were out of order in the DSDT, so I put the Interrupt 0x18 as the first one[5] and now the driver can boot the device and upload the firmware to it[6]: [ 11.433460] baytrail-pcm-audio baytrail-pcm-audio: FW version: 04.05.13.a0 [ 11.433468] baytrail-pcm-audio baytrail-pcm-audio: Build type: a0 [ 11.433473] baytrail-pcm-audio baytrail-pcm-audio: Build date: Apr 2 2014 14:14:39 [ 11.448257] byt-rt5640 byt-rt5640: rt5640-aif1 <-> baytrail-pcm-audio mapping ok ... But still no sound. I can see the mixer controls in alsamixer and I tried to initialize them copying from the alsactl output from the Android kernel[7], but no, still no sound. I do not know if that matters, but the driver still emits this message: [ 11.398304] baytrail-pcm-audio baytrail-pcm-audio: error: invalid DMA engine 0 [ 11.398314] baytrail-pcm-audio baytrail-pcm-audio: sst_dma_new failed -22 ... I noticed that on the Android kernel[8] the DMA channels for the ADMA0F28 device are actually configured, the intel_mid_dma driver sets up 4 channels for it along with 2 x 6 channels for the INTL9C60 device. On the mainline kernel only the INTL9C60 device gets configured, by the dw_dmac driver and with 2 x 8 channels. I do not know much about these details tho. Also, the codec driver on the Android kernel (byt_rt5642) seems to use one GPIO as an interrupt[9]: 390: 0 1 0 0 VLV-GPIO-gpio byt-codec-int Which is pin 4 on GPO2, but the codec driver in the mainline kernel does not seem to be using this; however AFAICS in sound/soc/codecs/rt5640.c a gpio pin in only used for suspend/resume, so it is not strictly needed if it's already in the correct state, right? Last question, what is the difference between having the device detected by sound/soc/intel/sst-acpi.c (like in my case) opposed to sound/soc/intel/sst/sst_acpi.c? I can see the 80860F28 id in both the files but they seem to load different firmwares. Any idea of what is missing? It's the DSDT which still needs adjusting, or are some changes needed (also) in the kernel driver? Thanks, Antonio [1] http://ao2.it/110 [2] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dsdt_sst_original.dsl [3] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dmesg_mainline_sst_ori… [4] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dmesg_mainline_sst_wit… [5] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dsdt_sst_without_ADMA0… [6] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dmesg_mainline_sst_wit… [7] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/android_asound.state [8] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dmesg_Android_Teclast_… [9] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/android_proc_interrupt… -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?

6 23

[alsa-devel] BugReport: Dice works partially [Broken]
by Stanislav Sergiienko 16 Aug '15

16 Aug '15

Hi, I am a user of TC Electronic DesktopKonnekt6 and latest kernel update 3.19.2 add partial support for my device and thus broke my usual sound workflow. So i want to make good bug report to make device usable on latest kernels. With 3.19.2 kernel device is successfully recognized by system and even sometimes can play sound(!). But always, after some time sound is breaks (usually after 30-90 seconds) and to restore it i must restart pulseaudio(v6.0) and application. So device becomes unusable on latests kernels. Earlier i use my sound card through ffado + jackdbus + pulseaudio. Now it's impossible, so i have to downgrade kernel. Please request any additional info that you need to fix problem and i will post it here soon. Also i can test any "bleeding edge" changes thru dkms as described here: https://github.com/takaswie/snd-firewire-improve Related bug(not mine): https://bugs.archlinux.org/task/44258 Some useful info: cat /proc/asound/cards 0 [DesktopKonnekt6]: DICE - DesktopKonnekt6 TC Electronic DesktopKonnekt6 (serial 12941) at fw1.0, S400 cat /proc/asound/card0/dice sections: global: offset 10, size 90 tx: offset 100, size 142 rx: offset 242, size 282 ext_sync: offset 524, size 4 unused2: offset 0, size 0 global: owner: ffc1:000100000000 notification: 00000040 nick name: DesktopKonnekt6 clock select: internal 44100 enable: 1 status: locked 44100 ext status: 00000000 sample rate: 44100 version: 1.0.4.0 clock caps: 44100 48000 88200 96000 176400 192000 arx1 arx2 internal clock source names: Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\INTERNAL\\ tx 0: iso channel: 0 audio channels: 6 midi ports: 0 speed: S400 names: ch 1\ch 2\ - \ - \ - \ - \\ ac3 caps: 00000000 ac3 enable: 00000000 rx 0: iso channel: 1 sequence start: 0 audio channels: 6 midi ports: 0 names: main out 1\main out 2\phones out 1\phones out 2\ - \ - \\ ac3 caps: 00000000 ac3 enable: 00000000 ext status: clock source: internal locked: 1 rate: 44100 adat user data: 0

3 4

[alsa-devel] RME MADIFX mainline inclusion
by Adrian Knoth 10 Aug '15

10 Aug '15

Hi Takashi! Back in the days (late 2012 I guess), I wrote the MADIFX driver based on the existing RME hdspm.c. I never had physical access to this 1399 Euro audio interface, only the OSX driver and a shell login to one of IOSONO's machines which temporarily featured such a card. I know there are other users like University of Washington (DXARTS) and probably some more (the usual WFS suspects). Long story short: I don't have such a card and since I no longer work in Linux audio, I guess I won't have access in the foreseeable future. That said, I think the driver should be part of the mainline kernel, so it gets all the love the other drivers get (static code analysis, API changes etc.) I think I've ported everything you guys have done to hdspm: I've read the commitlog for hdspm and applied those changes to the madifx driver. Code is here: https://github.com/adiknoth/madifx/commits/tokernel Status: * PCM playback/capture working (SS and DS tested, QS untested) * MIDI working * All card settings working (e.g. TX64, SMUX, AESpro, WC-Term, WC-singlespeed...) * Slave Mode/External clock selection working * Mirror-MADI1-to-Out2+3 maybe working (untested) * Redundancy mode maybe working (untested) * ioctls implemented (see ioctl.c) * Static mixer working (fixed 1:1 mapping) * DSP NOT working. RME doesn't intend to release any information regarding the DSP. * Adjustable mixer NOT working (needs new userspace tools) * Levelmetering NOT working (maybe wrong, needs new userspace tools) I have no idea who could write the new mixer code. Apparently, demand is low, maybe zero. checkpatch reports four warnings of which one is a false-positive, the other one doesn't make sense and only two are real but somewhat ugly to fix (line over 80 with really long array indices). In its current state, can I send you three patches (Kconfig, madifx.h, madifx.c) that add said driver to sound/pci/rme9652? Cheers

6 16

[alsa-devel] Possible GPL-licensed header included in alsa-lib
by Clemens Lang 27 Jul '15

27 Jul '15

Hi, I recently reviewed the alsa-lib 1.0.27.2 source code from a licensing perspective to ensure compliant usage and distribution. It seems the intention is for the libraries to be covered by LGPL. I had a look at include/list.h, which seems to be licensed under GPL-2.0. It does not have a license header or any other copyright information, but it states it was taken from Linux 2.4.0: include/list.h, line 5: | This code was taken from the Linux 2.4.0 kernel. [jaroslav] I'm not sure one could argue that the header was trivial, especially since it does not only contain constants, structures and interface definitions, but also implementations of inline functions. I found one previous inquiry about a similar issue[1], but it does not cover the include/list.h header. Two questions: 1. Have the copyright holders of the code in question agreed to re-license under a different, LGPL-preserving license and, if yes, is there some documentation about that? 2. If the header is indeed covered by GPL-2.0, would you accept patches to replace it with a different implementation, e.g. Rusty Russell's MIT-licensed list from ccan[2]? [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2011-March/038267.html [2] http://ccodearchive.net/info/list.html Thank you for your time, Clemens Lang -- BMW Car IT GmbH Clemens Lang Spezialist Entwicklung Lise-Meitner-Straße 14 89081 Ulm Mail: clemens.lang(a)bmw-carit.de Web: http://www.bmw-carit.de -------------------------------------------------------------------- BMW Car IT GmbH Geschäftsführer: Michael Würtenberger und Reinhard Stolle Sitz und Registergericht: München HRB 134810 --------------------------------------------------------------------

3 12

Re: [alsa-devel] ASoC: Add max98925 codec driver
by Dan Carpenter 20 Jul '15

20 Jul '15

Hello Anish Kumar, The patch 1ff2765182d1: "ASoC: Add max98925 codec driver" from Mar 9, 2015, leads to the following static checker warning: sound/soc/codecs/max98925.c:274 max98925_rate_value() error: buffer overflow 'rate_table' 9 <= 9 sound/soc/codecs/max98925.c 259 static inline int max98925_rate_value(struct snd_soc_codec *codec, 260 int rate, int clock, int *value, int *n, int *m) 261 { 262 int ret = -EINVAL; 263 int i; 264 265 for (i = 0; i < ARRAY_SIZE(rate_table); i++) { 266 if (rate_table[i].rate >= rate) { 267 *value = rate_table[i].sr; 268 *n = rate_table[i].divisors[clock][0]; 269 *m = rate_table[i].divisors[clock][1]; 270 ret = 0; 271 break; 272 } 273 } 274 dev_dbg(codec->dev, "%s: sample rate is %d, returning %d\n", 275 __func__, rate_table[i].rate, *value); ^^^^^^^^^^^^^^^^^^ If we don't break then we're off by one. 276 return ret; 277 } regards, dan carpenter

2 2