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

[alsa-devel] CM6206, S/PDIF + JACK
by Dan MacDonald 14 Nov '12

14 Nov '12

Hi ALSA devs! I've got a Startech USB device based on the CM6206 chipset. It does work with JACK although I can only access the two mic inputs as JACK capture ports even though under alsamixer I can also see line in and SPDIF In. I bought it in the hope of using its SPDIF input under JACK. SPDIF is enabled under alsamixer and even when I start JACK with a signal coming in to SPDIF, I still get no SPDIF capture port.I have posted various ALSA logs and more details here: http://www.linuxmusicians.com/viewtopic.php?f=27&t=8898 I've already spoke to las about this but he couldn't help me, no knowing anything about these devices. Might I be able to get this working under JACK? Maybe I need a special ALSA config to enable SPDIF? Thanks! Dan

2 6

[alsa-devel] ALSA with dmix, help needed
by Sandulescu Bogdan 14 Nov '12

14 Nov '12

Hello, I am struggling for some time now with dmix plugin from ALSA. Could anyone please answer to these questions: 1. Is ALSA library with DMIX plugin suitable for real-time embedded systems: where it's needed small api latencies, fast output to dma/serial bus and no audible defects? 2. Is it reliable to use ALSA commands from different threads? (e.g. open() in one master thread, writei() from child threads)? 3. Is it normal that two consecutive writei() calls to generate underrun - this happens only just after opening the dmix device. e.g.: if( snd_pcm_writei(pPcmPlayHandle, (pu8WavDataBuf), 2048) < 0) fprintf(stderr, "Underrun encountered: application didn't sent enough data to the ALSA buffer \n"); if( snd_pcm_writei(pPcmPlayHandle, (pu8WavDataBuf+4096),2048) < 0) fprintf(stderr, "Underrun encountered: application didn't sent enough data to the ALSA buffer \n"); The second writei() generates this underrun error (-32), even though there is no delay between these two calls. The get_buff_size is 4096, get_buf_period = 1024. 4. The pcm_drain() help states: "for playback, wait for all pending frames to be played and then stop the PCM" But, how come the execution duration of this drain() takes longer than the actual sound duration? e.g. pcm_drain() takes 300-400 miliseconds, but the wav size sent to writei() is less than 100ms? I'm using ASLA lib 1.0.25, on a ARM controller with 440MHz, and no other high prio threads.

1 0

[alsa-devel] [PATCH 1/2] ALSA: core: fix NULL checking in snd_pcm_plug_client_size()
by Xi Wang 14 Nov '12

14 Nov '12

