February 2014 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Regression caused by "ASoC: core: Rework SOC_DOUBLE_R_SX_TLV add SOC_SINGLE_SX_TLV"
by Thomas Petazzoni 19 Mar '14

19 Mar '14

Brian, Liam, Mark, I am currently bringing up audio support on the Marvell Armada 370 ARM SoC, for which the development board uses the CS42L51 audio codec. It turns out that the commit 1d99f2436d0d1c7741d6dfd9d27b5376cdbbca40 ("ASoC: core: Rework SOC_DOUBLE_R_SX_TLV add SOC_SINGLE_SX_TLV") causes a problem here, and reverting this commit gets things back to normal. Basically, when this commit is applied, the "PCM", "Analog" and "ADC Mixer" volume controls in alsamixer cannot be changed to any other value than 60 or 61. The volume control doesn't allow to go above 61 and below 60. If I remember correctly, at the codec level, the values configured for PCM in registers 0x10 and 0x11 are either 0x0 or 0x1 depending on whether you select 60 or 61 in alsamixer. Reverting the commit mentioned above makes alsamixer behave normally: the volume can be adjusted between 0 and 100 as expected, the values in register 0x10 and 0x11 are meaningful, and the behavior is as expected: with a volume to 0, I hear nothing in my headphones, with a volume set to 100, the volume is maximum, with a nice progressive volume increase in-between. Therefore, I believe that the commit has a problem. I haven't yet investigated where the problem is, maybe just the values passed to SOC_DOUBLE_R_SX_TLV(), or maybe in the implementation of the volume control functions themselves. I can certainly start investigating, but maybe the author of the commit will immediately realize where the problem could be. Thanks a lot! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com

4 18

[alsa-devel] [PATCH v2 0/7] Audio support for Armada 370 DB
by Thomas Petazzoni 18 Mar '14

18 Mar '14

Hello, This series of patches enable audio support on the Marvell Armada 370 Development Board. Since both the I2S controller on the SoC side and the I2C audio codec are already supported by the kernel, the amount of work is fairly limited. Changes since v1: * Drop patches "sound: codec: add Device Tree binding to cs42l51" and " sound: soc: enable Kirkwood driver for mvebu platforms" since they have been applied by Mark Brown. * Set DAI format directly in the snd_soc_dai_link structure instead of separately calling snd_soc_dai_set_fmt(). Suggested by Mark Brown. * Do not call snd_soc_dapm_enable_pin(), as Mark Brown mentionned that DAPM widgets default to enabled. It allowed to entirely remove the dai_init operation. * Use devm_snd_soc_register_card() instead of snd_soc_register_card(), as suggested by Mark Brown. * Wrote a Device Tree binding document for the DT binding introduced by this driver. Requested by Mark Brown. * Use the DT to look up the controller and the codec, as suggested by Mark Brown. * Add S/PDIF support, which has been successfully tested. I've kept it as separate patches (for both the ASoC machine driver, and the Device Tree bits), so that it can be reviewed and applied separately. * Modified the commit title so that they contain "ASoC", as requested by Mark Brown. Patches 1 and 2 are to be reviewed/applied by the ASoC maintainer Mark Brown, while patches 3 to 7 are to be reviewed/applied by the ARM mvebu maintainers. Note that the audio support for Armada 370 also needs a fix to the CS42L51, which is being discussed with the author of the change that apparently introduced the problem (see discussion at http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/071916.ht…). Thanks, Thomas Thomas Petazzoni (7): sound: ASoC: add ASoC board driver for Armada 370 DB sound: ASoC: add S/PDIF support to Armada 370 DB ASoC driver ARM: mvebu: add audio I2S controller to Armada 370 Device Tree ARM: mvebu: add I2C0 muxing option for Armada 370 SoC ARM: mvebu: add audio support to Armada 370 DB ARM: mvebu: enable S/PDIF audio in Armada 370 DB Device Tree ARM: mvebu: enable audio options in mvebu_defconfig .../bindings/sound/armada-370db-audio.txt | 27 ++++ arch/arm/boot/dts/armada-370-db.dts | 56 ++++++++ arch/arm/boot/dts/armada-370.dtsi | 28 ++++ arch/arm/configs/mvebu_defconfig | 5 + sound/soc/kirkwood/Kconfig | 9 ++ sound/soc/kirkwood/Makefile | 2 + sound/soc/kirkwood/armada-370-db.c | 148 +++++++++++++++++++++ 7 files changed, 275 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/armada-370db-audio.txt create mode 100644 sound/soc/kirkwood/armada-370-db.c -- 1.8.3.2

