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

[alsa-devel] ASoC : playback and capture counts in soc_new_pcm
by JongHo Kim 29 Apr '13

29 Apr '13

Hi I am developing the ALSA ASoC part. I has some problem. Now my situation must only use the cpu_dai(AP I2S IP) to half duplex. So, I want to allocate either a capture substream or a playback substream. But ASoC(soc-pcm.c) referred to the playback(capture)_channel_min of codec_dai at the calling snd_pcm_new in soc_new_pcm. I do not want to modify the codec_dai codes. As a result, hope to see below /dev/snd/pcmC0D0p /dev/snd/pcmC0D1c attach the ASCII schematic diagram. Slaves Master +--------------+ +-----------------+ |I2S.0 data_out|---------------|data_in(AIF1) | |I2S.0 bclk |-------+-------|bclk | |I2S.0 lrclk |-------|--+----|lrclk | +--------------+ | | | | +--------------+ | | | AUDIO CODEC | |I2S.1 bclk |-------+ | | | |I2S.1 lrclk |----------+ | | |I2S.1 data_in |---------------|data_out(AIF1) | +--------------+ +-----------------+ attach the i2s and dai_link codes. ----------------------------------------------------------------------------- static struct snd_soc_dai_driver board_i2s_dai_hf_playback_template = { .probe = board_i2s_probe, .playback = { .stream_name = "Playback", .channels_min = 1, .channels_max = 2, .rates = SNDRV_PCM_RATE_8000_96000, .formats = SNDRV_PCM_FMTBIT_S16_LE, }, .ops = &board_i2s_dai_ops, }; static struct snd_soc_dai_driver board_i2s_dai_hf_capture_template = { .probe = board_i2s_probe, .capture = { .stream_name = "Capture", .channels_min = 1, .channels_max = 2, .rates = SNDRV_PCM_RATE_8000_96000, .formats = SNDRV_PCM_FMTBIT_S16_LE, }, .ops = &board_i2s_dai_ops, }; static struct snd_soc_dai_link board_dai[] = { { .name = "audcodec_l0", .stream_name = "audcodec HiFi", .cpu_dai_name = "board-i2s.0", .codec_dai_name = "audcodec-aif1", .platform_name = "board-pcm-audio", .codec_name = "audcodec-codec", .ops = &board_ops, }, { .name = "audcodec_l1", .stream_name = "audcodec HiFi", .cpu_dai_name = "board-i2s.1", .codec_dai_name = "audcodec-aif1", .platform_name = "board-pcm-audio", .codec_name = "audcodec-codec", .ops = &board_ops, }, }; ----------------------------------------------------------------------------- So, I suggest the next diff. --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -2014,9 +2014,11 @@ int soc_new_pcm(struct snd_soc_pcm_runtime *rtd, int num) if (cpu_dai->driver->capture.channels_min) capture = 1; } else { - if (codec_dai->driver->playback.channels_min) + if (codec_dai->driver->playback.channels_min && + cpu_dai->driver->playback.channels_min) playback = 1; - if (codec_dai->driver->capture.channels_min) + if (codec_dai->driver->playback.channels_min && + cpu_dai->driver->playback.channels_min) capture = 1; } Thanks.

2 2

[alsa-devel] ALSA SOC Driver (mxs-wm8753)
by John Graham 29 Apr '13

29 Apr '13

Hi there, I'm completely new to both kernel/ALSA driver programming (at least at a serious level) and was looking for some help on a project I'm working on - I'm part way there but I've kind of hit a brick wall and don't know where to turn. I'm trying to get a codec working on a new platform (new for the codec - the platform itself is not new). Here are the details: The audio codec is the Wolfson WM8753, which already has a codec driver in the kernel mainline tree. We also have a vendor-supplied (but GPL) patch to make the wm8753 work on a CC9M2443 (based on the Samsung S3C2443). This includes the glue code ("platform" code?) in sound/soc/s3c24xx/cc9m2443js_wm8753.c. We have a product with this combination fully working. The platform is the Karo TX28 (based on the Freescale i.MX28), and there are already drivers in the kernel tree to make the TX28 work with an SGTL5000 codec in sound/soc/mxs/mxs-sgtl5000.c. We also have a product with this combination fully working. Now we want to move the WM8753 over from the CC9M2443 to work on the TX28. To simplify, what I *have* is: CC9M2443 <----> WM8753 TX28 <----> SGTL5000 and what I *want* is: /-> WM8753 TX28 <-/ What I was hoping I could do was just "mash" the existing drivers together - i.e. copy sound/soc/mxs/mxs-sgtl5000.c into sound/soc/mxs/mxs-wm8753.c, change the parts in it that were specific for the SGTL5000 to the parts that drive the wm8753 in sound/soc/s3c24xx/cc9m2443js_wm8753.c, tell the TX28 to probe for it and that it would "magically work" (hey, crazier things have happened...). Obviously, it does not work, but I've got it a little way down the line. The WM8752 is probed for by the TX28 and recognized - the I2C control works, and you can change the mixer settings with amixer. When I try to record (using arecord) I can see with an oscilloscope the I2S clock lines look correct (in that they look the same as when the CC9M2443 talks to the WM8753 at the same audio rate). The problem now is that the I2S data lines don't look right - the line from codec to TX28 looks like a (more-or-less) square wave with the same period as the I2S clock, but only going from ~3.1 - ~3.5 V, as opposed to the 0 - ~3.3 V I expect. Furthermore, it's a pretty regular square wave - it doesn't have all the breaks you see on a working I2S data line. I know I probably haven't provided the right detail to get to the bottom of this problem, but part of my problem is that I'm so new to this that I'm not entirely sure where the problem might lie, or what extra detail to include to ask for more help. Is anyone able to point me in the right direction/suggest some ideas as to what might be wrong/anything else at all? Any help would be much appreciated - many thanks, John Graham