The dereference snd_pcm_plug_stream(plug) should come after the NULL check snd_BUG_ON(!plug). Signed-off-by: Xi Wang <xi.wang(a)gmail.com> --- sound/core/oss/pcm_plugin.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/core/oss/pcm_plugin.c b/sound/core/oss/pcm_plugin.c index 71cc3dd..f0d7b15 100644 --- a/sound/core/oss/pcm_plugin.c +++ b/sound/core/oss/pcm_plugin.c @@ -199,12 +199,13 @@ int snd_pcm_plugin_free(struct snd_pcm_plugin *plugin) snd_pcm_sframes_t snd_pcm_plug_client_size(struct snd_pcm_substream *plug, snd_pcm_uframes_t drv_frames) { struct snd_pcm_plugin *plugin, *plugin_prev, *plugin_next; - int stream = snd_pcm_plug_stream(plug); + int stream; if (snd_BUG_ON(!plug)) return -ENXIO; if (drv_frames == 0) return 0; + stream = snd_pcm_plug_stream(plug); if (stream == SNDRV_PCM_STREAM_PLAYBACK) { plugin = snd_pcm_plug_last(plug); while (plugin && drv_frames > 0) { -- 1.7.10.4

2 2

[alsa-devel] [patch] ALSA: fm801: precedence bug in snd_fm801_tea575x_get_pins()
by Dan Carpenter 14 Nov '12

14 Nov '12

There is a precedence bug because | has higher precedence than ?:. This code was cut and pasted and I fixed a similar bug a few days ago. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> diff --git a/sound/pci/fm801.c b/sound/pci/fm801.c index cc2e91d..c5806f8 100644 --- a/sound/pci/fm801.c +++ b/sound/pci/fm801.c @@ -767,9 +767,14 @@ static u8 snd_fm801_tea575x_get_pins(struct snd_tea575x *tea) struct fm801 *chip = tea->private_data; unsigned short reg = inw(FM801_REG(chip, GPIO_CTRL)); struct snd_fm801_tea575x_gpio gpio = *get_tea575x_gpio(chip); - - return (reg & FM801_GPIO_GP(gpio.data)) ? TEA575X_DATA : 0 | - (reg & FM801_GPIO_GP(gpio.most)) ? TEA575X_MOST : 0; + u8 ret; + + ret = 0; + if (reg & FM801_GPIO_GP(gpio.data)) + ret |= TEA575X_DATA; + if (reg & FM801_GPIO_GP(gpio.most)) + ret |= TEA575X_MOST; + return ret; } static void snd_fm801_tea575x_set_direction(struct snd_tea575x *tea, bool output)

2 1

[alsa-devel] [PATCH] ASoC: ab8500: Staticise non-exported ab85000_codec_dai
by Mark Brown 14 Nov '12

14 Nov '12

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/ab8500-codec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/ab8500-codec.c b/sound/soc/codecs/ab8500-codec.c index af54749..4d96090 100644 --- a/sound/soc/codecs/ab8500-codec.c +++ b/sound/soc/codecs/ab8500-codec.c @@ -2356,7 +2356,7 @@ static int ab8500_codec_set_dai_tdm_slot(struct snd_soc_dai *dai, return 0; } -struct snd_soc_dai_driver ab8500_codec_dai[] = { +static struct snd_soc_dai_driver ab8500_codec_dai[] = { { .name = "ab8500-codec-dai.0", .id = 0, -- 1.7.10.4

1 0

[alsa-devel] [PATCH v5 0/3] Add pinctrl support and enable audio
by Bo Shen 14 Nov '12

14 Nov '12

This patch set is based on linux next master branch The detail information as following: Git: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Branch: master Commit ID: 75e0ebabd87048b91e4189b90d4af8ef565115db Detail information about implement as following: - atmel ssc: add pinctrl support - atmel ssc dai: register dai and pcm directly - at91sam9g20ek wm8731: convert to dt support Bo Shen (3): ARM: at91: atmel-ssc: add pinctrl support ASoC: atmel-ssc-dai: register dai and pcm directly ASoC: at91sam9g20ek-wm8731: convert to dt support .../sound/atmel-at91sam9g20ek-wm8731-audio.txt | 26 +++ arch/arm/boot/dts/at91sam9260.dtsi | 18 ++ arch/arm/boot/dts/at91sam9263.dtsi | 36 ++++ arch/arm/boot/dts/at91sam9g20ek_common.dtsi | 34 ++- arch/arm/boot/dts/at91sam9g45.dtsi | 36 ++++ arch/arm/boot/dts/at91sam9n12.dtsi | 26 +++ arch/arm/boot/dts/at91sam9x5.dtsi | 32 ++- arch/arm/mach-at91/at91sam9260_devices.c | 9 - arch/arm/mach-at91/board-sam9g20ek.c | 8 +- drivers/misc/atmel-ssc.c | 8 + sound/soc/atmel/Kconfig | 3 +- sound/soc/atmel/atmel-pcm.c | 23 +- sound/soc/atmel/atmel-pcm.h | 3 + sound/soc/atmel/atmel_ssc_dai.c | 228 +++++--------------- sound/soc/atmel/atmel_ssc_dai.h | 1 + sound/soc/atmel/sam9g20_wm8731.c | 89 +++++++- 16 files changed, 357 insertions(+), 223 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/atmel-at91sam9g20ek-wm8731-audio.txt -- 1.7.9.5

2 11

[alsa-devel] [PATCH 1/3] ASoC: arizona: Add support for multiplexer with no associated mixer
by Charles Keepax 14 Nov '12

14 Nov '12

The Asynchronous Sample Rate Converters on the wm5102/wm5110 have no mixer attached to their input, but they do allow the input to be selected from a number of sources via a multiplexer. Currently the platform assumes the presence of 4 multiplexers and a mixer for each block. This patch adds support multiplexed single input blocks into the Arizona platform. Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/arizona.h | 40 ++++++++++++++++++++-------------------- 1 files changed, 20 insertions(+), 20 deletions(-) diff --git a/sound/soc/codecs/arizona.h b/sound/soc/codecs/arizona.h index 5a09127..f1c0ec9 100644 --- a/sound/soc/codecs/arizona.h +++ b/sound/soc/codecs/arizona.h @@ -94,33 +94,30 @@ extern int arizona_mixer_values[ARIZONA_NUM_MIXER_INPUTS]; const struct snd_kcontrol_new name##_mux = \ SOC_DAPM_VALUE_ENUM("Route", name##_enum) +#define ARIZONA_MUX_ENUMS(name, base_reg) \ + static ARIZONA_MUX_ENUM_DECL(name##_enum, base_reg); \ + static ARIZONA_MUX_CTL_DECL(name) + #define ARIZONA_MIXER_ENUMS(name, base_reg) \ - static ARIZONA_MUX_ENUM_DECL(name##_in1_enum, base_reg); \ - static ARIZONA_MUX_ENUM_DECL(name##_in2_enum, base_reg + 2); \ - static ARIZONA_MUX_ENUM_DECL(name##_in3_enum, base_reg + 4); \ - static ARIZONA_MUX_ENUM_DECL(name##_in4_enum, base_reg + 6); \ - static ARIZONA_MUX_CTL_DECL(name##_in1); \ - static ARIZONA_MUX_CTL_DECL(name##_in2); \ - static ARIZONA_MUX_CTL_DECL(name##_in3); \ - static ARIZONA_MUX_CTL_DECL(name##_in4) + ARIZONA_MUX_ENUMS(name##_in1, base_reg); \ + ARIZONA_MUX_ENUMS(name##_in2, base_reg + 2); \ + ARIZONA_MUX_ENUMS(name##_in3, base_reg + 4); \ + ARIZONA_MUX_ENUMS(name##_in4, base_reg + 6) #define ARIZONA_DSP_AUX_ENUMS(name, base_reg) \ - static ARIZONA_MUX_ENUM_DECL(name##_aux1_enum, base_reg); \ - static ARIZONA_MUX_ENUM_DECL(name##_aux2_enum, base_reg + 8); \ - static ARIZONA_MUX_ENUM_DECL(name##_aux3_enum, base_reg + 16); \ - static ARIZONA_MUX_ENUM_DECL(name##_aux4_enum, base_reg + 24); \ - static ARIZONA_MUX_ENUM_DECL(name##_aux5_enum, base_reg + 32); \ - static ARIZONA_MUX_ENUM_DECL(name##_aux6_enum, base_reg + 40); \ - static ARIZONA_MUX_CTL_DECL(name##_aux1); \ - static ARIZONA_MUX_CTL_DECL(name##_aux2); \ - static ARIZONA_MUX_CTL_DECL(name##_aux3); \ - static ARIZONA_MUX_CTL_DECL(name##_aux4); \ - static ARIZONA_MUX_CTL_DECL(name##_aux5); \ - static ARIZONA_MUX_CTL_DECL(name##_aux6) + ARIZONA_MUX_ENUMS(name##_aux1, base_reg); \ + ARIZONA_MUX_ENUMS(name##_aux2, base_reg + 8); \ + ARIZONA_MUX_ENUMS(name##_aux3, base_reg + 16); \ + ARIZONA_MUX_ENUMS(name##_aux4, base_reg + 24); \ + ARIZONA_MUX_ENUMS(name##_aux5, base_reg + 32); \ + ARIZONA_MUX_ENUMS(name##_aux6, base_reg + 40) #define ARIZONA_MUX(name, ctrl) \ SND_SOC_DAPM_VALUE_MUX(name, SND_SOC_NOPM, 0, 0, ctrl) +#define ARIZONA_MUX_WIDGETS(name, name_str) \ + ARIZONA_MUX(name_str " Input", &name##_mux) + #define ARIZONA_MIXER_WIDGETS(name, name_str) \ ARIZONA_MUX(name_str " Input 1", &name##_in1_mux), \ ARIZONA_MUX(name_str " Input 2", &name##_in2_mux), \ @@ -138,6 +135,9 @@ extern int arizona_mixer_values[ARIZONA_NUM_MIXER_INPUTS]; ARIZONA_MUX(name_str " Aux 5", &name##_aux5_mux), \ ARIZONA_MUX(name_str " Aux 6", &name##_aux6_mux) +#define ARIZONA_MUX_ROUTES(name) \ + ARIZONA_MIXER_INPUT_ROUTES(name " Input") + #define ARIZONA_MIXER_ROUTES(widget, name) \ { widget, NULL, name " Mixer" }, \ { name " Mixer", NULL, name " Input 1" }, \ -- 1.7.2.5

2 3

[alsa-devel] [PATCH v2 1/2] ASoC: mxs-saif: Fix channel swap for 24-bit format
by Fabio Estevam 14 Nov '12

14 Nov '12

Playing 24-bit format file leads to channel swap on mx28 and the reason is that the current driver performs one write/read to/from the SAIF_DATA register to trigger the transfer. This approach works fine for S16_LE case because SAIF_DATA is a 32-bit register and thus is capable of storing the 16-bit left and right channels, but for the S24_LE case it can only store one channel, so in order to not lose the FIFO sync an extra read/write is needed. Reported-by: Dan Winner <DWinner(a)tc-helicon.com> Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> Tested-by: Dan Winner <DWinner(a)tc-helicon.com> --- Changes since v1: - Clarify that the extra read/write is also safe for non 24-bit formats. sound/soc/mxs/mxs-saif.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/sound/soc/mxs/mxs-saif.c b/sound/soc/mxs/mxs-saif.c index aa037b2..0eb2883 100644 --- a/sound/soc/mxs/mxs-saif.c +++ b/sound/soc/mxs/mxs-saif.c @@ -523,16 +523,24 @@ static int mxs_saif_trigger(struct snd_pcm_substream *substream, int cmd, if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { /* - * write a data to saif data register to trigger - * the transfer + * write data to saif data register to trigger + * the transfer. + * For 24-bit format the 32-bit FIFO register stores + * only one channel, so we need to write twice. + * This is also safe for the other non 24-bit formats. */ __raw_writel(0, saif->base + SAIF_DATA); + __raw_writel(0, saif->base + SAIF_DATA); } else { /* - * read a data from saif data register to trigger - * the receive + * read data from saif data register to trigger + * the receive. + * For 24-bit format the 32-bit FIFO register stores + * only one channel, so we need to read twice. + * This is also safe for the other non 24-bit formats. */ __raw_readl(saif->base + SAIF_DATA); + __raw_readl(saif->base + SAIF_DATA); } master_saif->ongoing = 1; -- 1.7.9.5

4 6

[alsa-devel] [PATCH v3 1/2] aplay: Show usage if no parameter is passed
by Fabio Estevam 13 Nov '12

13 Nov '12

When aplay/arecord are called without any argument the application hangs forever. Instead of hanging, print the usage and exit. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- Changes since v2: - return 1 instead of 0 - Use stdout for the arecord case Changes since v1: - Also check for isatty, so that 'aplay < file.wav' can still work aplay/aplay.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/aplay/aplay.c b/aplay/aplay.c index 741979a..66cc78f 100644 --- a/aplay/aplay.c +++ b/aplay/aplay.c @@ -493,6 +493,7 @@ int main(int argc, char *argv[]) int tmp, err, c; int do_device_list = 0, do_pcm_list = 0; snd_pcm_info_t *info; + FILE *direction; #ifdef ENABLE_NLS setlocale(LC_ALL, ""); @@ -511,14 +512,21 @@ int main(int argc, char *argv[]) file_type = FORMAT_WAVE; command = "arecord"; start_delay = 1; + direction = stdout; } else if (strstr(argv[0], "aplay")) { stream = SND_PCM_STREAM_PLAYBACK; command = "aplay"; + direction = stdin; } else { error(_("command should be named either arecord or aplay")); return 1; } + if (isatty(fileno(direction)) && (argc == 1)) { + usage(command); + return 1; + } + chunk_size = -1; rhwparams.format = DEFAULT_FORMAT; rhwparams.rate = DEFAULT_SPEED; -- 1.7.9.5

3 3

Re: [alsa-devel] Races in alsa-lib with threads
by Krakora Robert-B42341 13 Nov '12

13 Nov '12

> From: Takashi Iwai [tiwai(a)suse.de] > Sent: Tuesday, November 13, 2012 2:30 AM > To: Trent Piepho > Cc: Krakora Robert-B42341; alsa-devel(a)alsa-project.org > Subject: Re: [alsa-devel] Races in alsa-lib with threads > > At Tue, 13 Nov 2012 02:14:08 -0500, > Trent Piepho wrote: > > > > On Tue, Nov 13, 2012 at 1:32 AM, Takashi Iwai <tiwai(a)suse.de> wrote: > > > At Mon, 12 Nov 2012 19:40:42 +0000 (UTC), > > > Rob Krakora wrote: > > >> Would you be able to point me the the ALSA documentation that indicates the > > >> stipulations on handle usage using multiple threads? I cannot find it. > > > > > > Think other way round: > > > The fact that it isn't documented means it's not safe to use in that > > > way :) > > > > > > The introduction on the alsa-project home page says, "SMP and > > thread-safe design. " Some people might misunderstand what > > thread-safe means. Maybe some clarification could be added. > > "Different streams are SMP and thread-safe (calls for the same stream > > must be serialized)." > > Yeah this should be corrected. SMP things are just about the kernel > side at that time. > > It's a Wiki, feel free to correct / improve the text. > > > Takashi Hi Takashi, The way that the GStreamer ALSA Sink Plugin is using ALSA Lib assumes that it is thread safe. The fix crafted by one of Trent's colleagues (attached) seems to be the way to go. However, I don't know how it would impact other functionality within ALSA Lib. Best Regards, Rob Krakora

1 0