3 10

Re: [alsa-devel] compress: adding support for hardware dependent params
by noman pouigt 16 Mar '14

16 Mar '14

> We have a requirement, where we need to set a number of hardware specific > parameters for compressed offload use-cases, before starting a stream. As > these parameters need to be set once for the entire session, we would > like to explore the best way to set these additional parameters somewhere > before calling trigger() function. > Below are few of the proposed solutions that we could think of at this > point for getting this done- As you have not mentioned what kind of metadata you are talking about I am assuming if your meta data can fit in below structure then we already have a code in upstream which takes care of your need. 140 struct snd_compr_metadata { 141 __u32 key; 142 __u32 value[8]; 143 }; Structure snd_compr_ops has set_metadata and get_metadata callbacks which you can use for your need. 88 * struct snd_compr_ops: compressed path DSP operations 89 * @open: Open the compressed stream 90 * This callback is mandatory and shall keep dsp ready to receive the stream 91 * parameter 92 * @free: Close the compressed stream, mandatory 93 * @set_params: Sets the compressed stream parameters, mandatory 94 * This can be called in during stream creation only to set codec params 95 * and the stream properties 96 * @get_params: retrieve the codec parameters, mandatory 97 * @trigger: Trigger operations like start, pause, resume, drain, stop. 98 * This callback is mandatory 99 * @pointer: Retrieve current h/w pointer information. Mandatory 100 * @copy: Copy the compressed data to/from userspace, Optional 101 * Can't be implemented if DSP supports mmap 102 * @mmap: DSP mmap method to mmap DSP memory 103 * @ack: Ack for DSP when data is written to audio buffer, Optional 104 * Not valid if copy is implemented 105 * @get_caps: Retrieve DSP capabilities, mandatory 106 * @get_codec_caps: Retrieve capabilities for a specific codec, mandatory 107 */ It would be nice if someone can send a patch here to describe set and get_metadata callbacks in compress_driver.h > > > 1. Adding new IOCTL call: Add a new ioctl control in compress-offload.c > file to handle hardware specific parameters setting. This new ioctl > control will call into soc-compress.c and eventually call into platform > driver ioctl to set those hardware specific parameters. In this case, we > will add a new structure, let's say "snd_compr_hw_ctrl_params", with the > same fields as "snd_compr_metadata" struct. > > > 2. Adding a function hw_dependant_hw_params(), which will be called after > hw_params() and before prepare() function. The new function will > eventually call into the platform driver to get the hardware specific > parameters set. Once implemented, this would look something like- > hw_params(); > hw_dependant_hw_params(); > prepare(); > > > 3. Add a function "hw_dependant_hw_params()", as _part_ of the hw_params() > function. This new function will be called after the (existing) generic > parameters are set. So once implemented, the proposed function calls would > look like- > hw_params() { > generic_hw_params(); > hw_dependant_hw_params(); > } > prepare(); > > > We would like to get feedback on these proposed solutions and get a > discussion going to see how best these requirements can be fitted in the > current Compressed ALSA framework (for mainlining). Can you explain your meta data? Be the change you want to see in the world:Gandhi

4 3

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] [TINYCOMPRESS][PATCH 1/1] compress: no need to set metadata before calling next_track
by Richard Fitzgerald 07 Mar '14

07 Mar '14

The metadata is mainly for MP3 gapless playback, since the MP3 audio stream does not contain enough information to enable gapless. Other audio formats do not necessarily require any additional metadata so we should allow next_track to be called without any metadata. Signed-off-by: Zhao Weijia <weijia.zhao(a)capelabs.com> Signed-off-by: Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com> --- compress.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/compress.c b/compress.c index 15dfdb7..0c9ecd2 100644 --- a/compress.c +++ b/compress.c @@ -534,8 +534,6 @@ int compress_next_track(struct compress *compress) if (!is_compress_running(compress)) return oops(compress, ENODEV, "device not ready"); - if (!compress->gapless_metadata) - return oops(compress, EPERM, "metadata not set"); if (ioctl(compress->fd, SNDRV_COMPRESS_NEXT_TRACK)) return oops(compress, errno, "cannot set next track\n"); compress->next_track = 1; -- 1.7.2.5

2 7