2 1

[alsa-devel] Configure a CODEC which has I2C connected to CPU, but no PCM bus connection
by Craig McQueen 29 Apr '13

29 Apr '13

I have an embedded device with somewhat unusual configuration: there is a second audio CODEC (Wolfson WM8940) which is connected to the PCM interface of another device (a radio module, which is acting as PCM bus master), so that radio device can do analog audio I/O. So there is no CPU<-->CODEC PCM link, but the CODEC _is_ connected to the CPU's I2C, and the CPU needs to configure the CODEC registers to interface to the radio module. See the attached diagram which shows a simplified view of the configuration. This configuration came about because both the CPU and the radio module can _only_ operate as PCM bus masters. I am not sure how I could fit this into the ALSA ASoC architecture. Is the ALSA ASoC driver architecture able to accommodate this scenario? Can I use the WM8940 driver to configure the second CODEC through I2C? Could I simply set up a machine driver that defines a DAI including a pointer to the WM8940 CODEC DAI, but NULL pointer for CPU DAI? Can I set it up so the Wolfson CODEC gains could appear as ALSA mixer widgets? Regards, Craig McQueen

2 1

[alsa-devel] [PATCH] ASoC: wm8962: Convert to devm_input_allocate_device()
by Mark Brown 29 Apr '13

