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

[alsa-devel] [PATCH] ASoC: soc-cache: Ensure consistent cache naming
by Dimitris Papastamos 29 Nov '10

29 Nov '10

Signed-off-by: Dimitris Papastamos <dp(a)opensource.wolfsonmicro.com> --- include/sound/soc.h | 2 +- sound/soc/soc-cache.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index 3eb92ef..9e593cf 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -256,7 +256,7 @@ enum snd_soc_control_type { }; enum snd_soc_compress_type { - SND_SOC_NO_COMPRESSION, + SND_SOC_FLAT_COMPRESSION, SND_SOC_LZO_COMPRESSION, SND_SOC_RBTREE_COMPRESSION }; diff --git a/sound/soc/soc-cache.c b/sound/soc/soc-cache.c index e5b1888..9b1ba33 100644 --- a/sound/soc/soc-cache.c +++ b/sound/soc/soc-cache.c @@ -1520,7 +1520,7 @@ static int snd_soc_flat_cache_init(struct snd_soc_codec *codec) /* an array of all supported compression types */ static const struct snd_soc_cache_ops cache_types[] = { { - .id = SND_SOC_NO_COMPRESSION, + .id = SND_SOC_FLAT_COMPRESSION, .init = snd_soc_flat_cache_init, .exit = snd_soc_flat_cache_exit, .read = snd_soc_flat_cache_read, -- 1.7.3.2

3 2

[alsa-devel] [PATCH] ASoC: soc-cache: Add error checking in the *_cache_sync functions
by Dimitris Papastamos 29 Nov '10

29 Nov '10

Ensure that we report any errors encountered during reads/writes in the cache syncing functions. Remove redundant newline in the source code. Signed-off-by: Dimitris Papastamos <dp(a)opensource.wolfsonmicro.com> --- sound/soc/soc-cache.c | 28 +++++++++++++++++++++------- 1 files changed, 21 insertions(+), 7 deletions(-) diff --git a/sound/soc/soc-cache.c b/sound/soc/soc-cache.c index 6c0589e..e5b1888 100644 --- a/sound/soc/soc-cache.c +++ b/sound/soc/soc-cache.c @@ -792,7 +792,6 @@ static struct snd_soc_rbtree_node *snd_soc_rbtree_lookup( return NULL; } - static int snd_soc_rbtree_insert(struct rb_root *root, struct snd_soc_rbtree_node *rbnode) { @@ -826,14 +825,19 @@ static int snd_soc_rbtree_cache_sync(struct snd_soc_codec *codec) struct rb_node *node; struct snd_soc_rbtree_node *rbnode; unsigned int val; + int ret; rbtree_ctx = codec->reg_cache; for (node = rb_first(&rbtree_ctx->root); node; node = rb_next(node)) { rbnode = rb_entry(node, struct snd_soc_rbtree_node, node); if (rbnode->value == rbnode->defval) continue; - snd_soc_cache_read(codec, rbnode->reg, &val); - snd_soc_write(codec, rbnode->reg, val); + ret = snd_soc_cache_read(codec, rbnode->reg, &val); + if (ret) + return ret; + ret = snd_soc_write(codec, rbnode->reg, val); + if (ret) + return ret; dev_dbg(codec->dev, "Synced register %#x, value = %#x\n", rbnode->reg, val); } @@ -1110,11 +1114,16 @@ static int snd_soc_lzo_cache_sync(struct snd_soc_codec *codec) struct snd_soc_lzo_ctx **lzo_blocks; unsigned int val; int i; + int ret; lzo_blocks = codec->reg_cache; for_each_set_bit(i, lzo_blocks[0]->sync_bmp, lzo_blocks[0]->sync_bmp_nbits) { - snd_soc_cache_read(codec, i, &val); - snd_soc_write(codec, i, val); + ret = snd_soc_cache_read(codec, i, &val); + if (ret) + return ret; + ret = snd_soc_write(codec, i, val); + if (ret) + return ret; dev_dbg(codec->dev, "Synced register %#x, value = %#x\n", i, val); } @@ -1390,12 +1399,15 @@ err_tofree: static int snd_soc_flat_cache_sync(struct snd_soc_codec *codec) { int i; + int ret; struct snd_soc_codec_driver *codec_drv; unsigned int val; codec_drv = codec->driver; for (i = 0; i < codec_drv->reg_cache_size; ++i) { - snd_soc_cache_read(codec, i, &val); + ret = snd_soc_cache_read(codec, i, &val); + if (ret) + return ret; if (codec_drv->reg_cache_default) { switch (codec_drv->reg_word_size) { case 1: { @@ -1418,7 +1430,9 @@ static int snd_soc_flat_cache_sync(struct snd_soc_codec *codec) BUG(); } } - snd_soc_write(codec, i, val); + ret = snd_soc_write(codec, i, val); + if (ret) + return ret; dev_dbg(codec->dev, "Synced register %#x, value = %#x\n", i, val); } -- 1.7.3.2

3 2

[alsa-devel] [PATCH 0/4] Fixes resource leaks for Samsung SoCs
by Axel Lin 29 Nov '10

29 Nov '10

This serial of patches fixes resource leaks for Samsung SoCs. Axel Lin (4): ASoC: Fix resource leask in goni_wm8994.c ASoC: Fix resource leask in neo1973_gta02_init() error path ASoC: Add missing gpio_free(S3C64XX_GPK(12)) in smartq_exit() ASoC: Fix resource leask in smdk_spdif.c sound/soc/samsung/goni_wm8994.c | 9 +++++++-- sound/soc/samsung/neo1973_gta02_wm8753.c | 22 +++++++++++----------- sound/soc/samsung/smartq_wm8987.c | 1 + sound/soc/samsung/smdk_spdif.c | 13 +++++++++---- 4 files changed, 28 insertions(+), 17 deletions(-) -- 1.7.2

5 9

Re: [alsa-devel] Blackfin ASoC drivers with multi-component
by Mark Brown 29 Nov '10

29 Nov '10

On Sun, Nov 28, 2010 at 09:27:17PM -0500, Zhang, Sonic wrote: [Reflowed into 80 columns] > We are busy with 2010R1 Linux on blackfin release based on kernel > 2.6.34. There is no activity in ADI on multi component audio drivers in > latest 2.6.37 rc kernel. However, we are switching to the 2011 > development cycle soon, which will cover some audio drivers on top of > the multi-component framework. Please bear in mind that 2.6.37 will be released probably around the end of next month so it's important to get testing and any fixes done before then.

1 0

[alsa-devel] Writing 20ms of AUDIO data
by Irfan Shaikh 29 Nov '10

29 Nov '10

Hello developers, Please can some tell me how can i configure my snd_pcm_writei so that i can write 20ms of audio data each time. Is there any way to find out the time duration interval of PCM frames we write to playback device {So that soem i can write each tie 20 millisec of audio data to device}. Thanks and regards, SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited ("Sasken") unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html

1 0

[alsa-devel] Is calling snd_pcm_sw_params() mandatory ?
by Raymond Yau 29 Nov '10

29 Nov '10

>>Twas brillig, and Raymond Yau at 24/07/10 04:51 did gyre and gimble: >> 2010/7/15 Colin Guthrie <gmane <at> colin.guthr.ie> >> >> >> Can I remove pulseaudio from mandriva 2000 ? >> >> I just want to test *libcanberra*-alsa alone ( i.e. *libcanberra* without >> pulseaudio ) >> >> when PA server abort, and *libcanberra*-pulse cannot connect to PA server , >> >> Will *libcanberra* use *libcanberra*-alsa connect to PA using alsa-pulse plugin >> ? > Use draksound (or via Mandriva Control Center) to disable pulseaudio and > the ALSA backend for canberra should be used instead. > It's based on the alternatives system and the file > /etc/sound/profiles/alsa/canberra.conf > Col It is strange that the alsa back end of libcanberra (http://git.0pointer.de/?p=libcanberra.git;a=blob;f=src/alsa.c) does not call snd_pcm_sw_params() Does alsa-lib has any check whether the application had called snd_pcm_sw_params() or it provide default values for those software parameters (e.g. start_threshold, stop_threshold) when the application only call snd_pcm_hw_params() and snd_pcm_prepare()

2 1

[alsa-devel] [PATCH] ALSA: hda: Use BIOS auto-parsing instead of existing model quirk for MEDION MD2
by Daniel Chen 29 Nov '10

29 Nov '10

Hi, Attached is a patch against current sound-2.6.git master HEAD that resolves a regression from 2.6.32 for the user's machine. Briefly, the existing quirk entry, ALC883_MEDION_MD2, is no longer necessary for the user's machine; we can use BIOS auto-parsing successfully. Please apply. Thanks, -Dan

2 1

[alsa-devel] Blackfin ASoC drivers with multi-component
by Mark Brown 29 Nov '10

29 Nov '10

I'm a little concerned that there have been no updates to the Blackfin audio drivers since the merge of multi-component ASoC (which is now in mainline and should be released as part of 2.6.37). This was a very big and invasive update, and experience with other architectures has been that there's usually at least some typos that need fixing. It'd be good to get some confirmation that the audio drivers have at least been tested with current mainline - if everything worked fine that's obviously excellent but it'd be good if someone could confirm that this is the case. There was some discussion with Mike at the time the drivers were merged but it sounded more like "I need to get the audio guys to look at this" than a report of actual testing and there's been nothing since.

2 1

[alsa-devel] bug in alsa-lib/snd_pcm_plugin_delay for capture?
by pl bossart 27 Nov '10

27 Nov '10

Since the PulseAudio commit 29acfd0e0413a9bd126782763ee2dcf10357546 I am seeing errors messages telling me that the information reported by snd_pcm_avail_delay is not accurate on the capture path, more specifically the delay is lower than the available samples. I spent a little bit of time to find the root cause, and I believe this is a problem with alsa-lib plugins. I never see any errors when using hw devices. Conversely I always have these errors when using the front: plugin (the pulseaudio default). When I looked at the code, I saw that snd_pcm_plugin_delay and snd_pcm_plugin_avail_update don't really match. There is additional code in snd_pcm_plugin_avail_update for the capture case that is not present when in the delay code, and that causes the delta between the values reported. Since I don't understand this code that has all kinds of mmap_commit/forward/undos, I have to ask higher powers for advice. Jaroslav, could you take a look at the code and let me know if my analysis is correct? Thanks, -Pierre

4 9

[alsa-devel] Xonar DS
by Thomas 27 Nov '10

27 Nov '10

Hello everyone, (Sorry about the double post between user and devel. But I realized I might actually get the answer in the dev because they maintain the page and the development of drivers) I have an interest in purchasing Asus Xonar DS but I stumbled on this "No headphone plug event detection yet." from http://www.alsa- project.org/main/index.php/Matrix:Vendor-Asus. I'm not exactly sure what the above means. Does it mean headphone cannot be detected if we were to plug them in? Headphone means a lot to me and if it cannot be detected, I would need to purchase something else. Thank you very much

1 0