Re: [alsa-devel] Call for testing: ALSA driver for Fireworks/BeBoB based devices
by Brand, Mark (Mr) (Summerstrand Campus South) 07 Mar '14

07 Mar '14

Hi Takashi, Thank you once again! Your comments have been very helpful. I now understand how to run ffado-dbus-server/ffado-mixer alongside your ALSA driver. I have pulled your revised Ozonic mixer from ffado-mixer, and when I now invoke ffado-mixer, it properly detects the Ozonic. I can also verify that the mixer control of my audio pass-through (which is plugged into inputs 3 & 4) works as expected. However, I have not yet been able to get audio playback (using "aplay -D plughw:2,0 Desktop/test.wav"). The .wav file is a short, 44.1/16 mono file saved from Audacity, if that's relevant. The terminal output of aplay seems to reflect successful playback, and I hear audible clicks as the file starts and ends its playback. The pass-through is also momentarily muted as aplay starts and stops. I have experimented with every conceivable combination of ffado-mixer settings, ultimately returning to the default settings that it was installed with. When aplay executes, the mixer app shows check marks next to both "Outgoing" and "Incoming". I have been testing the latest git version of the driver (updated this morning), and installing/uninstalling by DKMS. Please, is there anything you can suggest that I should try next? Is there anything obvious that I appear to have overlooked? I will try with a wider range of test materials tomorrow, as well as trying other ALSA apps, but I wanted to get this posted in case that's not the issue. I also recently saw some comments suggesting that pulseaudio be killed. Could that be the issue? I will investigate this tomorrow too. Thank you sincerely, Mark Brand. ________________________________________ From: Takashi Sakamoto [o-takashi(a)sakamocchi.jp] Sent: Sunday, February 23, 2014 9:55 AM To: Brand, Mark (Mr) (Summerstrand Campus South) Cc: alsa-devel(a)alsa-project.org; ffado-devel(a)lists.sf.net Subject: Re: Call for testing: ALSA driver for Fireworks/BeBoB based devices Hi Mark, Thanks for your testing. Ozonic is one of devices for which I test. > My testing is probably not particularly rigorous, and I would > sincerely appreciate your advice on what steps to follow > in order to verify your driver's functionality. Try playback/capture PCM samples/MIDI messages with ALSA applications. > In particular, you mention "(to control mixer channels please use > FFADO upstream)". My drivers don't give ways to control device's internal mixer. So you need the other stuff for this purpose. Please refer to this page. You can see some screenshots of ffado-mixer for 'M-Audio Ozonic'. I already commited these improvement to current FFADO trunk except for FW1814/ProjectMiX: MaudioBebob http://subversion.ffado.org/wiki/MaudioBebob > I have not yet set up FFADO on this machine, but I also see under > "Note": "- Don't use simultaneously 'ALSA PCM/MIDI playback/capture' > and 'jackd with Firewire (FFADO) backend'. Both of them try > connecting to the device when another is running." Would you please > explain? How should one rely on the "upstream" mixer functionality > while keeping jackd out of ALSA's way? Devices which my drivers support handle a pair of streams over IEEE1394 bus. PCM samples/MIDI messages are multiplexed into these streams. And snd-fireworks/snd-bebob uses 'duplex streams synchronization'. As a result: - ALSA PCM/MIDI functionality and jackd with firewire backend conflict for its streaming functionality. But: - ALSA PCM/MIDI fuctionality and ffado-dbus-server/ffado-mixer do not interrupt each other. > I open Audacity, which now lists "Ozonic: Ozonic PCM (hw:2,0)" as > ALSA input and output options. However, no audio input is shown when > I try to monitor the audio input I confirm that Audacity has such bugs to detect ALSA PCM character devices. In detail, its PortAudio v19 codes includes bugs. I have no will to investigate this bug because it's not within my work for these drivers. > $aplay -D hw:2,0 test.wav > (where test.wav has been saved from Audacity) > ... and this responds with: > aplay: main:722: audio open error: Input/output error According to aplay codes, snd_pcm_open() generate this error. I guess that another application still uses PCM character device for Ozonic. > $ aplay -D hw:2,0 Desktop/test.wav > Playing WAVE 'Desktop/test.wav' : Signed 16 bit Little Endian, Rate > 44100 Hz, Mono aplay: set_params:1239: Channels count not available You MUST add 'c' option to indicate the number of channels with 'hw' PCM device. For convinience, use 'plughw' PCM device instead, like: $ aplay -D plughw:2,0 Desktop/test.wav I note an item: - A few days ago, I fixed bug to fail to start stream for Ozonic. See: bebob: fix mappling for MIDI conformant data in stream channels https://github.com/takaswie/snd-firewire-improve/commit/545ab7068f1d53b2b17… Thanks Takashi Sakamoto o-takashi(a)sakamocchi.jp ________________________________ NOTICE: Please note that this eMail, and the contents thereof, is subject to the standard NMMU eMail disclaimer which may be found at: http://www.nmmu.ac.za/disclaimer/email.htm

