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

[alsa-devel] [PATCH 0/7][REBASE] ASoC: simple-card: add parse_clk / parse_dai
by Kuninori Morimoto 08 Aug '16

08 Aug '16

Hi Mark These are rebase version patches for parse_clk / parse_dai on simple utiles. I think today's topic/simple is missing [1/7] patch, but have [2/7] [3/7]. Because of this, it has bulid error, and you can't apply [4/7]. These patches add new functions on utils.c, and I noticed that it will have conflict with fix/simple branch. Because of these reasons, I think you want to redo topic/simple branch (?). These patches are based on fix/simple branch. Kuninori Morimoto (7): ASoC: simple-card-utils: add asoc_simple_card_parse_clk() ASoC: simple-card: use asoc_simple_card_parse_clk() ASoC: rsrc-card: use asoc_simple_card_parse_clk() ASoC: simple-card-utils: add asoc_simple_card_parse_dai() ASoC: simple-card: use asoc_simple_card_parse_dai() ASoC: rsrc-card: use asoc_simple_card_parse_dai() ASoC: simple-card: remove asoc_simple_card_sub_parse_of() include/sound/simple_card_utils.h | 25 ++++++++ sound/soc/generic/simple-card-utils.c | 69 ++++++++++++++++++++ sound/soc/generic/simple-card.c | 116 ++++++++++------------------------ sound/soc/sh/rcar/rsrc-card.c | 93 ++++++--------------------- 4 files changed, 146 insertions(+), 157 deletions(-) -- 1.9.1

2 10

[alsa-devel] [PATCH 0/7] ASoC: simple-card: add parse_clk / parse_dai
by Kuninori Morimoto 08 Aug '16

08 Aug '16

Hi Mark These add parse_clk / parse_dai to simple utiles. I know that we want to use "devm_" version of of_clk_get(), and now I'm posting its patch to kernel ML, but it still under discussion. Thus, this patch is using current style (with small fixup). I will replace it to devm version if it was accepted. Kuninori Morimoto (7): ASoC: simple-card-utils: add asoc_simple_card_parse_clk() ASoC: simple-card: use asoc_simple_card_parse_clk() ASoC: rsrc-card: use asoc_simple_card_parse_clk() ASoC: simple-card-utils: add asoc_simple_card_parse_dai() ASoC: simple-card: use asoc_simple_card_parse_dai() ASoC: rsrc-card: use asoc_simple_card_parse_dai() ASoC: simple-card: remove asoc_simple_card_sub_parse_of() include/sound/simple_card_utils.h | 25 ++++++++ sound/soc/generic/simple-card-utils.c | 69 ++++++++++++++++++++ sound/soc/generic/simple-card.c | 116 ++++++++++------------------------ sound/soc/sh/rcar/rsrc-card.c | 93 ++++++--------------------- 4 files changed, 146 insertions(+), 157 deletions(-) -- 1.9.1

2 14

[alsa-devel] [PATCH 0/4] ASoC: da7213: Device clocking updates and fixes
by Adam Thomson 08 Aug '16

08 Aug '16

This patch set contains a series of patches relating to device clocking. The changes are as follows: 1) Set correct default BCLKs per WCLK to achieve all DAI formats. Currently only 16-bit formats would operate correctly. 2) Only use MCLK as required, when an audio stream is active. Can be disabled all other times. 3) Refactoring of sysclk() and pll() functions to make them cleaner, removing need for unnecessary private flags, and resolve incorrect 32Khz mode configuration. 4) Improve 32KHz PLL locking with some small register updates when configuring PLL and when DAI is enabled. Patches are based on v4.7 Linux kernel Adam Thomson (4): ASoC: da7213: Default to 64 BCLKs per WCLK to support all formats ASoC: da7213: Improve driver efficiency with regards to MCLK usage ASoC: da7213: Refactor sysclk(), pll() functions to improve handling ASoC: da7213: Improve 32KHz mode PLL locking sound/soc/codecs/da7213.c | 134 +++++++++++++++++++++++++++++----------------- sound/soc/codecs/da7213.h | 12 +++-- 2 files changed, 94 insertions(+), 52 deletions(-) -- 1.9.3

3 10

[alsa-devel] Audible Pop noise with CS4271 codec
by Vishal Thanki 08 Aug '16