29 Apr '13

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8962.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c index 50b0983..1cee9b3 100644 --- a/sound/soc/codecs/wm8962.c +++ b/sound/soc/codecs/wm8962.c @@ -3189,7 +3189,7 @@ static void wm8962_init_beep(struct snd_soc_codec *codec) struct wm8962_priv *wm8962 = snd_soc_codec_get_drvdata(codec); int ret; - wm8962->beep = input_allocate_device(); + wm8962->beep = devm_input_allocate_device(codec->dev); if (!wm8962->beep) { dev_err(codec->dev, "Failed to allocate beep device\n"); return; @@ -3210,7 +3210,6 @@ static void wm8962_init_beep(struct snd_soc_codec *codec) ret = input_register_device(wm8962->beep); if (ret != 0) { - input_free_device(wm8962->beep); wm8962->beep = NULL; dev_err(codec->dev, "Failed to register beep device\n"); } @@ -3227,7 +3226,6 @@ static void wm8962_free_beep(struct snd_soc_codec *codec) struct wm8962_priv *wm8962 = snd_soc_codec_get_drvdata(codec); device_remove_file(codec->dev, &dev_attr_beep); - input_unregister_device(wm8962->beep); cancel_work_sync(&wm8962->beep_work); wm8962->beep = NULL; -- 1.7.10.4

4 11

[alsa-devel] ALSA: usb-audio: caiaq: endianness bug
by Eldad Zack 29 Apr '13

29 Apr '13

Hi Daniel, I think I found a endian usage issue in the caiaq driver. I have a patch to fix it (below), but it assumes that the driver works currently on little endian CPUs - I don't have a device to test it with. Cheers, Eldad -- >8 -- Subject: [PATCH] ALSA: usb-audio: caiaq: fix endianness bug Current code does this: be16_to_cpu(buf[i * 2] << 8 | buf[(i * 2) + 1]) Which is effectively: be16_to_cpu(be16_to_cpu(*((u16 *) buf))) This means the int16 in the buffer is not converted at all. Assuming the device-side structure is actually little endian, change the code to use le16_to_cpu(). Signed-off-by: Eldad Zack <eldad(a)fogrefinery.com> --- sound/usb/caiaq/input.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/sound/usb/caiaq/input.c b/sound/usb/caiaq/input.c index efc70ae..2f4ae4d 100644 --- a/sound/usb/caiaq/input.c +++ b/sound/usb/caiaq/input.c @@ -488,13 +488,12 @@ static void snd_usb_caiaq_maschine_dispatch(struct snd_usb_caiaqdev *cdev, unsigned int len) { unsigned int i, pad_id; - uint16_t pressure; + __le16 *pressure = (__le16 *) buf; for (i = 0; i < MASCHINE_PADS; i++) { - pressure = be16_to_cpu(buf[i * 2] << 8 | buf[(i * 2) + 1]); - pad_id = pressure >> 12; - - input_report_abs(cdev->input_dev, MASCHINE_PAD(pad_id), pressure & 0xfff); + pad_id = le16_to_cpu(*pressure) >> 12; + input_report_abs(cdev->input_dev, MASCHINE_PAD(pad_id), le16_to_cpu(*pressure) & 0xfff); + pressure++; } input_sync(cdev->input_dev); -- 1.8.1.5

2 2

Re: [alsa-devel] linux-next: Tree for Apr 29 (sound/soc)
by Randy Dunlap 29 Apr '13

29 Apr '13

On 04/29/13 02:17, Stephen Rothwell wrote: > Hi all, > > Changes since 20130426: > on i386: CONFIG_I2C=m sound/built-in.o: In function `snd_soc_codec_set_cache_io': (.text+0x1ebe4): undefined reference to `regmap_init_i2c' make[1]: *** [vmlinux] Error 1 -- ~Randy

1 0

[alsa-devel] [PATCH 0/3] snd-firewire-lib: add handling CMP output connection
by Takashi Sakamoto 29 Apr '13

29 Apr '13

Current implementation of snd-firewire-lib can handle only CMP input connection. This series of patch enable it to handle both CMP output and input connection according to IEC 61883-1. Note that this series of patch still supports only a point-to-point connection without overlaying. The overlaying and any broadcast connection are not supported. Each connections gain its own isochronous resource. Takashi Sakamoto (3): rename macros, variables and functions related to CMP plug Add "direction" member to cmp_connection structure Add handling CMP output connection sound/firewire/cmp.c | 192 +++++++++++++++++++++++++++++++++------------ sound/firewire/cmp.h | 13 ++- sound/firewire/speakers.c | 2 +- 3 files changed, 152 insertions(+), 55 deletions(-) -- 1.7.10.4

2 12

[alsa-devel] Missing patches for 3.10 merge?
by Takashi Iwai 29 Apr '13

29 Apr '13

Hi, if anyone posted fix patches that should be applied to 3.10, but still unapplied, please let me know ASAP. I got a complete home (and system) FS crash on Friday (due to too much experiment with btrfs) and might have lost some incoming mails. thanks, Takashi

2 2

[alsa-devel] [PATCH] ALSA: compress: fix the states to check for allowing read
by Vinod Koul 29 Apr '13

29 Apr '13

for reading compressed data, we need to allow when we are paused, draining or stopped. Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> Cc: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> Cc: Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com> --- sound/core/compress_offload.c | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c index a0bc47f..5389b9a 100644 --- a/sound/core/compress_offload.c +++ b/sound/core/compress_offload.c @@ -311,8 +311,14 @@ static ssize_t snd_compr_read(struct file *f, char __user *buf, stream = &data->stream; mutex_lock(&stream->device->lock); - /* read is allowed when stream is running */ - if (stream->runtime->state != SNDRV_PCM_STATE_RUNNING) { + /* read is allowed when stream is running, paused, draining and setup + * (yes setup is state which we transistion to after stop, so if user + * wants to read data after stop we allow that + */ + if (stream->runtime->state != SNDRV_PCM_STATE_RUNNING || + stream->runtime->state != SNDRV_PCM_STATE_DRAINING || + stream->runtime->state != SNDRV_PCM_STATE_PAUSED || + stream->runtime->state != SNDRV_PCM_STATE_SETUP) { retval = -EBADFD; goto out; } -- 1.7.0.4

4 8

[alsa-devel] [PATCH] compress: fix the states to check for allowing read
by Vinod Koul 29 Apr '13

29 Apr '13

for reading compressed data, we need to allow when we are paused, draining or stopped. Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> Cc: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> Cc: Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com> --- sound/core/compress_offload.c | 12 ++++++++++-- 1 files changed, 10 insertions(+), 2 deletions(-) diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c index a0bc47f..7b774b7 100644 --- a/sound/core/compress_offload.c +++ b/sound/core/compress_offload.c @@ -311,8 +311,16 @@ static ssize_t snd_compr_read(struct file *f, char __user *buf, stream = &data->stream; mutex_lock(&stream->device->lock); - /* read is allowed when stream is running */ - if (stream->runtime->state != SNDRV_PCM_STATE_RUNNING) { + /* read is allowed when stream is running, paused, draining and setup + * (yes setup is state which we transition to after stop, so if user + * wants to read data after stop we allow that + */ + switch (stream->runtime->state) { + case SNDRV_PCM_STATE_OPEN: + case SNDRV_PCM_STATE_PREPARED: + case SNDRV_PCM_STATE_XRUN: + case SNDRV_PCM_STATE_SUSPENDED: + case SNDRV_PCM_STATE_DISCONNECTED: retval = -EBADFD; goto out; } -- 1.7.0.4

2 1