2 2

[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] [PATCH 00/15] ASoC: fsl-ssi: Driver cleanup
by Markus Pargmann 05 Mar '14

05 Mar '14

Hi, Here is a series of cleanups for the fsl-ssi driver. It would be great if someone with PPC hardware and this fsl-ssi unit could please test this series. I am not sure if the regmap patch works as expected on PPC as well. I tested this series on imx53 quick starter board and a custom board. Both with SSI as I2S slave. Regards, Markus Markus Pargmann (15): ASoC: fsl-ssi: Use regmap ASoC: fsl-ssi: Remove fsl_ssi_setup ASoC: fsl-ssi: Move debugging to seperate file ASoC: fsl-ssi: Use dev_name for DAI driver struct ASoC: fsl-ssi: Move imx-specific probe to seperate function ASoC: fsl-ssi: Remove useless DMA code ASoC: fsl-ssi: baud clock error handling ASoC: fsl-ssi: Cleanup probe function ASoC: fsl-ssi: Remove unnecessary variables from ssi_private ASoC: fsl-ssi: reorder and document fsl_ssi_private ASoC: fsl-ssi: Fix register values when disabling ASoC: fsl-ssi: Only enable baudclk when used ASoC: fsl-ssi: Set default dai-fmts ASoC: fsl-ssi: Transmit enable synchronization ASoC: fsl-ssi: Update binding documentation .../devicetree/bindings/sound/fsl,ssi.txt | 21 +- sound/soc/fsl/Kconfig | 1 + sound/soc/fsl/Makefile | 2 + sound/soc/fsl/fsl_ssi.c | 1167 ++++++++------------ sound/soc/fsl/fsl_ssi.h | 112 +- sound/soc/fsl/fsl_ssi_dbg.c | 163 +++ 6 files changed, 750 insertions(+), 716 deletions(-) create mode 100644 sound/soc/fsl/fsl_ssi_dbg.c -- 1.8.5.3

4 21

[alsa-devel] [PATCH 00/10] Simplify the code of TDM slot setting
by Xiubo Li 05 Mar '14

05 Mar '14

Xiubo Li (10): ASoC: core: Add snd_soc_dai_set_tdm_slot_xlate(). ASoC: fsl-utils: Add fsl_asoc_of_xlate_tdm_slot_mask() support. ASoC: fsl-esai: Add .of_xlate_tdm_slot_mask() support. ASoC: fsl-ssi: Add .of_xlate_tdm_slot_mask() support. ASoC: imx-ssi: Add .of_xlate_tdm_slot_mask() support. ASoC: simple-card: Use snd_soc_dai_set_tdm_slot_xlate() ASoC: blackfin: bf5xx-ad1836: Use snd_soc_dai_set_tdm_slot_xlate() ASoC: blackfin: bf5xx-ad193x: Use snd_soc_dai_set_tdm_slot_xlate() ASoC: fsl: eukrea-tlv320: Use snd_soc_dai_set_tdm_slot_xlate() ASoC: fsl: wm1133-ev1: Use snd_soc_dai_set_tdm_slot_xlate() include/sound/soc-dai.h | 3 +++ sound/soc/blackfin/bf5xx-ad1836.c | 2 +- sound/soc/blackfin/bf5xx-ad193x.c | 4 ++-- sound/soc/fsl/Kconfig | 3 +++ sound/soc/fsl/eukrea-tlv320.c | 2 +- sound/soc/fsl/fsl_esai.c | 2 ++ sound/soc/fsl/fsl_ssi.c | 2 ++ sound/soc/fsl/fsl_utils.c | 27 +++++++++++++++++++++++++++ sound/soc/fsl/fsl_utils.h | 4 +++- sound/soc/fsl/imx-ssi.c | 2 ++ sound/soc/fsl/wm1133-ev1.c | 11 +---------- sound/soc/generic/simple-card.c | 7 +++---- sound/soc/soc-core.c | 33 ++++++++++++++++++++++++++++----- 13 files changed, 78 insertions(+), 24 deletions(-) -- 1.8.4