08 Aug '16

Hi all, On a custom built am335x based board with CS4271 codec, I am observing the audible pop/click sound during playback start and playback stop (using aplay). The pop sound is observed with kernel 4.0 as well as on kernel 4.4. I have not tried the recent kernels but since there is no change in the CS4271 codec driver, I am assuming the problem can be reproduced in the latest kernel as well. I have experimented a bit with conditional "soft reset" (enable_soft_reset flag) which is added in driver and which seems to have little influence in pop sound. My experiment is like following: 1) Start the board with "soft reset" enabled in CS4271 driver 2) Play sine wave tone for 5 seconds using aplay --> The pop sound is present during starting and stopping of the playback 3) Play the silence file (no audio data - filled with zero) using aplay --> The pop sound is present only during starting of the playback 4) Play the silence file again using aplay --> The pop sound is present only during starting of the playback Now disable the "soft reset" in driver and 1) Play sine wave tone for 5 seconds using aplay --> The pop sound is present during starting and stopping of the playback 2) Play the silence file using aplay --> The pop sound is present only during starting of the playback 3) Play the silence file again using aplay --> The pop sound is gone 4) Play the silence file successively multiple times --> The pop sound not observed 5) Now play the sine wave tone again --> The pop sound is present during startup and stop. 6) Now play the silent file again --> The pop sound is present during startup, and no pop sound during stop. The driver handles the muting and unmuting of DAC in mute_stream DAI callback which looks okay to me. So I have added delays in mute_stream callback after "unmute" of DACs and noticed that unmuting of DAC is not causing the pop noise, but it is heard as soon as the audio data starts flowing (after .trigger() ?). I could also not figure out what problem the "soft reset" is addressing and how it is influencing the pop noise in successive silence file playback. Any help in further debugging would be greatly appreciated. Thanks, Vishal

1 0

[alsa-devel] [PATCH] alsa-python: alsaseq: added binding for delete_port
by Maurizio Berti 07 Aug '16

07 Aug '16

Hello, I was going to send this patch via git, but I've troubles setting it up against gmail, then I hope I'm not doing something wrong by posting this directly here. I found out that pyalsa doesn't provide delete_port, then I added it; please, note, I'm not a programmer, I just do this for fun and I actually have no experience in C programming: I just understand (most of) it by reading the code, so I just used some knowledge and logic to add this binding. So far, it looks fine to me and works without any problem. Signed-off-by: MaurizioB <maurizio.berti(a)gmail.com> diff --git a/pyalsa/alsaseq.c b/pyalsa/alsaseq.c index ce332ed..2ad4d55 100644 --- a/pyalsa/alsaseq.c +++ b/pyalsa/alsaseq.c @@ -2343,6 +2343,44 @@ Sequencer_create_simple_port(SequencerObject *self, return PyInt_FromLong(port); } + +/** alsaseq.Sequencer delete_port() method: __doc__ */ +PyDoc_STRVAR(Sequencer_delete_port__doc__, + "delete_port(port_id) -> int" + "\n" + "Delete an existing port.\n" + "\n" + "Parameters:\n" + " port_id -- id of the port\n" + "Raises:\n" + " SequencerError: if ALSA can't delete the port" +); + + +/** alsaseq.Sequencer delete_port() method */ +static PyObject * +Sequencer_delete_port(SequencerObject *self, + PyObject *args, + PyObject *kwds) { + int port_id = 0; + int ret; + char *kwlist[] = { "port_id", NULL}; + + if (!PyArg_ParseTupleAndKeywords(args, kwds, "|i", kwlist, + &port_id)) { + return NULL; + } + + ret = snd_seq_delete_port(self->handle, port_id); + if (ret < 0) { + RAISESND(ret, "Failed to delete port"); + return NULL; + } + + Py_RETURN_NONE; +} + + /** alsaseq.Sequencer connection_list() method: __doc__ */ PyDoc_STRVAR(Sequencer_connection_list__doc__, "connection_list() -> list\n" @@ -3248,6 +3286,10 @@ static PyMethodDef Sequencer_methods[] = { (PyCFunction) Sequencer_create_simple_port, METH_VARARGS | METH_KEYWORDS, Sequencer_create_simple_port__doc__ }, + {"delete_port", + (PyCFunction) Sequencer_delete_port, + METH_VARARGS | METH_KEYWORDS, + Sequencer_delete_port__doc__ }, {"connection_list", (PyCFunction) Sequencer_connection_list, METH_VARARGS, -- 2.4.10 -- È difficile avere una convinzione precisa quando si parla delle ragioni del cuore. - "Sostiene Pereira", Antonio Tabucchi http://www.jidesk.net

1 0

[alsa-devel] Alsa Application using the "default" plugin
by Hauke Krüger 07 Aug '16

07 Aug '16

Hi everyone, I have created an ALSA audio application which works fine for any kind of hardware device (all devices addressed by "hw:n,m"). Today, I planned to implement the functionality to also address plugins. My test case is the "default" plugin. When using this, I see significant differences: 1) Function "snd_pcm_hw_params_any" returns a value of 1. For hardware devices it returns 0. There is no documentation of the return type from that function. What does the 1 say? 2) I want to simultaneously capture and playback. Therefore I call "snd_pcm_link". This function fails with the error saying that this function is not implemented. Is that the intended behavior and how would I synchronize input and output? What I do to fix this is to start input and output ("snd_pcm_start") independently if "snd_pcm_link" fails. 3) The program stops working on the second call to "snd_pcm_writei": The function call simply never returns. I guess that the pcm output interface does not run at this moment and the output buffer has been completely filled before. All other functions calls work as expected but the described behavior prevents the application from working properly. And - to repeat - the same code works for all hardware soundcards "hw:n,m" which I tested. What is the recommended way to address the "default" plugin pcm device? Best regards Hauke

