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

Re: [alsa-devel] [PATCH 1/1] media: Entities with sink pads must have at least one enabled link
by Laurent Pinchart 14 Nov '12

14 Nov '12

Hi Sylwester, On Wednesday 14 November 2012 10:23:19 Sylwester Nawrocki wrote: > On 11/13/2012 03:24 PM, Sakari Ailus wrote: > > Hi all, > > > > Comments would be appreciated, either positive or negative. The omap3isp > > driver does the same check itself currently, but I think this is more > > generic than that. > > > > Thanks. > > > > On Fri, Oct 26, 2012 at 10:46:17PM +0300, Sakari Ailus wrote: > >> If an entity has sink pads, at least one of them must be connected to > >> another pad with an enabled link. If a driver with multiple sink pads has > >> more strict requirements the check should be done in the driver itself. > >> > >> Just requiring one sink pad is connected with an enabled link is enough > >> API-wise: entities with sink pads with only disabled links should not be > >> allowed to stream in the first place, but also in a different operation > >> mode a device might require only one of its pads connected with an > >> active link. > >> > >> If an entity has an ability to function as a source entity another > >> logical entity connected to the aforementioned one should be used for the > >> purpose. > > Why not leave it to individual drivers ? I'm not sure if it is a good idea > not to allow an entity with sink pads to be used as a source only. It might > be appropriate for most of the cases but likely not all. I'm inclined not to > add this requirement in the API. Just my opinion though. I have mixed feelings about this patch too, which is why I've asked Sakari to cross-post it. It's pretty easy to add this check to the core now, but pushing it back to drivers late if we realize it's too restrictive would be difficult. I think my preference would go for a helper function that drivers can use, possibly first waiting until a second driver requires this kind of checks before implementing it. -- Regards, Laurent Pinchart

1 0

[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