4 14

[alsa-devel] [PATCH v4-resend 0/7] ASoC: add CSR SiRFSoC sound drivers
by RongJun Ying 05 Mar '14

05 Mar '14

From: Rongjun Ying <rongjun.ying(a)csr.com> This patchset adds CSR SiRFSoC sound drivers including: 1. The SiRF internal audio codec driver 2. The SiRF audio port driver 3. The SiRF internal audio card driver 4. The SiRF I2S controller driver 5. The SiRF hdmi card driver 6. The SiRF USP controller(DSP mode) driver 7. The SiRF bt-sco card driver -v4: 1. Use the generic dmaengine pcm codes instead of sirf pcm driver. 2. Add TLV information into internal audio codec driver. 3. Use the MMIO regmap instead of custom read and write callbacks. 4. Remove spin_lock. 5. Change some variable names. 6. The SiRF internal audio driver split into codec, port. 7. Add binding documents. Rongjun Ying (7): ASoC: sirf: Add SiRF internal audio codec driver ASoC: sirf: Add SiRF audio port driver is used by SiRF internal audio codec ASoC: sirf: Add SiRF audio card ASoC: sirf: Add SiRF I2S driver ASoC: sirf: Add hdmi card ASoC: sirf: Add usp driver which is used by dsp mode ASoC: sirf: Add bt-sco card .../devicetree/bindings/sound/sirf-audio-codec.txt | 17 + .../devicetree/bindings/sound/sirf-audio-port.txt | 20 + .../devicetree/bindings/sound/sirf-audio.txt | 41 ++ .../devicetree/bindings/sound/sirf-bt-sco.txt | 18 + .../devicetree/bindings/sound/sirf-hdmi.txt | 15 + .../devicetree/bindings/sound/sirf-i2s.txt | 27 + .../devicetree/bindings/sound/sirf-usp.txt | 27 + sound/soc/Kconfig | 1 + sound/soc/Makefile | 1 + sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/sirf-audio-codec.c | 585 ++++++++++++++++++++ sound/soc/codecs/sirf-audio-codec.h | 75 +++ sound/soc/sirf/Kconfig | 34 ++ sound/soc/sirf/Makefile | 13 + sound/soc/sirf/sirf-audio-port.c | 194 +++++++ sound/soc/sirf/sirf-audio-port.h | 62 ++ sound/soc/sirf/sirf-audio.c | 156 ++++++ sound/soc/sirf/sirf-bt-sco.c | 99 ++++ sound/soc/sirf/sirf-hdmi.c | 98 ++++ sound/soc/sirf/sirf-i2s.c | 438 +++++++++++++++ sound/soc/sirf/sirf-i2s.h | 88 +++ sound/soc/sirf/sirf-usp.c | 448 +++++++++++++++ sound/soc/sirf/sirf-usp.h | 282 ++++++++++ 24 files changed, 2745 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/sirf-audio-codec.txt create mode 100644 Documentation/devicetree/bindings/sound/sirf-audio-port.txt create mode 100644 Documentation/devicetree/bindings/sound/sirf-audio.txt create mode 100644 Documentation/devicetree/bindings/sound/sirf-bt-sco.txt create mode 100644 Documentation/devicetree/bindings/sound/sirf-hdmi.txt create mode 100644 Documentation/devicetree/bindings/sound/sirf-i2s.txt create mode 100644 Documentation/devicetree/bindings/sound/sirf-usp.txt create mode 100644 sound/soc/codecs/sirf-audio-codec.c create mode 100644 sound/soc/codecs/sirf-audio-codec.h create mode 100644 sound/soc/sirf/Kconfig create mode 100644 sound/soc/sirf/Makefile create mode 100644 sound/soc/sirf/sirf-audio-port.c create mode 100644 sound/soc/sirf/sirf-audio-port.h create mode 100644 sound/soc/sirf/sirf-audio.c create mode 100644 sound/soc/sirf/sirf-bt-sco.c create mode 100644 sound/soc/sirf/sirf-hdmi.c create mode 100644 sound/soc/sirf/sirf-i2s.c create mode 100644 sound/soc/sirf/sirf-i2s.h create mode 100644 sound/soc/sirf/sirf-usp.c create mode 100644 sound/soc/sirf/sirf-usp.h -- 1.7.5.4

4 18