1 0

[alsa-devel] ASoC: sun4i-i2s: Restricting the MCLK
by Thomas Niederprüm 05 Aug '16

05 Aug '16

I am using the new sun4i-i2s driver in linux-next to run a sta326 codec via the pin header on a cubietruck (this involves some soldering as described in [1]). The codec can only be configured as slave and needs a master clock for its internal PLL. It is therefore great that, unlike many other SOCs, the a20 provides a MCLK that can be used to sync the codec. However, in my case there is a restriction imposed on the MCLK by the codec. As stated in the datasheet [2], the master clock should be at maximum 12.288 MHz/11.2896 MHz or otherwise the codec will not work (confirmed by experiment!). Since the mod clock of the a20's dai block is running at twice this frequency, I need to assure that the MLCK divider is at least 2. Actually it is rather straight forward to achieve this by changing the breaking condition in the divider calculation, as shown by the following one-line patch: diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c index 687a8f8..8920844 100644 --- a/sound/soc/sunxi/sun4i-i2s.c +++ b/sound/soc/sunxi/sun4i-i2s.c @@ -206,7 +206,7 @@ static int sun4i_i2s_set_clk_rate(struct sun4i_i2s *i2s, clk_rate, rate); - if ((bclk_div >= 0) && (mclk_div >= 0)) + if ((bclk_div >= 0) && (mclk_div >= 1)) break; } Of course, this is just a hack to fix my use case and I am wondering what would be the best way to handle my corner case more generally? I see one option in introducing a DT property mlck_mindiv, or similar, that defaults to 1 and can be overwritten at the board level. I'm willing to prepare a proper patch to tackle this problem but right now I'm wondering if there a major objections to this approach or whether there is any better solution to the problem. Best regards, Thomas [1] https://hifiduino.wordpress.com/2014/03/07/cubieboard-for-audio/ [2] www.st.com/resource/en/datasheet/sta326.pdf

2 2

[alsa-devel] [PATCH v4 1/4] mfd: Add DT bindings documentation for Samsung Exynos LPASS
by Sylwester Nawrocki 05 Aug '16

05 Aug '16

This patch adds documentation of the DT bindings for the Samsung Exynos SoC Low Power Audio Subsystem. Signed-off-by: Sylwester Nawrocki <s.nawrocki(a)samsung.com> --- There were few rather significant additions since v3 and I had to drop tags: Acked-by: Rob Herring <robh(a)kernel.org> Acked-by: Krzysztof Kozlowski <k.kozlowski(a)samsung.com> Changes since v3: - moved to Documentation/devicetree/bindings/mfd, - added #address-cells, #size-cells, ranges as required properties, - added description of the IP block subnodes and links to their binding's documentation. Changes since v2: - none. --- .../bindings/mfd/samsung,exynos5433-lpass.txt | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.txt diff --git a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.txt b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.txt new file mode 100644 index 0000000..7e97c0d --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.txt @@ -0,0 +1,21 @@ + +Samsung Exynos SoC Low Power Audio Subsystem (LPASS) + +Required properties: + + - compatible : "samsung,exynos5433-lpass" + - reg : should contain the LPASS top SFR region location and size + - samsung,pmu-syscon : the phandle to the Power Management Unit node + - #address-cells: should be 1 + - #size-cells: should be 1 + - ranges: must be present + +Each IP block of the Low Power Audio Subsystem should be specified +as an optional sub-node. For "samsung,exynos5433-lpass" compatible +this includes: UART, SLIMBUS, PCM, I2S, DMAC, Timers 0...4, WDT 0...1 +devices. + +Bindings of the sub-nodes are described in: + Documentation/devicetree/bindings/serial/samsung_uart.txt + Documentation/devicetree/bindings/sound/samsung-i2s.txt + Documentation/devicetree/bindings/dma/arm-pl330.txt -- 1.9.1

3 3

[alsa-devel] Stale data interleaved in capture driver
by Rob Nertney 05 Aug '16

05 Aug '16

My DMA is configured with a debug mode in which it sends an a simple increasing counter value in the format I wish to receive: an IRQ every 32Bytes (half-frame). it transfers 32KBytes of data, and then restarts from it's original offset. This is tested in bare-metal mode as working. I wrote my handler as described in the high-frequency interrupts described here: http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/ch05s07.html My data is valid until 1/4 buffer full, then it interleaves stale (lower numbers) in, replacing the desired numbers. It's sporadic, and it appears to repeat, as if ALSA never returns to the 0-offset of dma_area. I've dumped a snip below. If the formatting is lost, I can post a google drive or an image somewhere. Thanks, Rob 00004000: 8182 8183 8184 8185 00004008: 8186 8187 8188 8189 00004010: 8190 8191 8192 1 00004018: 2 3 4 5 00004020: 6 7 8 8201 00004028: 8202 8203 8204 8205 00004030: 8206 8207 8208 8209 00004038: 8210 8211 8212 8213 00004040: 8214 8215 8216 8217 00004048: 8218 8219 8220 8221 00004050: 8222 8223 8224 8225 00004058: 8226 8227 8228 8229 00004060: 8230 8231 8232 8233 00004068: 8234 8235 8236 8237 00004070: 8238 8239 8240 49 00004078: 50 51 52 53 00004080: 54 55 56 8249 00004088: 8250 8251 8252 8253 00004090: 8254 8255 8256 65 00004098: 66 67 68 69 000040a0: 70 71 72 73 000040a8: 74 75 76 77 000040b0: 78 79 80 8273 000040b8: 8274 8275 8276 8277 000040c0: 8278 8279 8280 8281 000040c8: 8282 8283 8284 8285 000040d0: 8286 8287 8288 8289 000040d8: 8290 8291 8292 8293 000040e0: 8294 8295 8296 8297 000040e8: 8298 8299 8300 8301 000040f0: 8302 8303 8304 8305 000040f8: 8306 8307 8308 8309 00004100: 8310 8311 8312 121

2 6

[alsa-devel] [GIT PULL] Skylake firmware update
by Vinod Koul 05 Aug '16

05 Aug '16

Hi, Please PULL to recive updated Skylake audio firmware. The following changes since commit 6bc2c609988823744d1a45d33ee370c8310ec305: amdgpu: update stoney UVD firmware (2016-07-29 14:40:03 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/firmware.git skl for you to fetch changes up to c170c8d95794d6aedbaeea44674daaa96baf04f7: linux-firmware: intel: Update Skylake audio firmware (2016-08-04 16:09:21 +0530) ---------------------------------------------------------------- Vinod Koul (1): linux-firmware: intel: Update Skylake audio firmware WHENCE | 4 ++-- intel/dsp_fw_release.bin | 2 +- intel/dsp_fw_release_v958.bin | Bin 0 -> 221184 bytes 3 files changed, 3 insertions(+), 3 deletions(-) create mode 100644 intel/dsp_fw_release_v958.bin Thanks -- ~Vinod

2 1