[alsa-devel] [PATCH 0/4] ASoC: fix saif record unwork issue
This patch series mainly fixes the saif record unwork issue. The root cause consists of: 1) clk_prepare and clk_enable un-balanced 2) missed setting a proper initial clock rate for saif in dt 3) sgtl5000 dapm widget kcontrol does not work So can not test record on mx28evk. 4) missed setting clkmux mode for saif in dt With this patch series it can fix sgtl5000 widget kcontrol unwork and saif record unwork issue. BTW, just let people konw, i still met a few overruns during record, that's another issue and will be fixed in separte patches later. Patch based on sound-2.6/for-3.6. Dong Aisheng (4): ASoC: mxs-saif: fix clock prepare and enable unbalance issue ASoC: mxs-saif: set a base clock rate for EXTMASTER mode work ASoC: sgtl5000: remove unneeded snd_soc_dapm_new_widgets in probe ARM: mx28evk: add missed clkmux select for saif arch/arm/mach-mxs/mach-mxs.c | 3 +++ sound/soc/codecs/sgtl5000.c | 2 -- sound/soc/mxs/mxs-saif.c | 24 ++++++++++++++++++++++++ 3 files changed, 27 insertions(+), 2 deletions(-)
From: Dong Aisheng <dong.aisheng@linaro.org> Currently we directly call a clock_enable in trigger function without a clk_prepare as pair first. This will cause system hang immediately when run capture because the clock was not prepared(playback does not hang because the clock was prepared already by get_mclk before), a warning message in clock framework may cause a deadlock to reclaim clock lock (see: pl011_console_write). Here we prepare clock first in hw_param, then enable it in trigger function to guarantee the balance. Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Liam Girdwood <lrg@ti.com> Cc: Wolfram Sang <w.sang@pengutronix.de> Cc: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> --- sound/soc/mxs/mxs-saif.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/sound/soc/mxs/mxs-saif.c b/sound/soc/mxs/mxs-saif.c index aba71bf..fdbb36a 100644 --- a/sound/soc/mxs/mxs-saif.c +++ b/sound/soc/mxs/mxs-saif.c @@ -394,9 +394,14 @@ static int mxs_saif_hw_params(struct snd_pcm_substream *substream, struct snd_soc_dai *cpu_dai) { struct mxs_saif *saif = snd_soc_dai_get_drvdata(cpu_dai); + struct mxs_saif *master_saif; u32 scr, stat; int ret; + master_saif = mxs_saif_get_master(saif); + if (!master_saif) + return -EINVAL; + /* mclk should already be set */ if (!saif->mclk && saif->mclk_in_use) { dev_err(cpu_dai->dev, "set mclk first\n"); @@ -420,6 +425,11 @@ static int mxs_saif_hw_params(struct snd_pcm_substream *substream, return ret; } + /* prepare clk in hw_param, enable in trigger */ + clk_prepare(saif->clk); + if (saif != master_saif) + clk_prepare(master_saif->clk); + scr = __raw_readl(saif->base + SAIF_CTRL); scr &= ~BM_SAIF_CTRL_WORD_LENGTH; -- 1.7.0.4
On Fri, Jul 20, 2012 at 05:20:24PM +0800, Dong Aisheng wrote:
From: Dong Aisheng <dong.aisheng@linaro.org>
Currently we directly call a clock_enable in trigger function without a clk_prepare as pair first. This will cause system hang immediately when run capture because the clock was not prepared(playback does not hang because the clock was prepared already by get_mclk before), a warning message in clock framework may cause a deadlock to reclaim clock lock (see: pl011_console_write).
Here we prepare clock first in hw_param, then enable it in trigger function to guarantee the balance.
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Liam Girdwood <lrg@ti.com> Cc: Wolfram Sang <w.sang@pengutronix.de> Cc: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
On Fri, Jul 20, 2012 at 05:20:24PM +0800, Dong Aisheng wrote:
From: Dong Aisheng <dong.aisheng@linaro.org>
Currently we directly call a clock_enable in trigger function without a clk_prepare as pair first.
Applied, thanks.
Dong Aisheng <b29396@freescale.com> writes:
From: Dong Aisheng <dong.aisheng@linaro.org>
Currently we directly call a clock_enable in trigger function without a clk_prepare as pair first. This will cause system hang immediately when run capture because the clock was not prepared(playback does not hang because the clock was prepared already by get_mclk before), a warning message in clock framework may cause a deadlock to reclaim clock lock (see: pl011_console_write).
Here we prepare clock first in hw_param, then enable it in trigger function to guarantee the balance.
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Liam Girdwood <lrg@ti.com> Cc: Wolfram Sang <w.sang@pengutronix.de> Cc: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> --- sound/soc/mxs/mxs-saif.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/sound/soc/mxs/mxs-saif.c b/sound/soc/mxs/mxs-saif.c index aba71bf..fdbb36a 100644 --- a/sound/soc/mxs/mxs-saif.c +++ b/sound/soc/mxs/mxs-saif.c @@ -394,9 +394,14 @@ static int mxs_saif_hw_params(struct snd_pcm_substream *substream, struct snd_soc_dai *cpu_dai) { struct mxs_saif *saif = snd_soc_dai_get_drvdata(cpu_dai); + struct mxs_saif *master_saif; u32 scr, stat; int ret;
+ master_saif = mxs_saif_get_master(saif); + if (!master_saif) + return -EINVAL; + /* mclk should already be set */ if (!saif->mclk && saif->mclk_in_use) { dev_err(cpu_dai->dev, "set mclk first\n"); @@ -420,6 +425,11 @@ static int mxs_saif_hw_params(struct snd_pcm_substream *substream, return ret; }
+ /* prepare clk in hw_param, enable in trigger */ + clk_prepare(saif->clk); + if (saif != master_saif) + clk_prepare(master_saif->clk); + scr = __raw_readl(saif->base + SAIF_CTRL);
scr &= ~BM_SAIF_CTRL_WORD_LENGTH; --
This is missing a matching clk_unprepare() call. -- Måns Rullgård
From: Dong Aisheng <dong.aisheng@linaro.org> Set an initial clock rate for the saif internal logic to work properly. This is important when working in EXTMASTER mode that uses the other saif's BITCLK&LRCLK but it still needs a basic clock which should be fast enough for the internal logic. Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Liam Girdwood <lrg@ti.com> Cc: Wolfram Sang <w.sang@pengutronix.de> Cc: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> --- sound/soc/mxs/mxs-saif.c | 16 +++++++++++++++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/sound/soc/mxs/mxs-saif.c b/sound/soc/mxs/mxs-saif.c index fdbb36a..b303071 100644 --- a/sound/soc/mxs/mxs-saif.c +++ b/sound/soc/mxs/mxs-saif.c @@ -427,8 +427,22 @@ static int mxs_saif_hw_params(struct snd_pcm_substream *substream, /* prepare clk in hw_param, enable in trigger */ clk_prepare(saif->clk); - if (saif != master_saif) + if (saif != master_saif) { + /* + * Set an initial clock rate for the saif internal logic to work + * properly. This is important when working in EXTMASTER mode + * that uses the other saif's BITCLK&LRCLK but it still needs a + * basic clock which should be fast enough for the internal + * logic. + */ + clk_enable(saif->clk); + ret = clk_set_rate(saif->clk, 24000000); + clk_disable(saif->clk); + if (ret) + return ret; + clk_prepare(master_saif->clk); + } scr = __raw_readl(saif->base + SAIF_CTRL); -- 1.7.0.4
On Fri, Jul 20, 2012 at 05:20:25PM +0800, Dong Aisheng wrote:
From: Dong Aisheng <dong.aisheng@linaro.org>
Set an initial clock rate for the saif internal logic to work properly. This is important when working in EXTMASTER mode that uses the other saif's BITCLK&LRCLK but it still needs a basic clock which should be fast enough for the internal logic.
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Liam Girdwood <lrg@ti.com> Cc: Wolfram Sang <w.sang@pengutronix.de> Cc: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
On Fri, Jul 20, 2012 at 05:20:25PM +0800, Dong Aisheng wrote:
From: Dong Aisheng <dong.aisheng@linaro.org>
Set an initial clock rate for the saif internal logic to work properly. This is important when working in EXTMASTER mode that uses the other saif's BITCLK&LRCLK but it still needs a basic clock which should be fast enough for the internal logic.
Applied, thanks.
From: Dong Aisheng <dong.aisheng@linaro.org> There's a driver bug that sgtl5000 dapm widget kcontrols do not work. e.g. can not select capture mux with amixer tool(no error info prompted). The root cause is that we still call snd_soc_dapm_new_widgets in codec driver probe function afer converting to table based widgets. This will cause the card dapm widgets are instantiated before the dapm_routes are registered. Then, no available dapm widget pathes can be found during instantiation which finally will cause soc_dapm_mux_update_power to fail(can not find correct path with kcontrol) in snd_soc_dapm_put_enum_double function. Here we remove the unneeded snd_soc_dapm_new_widgets in codec probe and let the soc core to handle the register sequence properly. Then we can fix above issue. Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Liam Girdwood <lrg@ti.com> Cc: Wolfram Sang <w.sang@pengutronix.de> Cc: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> --- sound/soc/codecs/sgtl5000.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c index 8af6a52..5c54b6f 100644 --- a/sound/soc/codecs/sgtl5000.c +++ b/sound/soc/codecs/sgtl5000.c @@ -1357,8 +1357,6 @@ static int sgtl5000_probe(struct snd_soc_codec *codec) if (ret) goto err; - snd_soc_dapm_new_widgets(&codec->dapm); - return 0; err: -- 1.7.0.4
On Fri, Jul 20, 2012 at 05:20:26PM +0800, Dong Aisheng wrote:
From: Dong Aisheng <dong.aisheng@linaro.org>
There's a driver bug that sgtl5000 dapm widget kcontrols do not work. e.g. can not select capture mux with amixer tool(no error info prompted).
The root cause is that we still call snd_soc_dapm_new_widgets in codec driver probe function afer converting to table based widgets. This will cause the card dapm widgets are instantiated before the dapm_routes are registered. Then, no available dapm widget pathes can be found during instantiation which finally will cause soc_dapm_mux_update_power to fail(can not find correct path with kcontrol) in snd_soc_dapm_put_enum_double function.
Here we remove the unneeded snd_soc_dapm_new_widgets in codec probe and let the soc core to handle the register sequence properly. Then we can fix above issue.
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Liam Girdwood <lrg@ti.com> Cc: Wolfram Sang <w.sang@pengutronix.de> Cc: Shawn Guo <shawn.guo@linaro.org>
On imx53-qsb board: Tested-by: Shawn Guo <shawn.guo@linaro.org>
On Fri, Jul 20, 2012 at 05:20:26PM +0800, Dong Aisheng wrote:
From: Dong Aisheng <dong.aisheng@linaro.org>
There's a driver bug that sgtl5000 dapm widget kcontrols do not work. e.g. can not select capture mux with amixer tool(no error info prompted).
Applied, thanks.
From: Dong Aisheng <dong.aisheng@linaro.org> Added missed clkmux setting for mx28evk. Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Liam Girdwood <lrg@ti.com> Cc: Wolfram Sang <w.sang@pengutronix.de> Cc: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> --- arch/arm/mach-mxs/mach-mxs.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c index 8cac94b..82f27a4 100644 --- a/arch/arm/mach-mxs/mach-mxs.c +++ b/arch/arm/mach-mxs/mach-mxs.c @@ -21,6 +21,7 @@ #include <asm/mach/arch.h> #include <asm/mach/time.h> #include <mach/common.h> +#include <mach/digctl.h> static int __init mxs_icoll_add_irq_domain(struct device_node *np, struct device_node *interrupt_parent) @@ -79,6 +80,8 @@ static void __init imx28_evk_init(void) clk = clk_get_sys("enet_out", NULL); if (!IS_ERR(clk)) clk_prepare_enable(clk); + + mxs_saif_clkmux_select(MXS_DIGCTL_SAIF_CLKMUX_EXTMSTR0); } static void __init mxs_machine_init(void) -- 1.7.0.4
On Fri, Jul 20, 2012 at 05:20:27PM +0800, Dong Aisheng wrote:
From: Dong Aisheng <dong.aisheng@linaro.org>
Added missed clkmux setting for mx28evk.
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Liam Girdwood <lrg@ti.com> Cc: Wolfram Sang <w.sang@pengutronix.de> Cc: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> --- arch/arm/mach-mxs/mach-mxs.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c index 8cac94b..82f27a4 100644 --- a/arch/arm/mach-mxs/mach-mxs.c +++ b/arch/arm/mach-mxs/mach-mxs.c @@ -21,6 +21,7 @@ #include <asm/mach/arch.h> #include <asm/mach/time.h> #include <mach/common.h> +#include <mach/digctl.h>
static int __init mxs_icoll_add_irq_domain(struct device_node *np, struct device_node *interrupt_parent) @@ -79,6 +80,8 @@ static void __init imx28_evk_init(void) clk = clk_get_sys("enet_out", NULL); if (!IS_ERR(clk)) clk_prepare_enable(clk); + + mxs_saif_clkmux_select(MXS_DIGCTL_SAIF_CLKMUX_EXTMSTR0);
Is this a board specific setup? Or every single imx28 based board that wants recording function is going to need this setup? BTW, the patch needs to get rebased on v3.6-rc1, where mach-mxs.c will have some context update. Regards, Shawn
}
static void __init mxs_machine_init(void) -- 1.7.0.4
_______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Sat, Jul 21, 2012 at 03:40:04PM +0800, Shawn Guo wrote:
On Fri, Jul 20, 2012 at 05:20:27PM +0800, Dong Aisheng wrote:
From: Dong Aisheng <dong.aisheng@linaro.org>
Added missed clkmux setting for mx28evk.
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Liam Girdwood <lrg@ti.com> Cc: Wolfram Sang <w.sang@pengutronix.de> Cc: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> --- arch/arm/mach-mxs/mach-mxs.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c index 8cac94b..82f27a4 100644 --- a/arch/arm/mach-mxs/mach-mxs.c +++ b/arch/arm/mach-mxs/mach-mxs.c @@ -21,6 +21,7 @@ #include <asm/mach/arch.h> #include <asm/mach/time.h> #include <mach/common.h> +#include <mach/digctl.h>
static int __init mxs_icoll_add_irq_domain(struct device_node *np, struct device_node *interrupt_parent) @@ -79,6 +80,8 @@ static void __init imx28_evk_init(void) clk = clk_get_sys("enet_out", NULL); if (!IS_ERR(clk)) clk_prepare_enable(clk); + + mxs_saif_clkmux_select(MXS_DIGCTL_SAIF_CLKMUX_EXTMSTR0);
Is this a board specific setup? Or every single imx28 based board that wants recording function is going to need this setup?
Yes, this is a board specific setup, just as non-dt does currently. Different boards may have different setting.
BTW, the patch needs to get rebased on v3.6-rc1, where mach-mxs.c will have some context update.
I can do it. This patch series was made based on Mark's sound-2.6 tree. Do you want this one go through mxs tree and other three go through Mark's tree? I'm thinking maybe it would be better go through one tree(Mark's or Yours) since without this one the saif record still can not work. Maybe go through yours may save some conflicts. Mark, What's your suggestion? Regards Dong Aisheng
On Mon, Jul 23, 2012 at 10:36:33AM +0800, Dong Aisheng wrote:
This patch series was made based on Mark's sound-2.6 tree. Do you want this one go through mxs tree and other three go through Mark's tree?
Yes. That's the way to save conflict.
I'm thinking maybe it would be better go through one tree(Mark's or Yours) since without this one the saif record still can not work.
The recording has been broken. There is no point to force the whole series to go via one tree. When sound and arm-soc get merged on linux-next (for testing) and mainline, the recording gets back to work. -- Regards, Shawn
On Sat, Jul 28, 2012 at 04:25:48PM +0800, Shawn Guo wrote:
On Mon, Jul 23, 2012 at 10:36:33AM +0800, Dong Aisheng wrote:
This patch series was made based on Mark's sound-2.6 tree. Do you want this one go through mxs tree and other three go through Mark's tree?
Yes. That's the way to save conflict.
I'm thinking maybe it would be better go through one tree(Mark's or Yours) since without this one the saif record still can not work.
The recording has been broken. There is no point to force the whole series to go via one tree. When sound and arm-soc get merged on linux-next (for testing) and mainline, the recording gets back to work.
Understand. Will rebase it and resend it for this one. Regards Dong Aisheng
Recording does not work. On 07/20/2012 12:20 PM, Dong Aisheng wrote:
This patch series mainly fixes the saif record unwork issue. The root cause consists of: 1) clk_prepare and clk_enable un-balanced 2) missed setting a proper initial clock rate for saif in dt 3) sgtl5000 dapm widget kcontrol does not work So can not test record on mx28evk. 4) missed setting clkmux mode for saif in dt
With this patch series it can fix sgtl5000 widget kcontrol unwork and saif record unwork issue.
BTW, just let people konw, i still met a few overruns during record, that's another issue and will be fixed in separte patches later.
Patch based on sound-2.6/for-3.6.
I see two different issues. 1. Recorded audio file is totally silent. Hexdump shows zeros. 2. Recording/playback after first recording gives following error "mxs-saif 80042000.saif: error: busy". Please look at following logs. Lauri $ uname -a Linux mx28evk 3.5.0-00004-g5b5b6fa #9 Tue Jul 24 15:21:25 EEST 2012 armv5tejl GNU/Linux $ arecord --version arecord: version 1.0.25 by Jaroslav Kysela <perex@perex.cz> $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: mxssgtl5000 [mxs_sgtl5000], device 0: HiFi Playback sgtl5000-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: mxssgtl5000 [mxs_sgtl5000], device 1: HiFi Capture sgtl5000-1 [] Subdevices: 1/1 Subdevice #0: subdevice #0 $ arecord -f cd test.wav Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo ^CAborted by signal Interrupt... $ hexdump -C test.wav 00000000 52 49 46 46 24 e0 0f 00 57 41 56 45 66 6d 74 20 |RIFF$...WAVEfmt | 00000010 10 00 00 00 01 00 02 00 44 ac 00 00 10 b1 02 00 |........D.......| 00000020 04 00 10 00 64 61 74 61 00 e0 0f 00 00 00 00 00 |....data........| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00100020 $ arecord -f cd test.wav Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo [ 90.610000] mxs-saif 80042000.saif: error: busy [ 90.620000] asoc: machine hw_params failed: -16 arecord: set_params:1145: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 32 CHANNELS: 2 RATE: 44100 PERIOD_TIME: (46439 46440) PERIOD_SIZE: 2048 PERIOD_BYTES: 8192 PERIODS: 8 BUFFER_TIME: (371519 371520) BUFFER_SIZE: 16384 BUFFER_BYTES: 65536 TICK_TIME: 0 $ aplay test.wav Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo [ 98.300000] mxs-saif 80042000.saif: error: busy [ 98.310000] asoc: machine hw_params failed: -16 aplay: set_params:1145: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 32 CHANNELS: 2 RATE: 44100 PERIOD_TIME: (46439 46440) PERIOD_SIZE: 2048 PERIOD_BYTES: 8192 PERIODS: 8 BUFFER_TIME: (371519 371520) BUFFER_SIZE: 16384 BUFFER_BYTES: 65536 TICK_TIME: 0 $ amixer Simple mixer control 'Headphone',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 122 [96%] [9.50dB] Front Right: Playback 122 [96%] [9.50dB] Simple mixer control 'Headphone Mux',0 Capabilities: enum Items: 'DAC' 'LINE_IN' Item0: 'LINE_IN' Simple mixer control 'Headphone Playback ZC',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [on] Simple mixer control 'PCM',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 192 Mono: Front Left: Playback 173 [90%] Front Right: Playback 173 [90%] Simple mixer control 'Mic',0 Capabilities: volume volume-joined penum Playback channels: Mono Capture channels: Mono Limits: 0 - 4 Mono: 2 [50%] [30.00dB] Simple mixer control 'Capture',0 Capabilities: cvolume penum Capture channels: Front Left - Front Right Limits: Capture 0 - 15 Front Left: Capture 14 [93%] Front Right: Capture 14 [93%] Simple mixer control 'Capture Attenuate Switch (-6dB)',0 Capabilities: volume volume-joined penum Playback channels: Mono Capture channels: Mono Limits: 0 - 2 Mono: 2 [100%] Simple mixer control 'Capture Mux',0 Capabilities: enum Items: 'MIC_IN' 'LINE_IN' Item0: 'LINE_IN' Simple mixer control 'Capture ZC',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [on]
On Tue, Jul 24, 2012 at 03:46:38PM +0300, Lauri Hintsala wrote:
1. Recorded audio file is totally silent. Hexdump shows zeros.
This one is commonly due to devices powering up muted by default and requiring that you set some controls to route the audio through - are you sure you've not missed anything there?
On 07/24/2012 10:21 PM, Mark Brown wrote:
On Tue, Jul 24, 2012 at 03:46:38PM +0300, Lauri Hintsala wrote:
1. Recorded audio file is totally silent. Hexdump shows zeros.
This one is commonly due to devices powering up muted by default and requiring that you set some controls to route the audio through - are you sure you've not missed anything there?
I tried to set gains and other settings with alsamixer. I didn't see any options for muting. Here is the output of amixer. $ amixer Simple mixer control 'Headphone',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 122 [96%] [9.50dB] Front Right: Playback 122 [96%] [9.50dB] Simple mixer control 'Headphone Mux',0 Capabilities: enum Items: 'DAC' 'LINE_IN' Item0: 'LINE_IN' Simple mixer control 'Headphone Playback ZC',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [on] Simple mixer control 'PCM',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 192 Mono: Front Left: Playback 173 [90%] Front Right: Playback 173 [90%] Simple mixer control 'Mic',0 Capabilities: volume volume-joined penum Playback channels: Mono Capture channels: Mono Limits: 0 - 4 Mono: 2 [50%] [30.00dB] Simple mixer control 'Capture',0 Capabilities: cvolume penum Capture channels: Front Left - Front Right Limits: Capture 0 - 15 Front Left: Capture 14 [93%] Front Right: Capture 14 [93%] Simple mixer control 'Capture Attenuate Switch (-6dB)',0 Capabilities: volume volume-joined penum Playback channels: Mono Capture channels: Mono Limits: 0 - 2 Mono: 2 [100%] Simple mixer control 'Capture Mux',0 Capabilities: enum Items: 'MIC_IN' 'LINE_IN' Item0: 'LINE_IN' Simple mixer control 'Capture ZC',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [on] The testing is not currently very reasonable. I have to reboot my machine after every single recording because of "busy" bug. Regards, Lauri
On Wed, Jul 25, 2012 at 01:26:38PM +0800, Lauri Hintsala wrote:
On 07/24/2012 10:21 PM, Mark Brown wrote:
On Tue, Jul 24, 2012 at 03:46:38PM +0300, Lauri Hintsala wrote:
1. Recorded audio file is totally silent. Hexdump shows zeros.
This one is commonly due to devices powering up muted by default and requiring that you set some controls to route the audio through - are you sure you've not missed anything there?
I tried to set gains and other settings with alsamixer. I didn't see any options for muting. Here is the output of amixer.
$ amixer Simple mixer control 'Headphone',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 122 [96%] [9.50dB] Front Right: Playback 122 [96%] [9.50dB] Simple mixer control 'Headphone Mux',0 Capabilities: enum Items: 'DAC' 'LINE_IN' Item0: 'LINE_IN' Simple mixer control 'Headphone Playback ZC',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [on] Simple mixer control 'PCM',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 192 Mono: Front Left: Playback 173 [90%] Front Right: Playback 173 [90%] Simple mixer control 'Mic',0 Capabilities: volume volume-joined penum Playback channels: Mono Capture channels: Mono Limits: 0 - 4 Mono: 2 [50%] [30.00dB] Simple mixer control 'Capture',0 Capabilities: cvolume penum Capture channels: Front Left - Front Right Limits: Capture 0 - 15 Front Left: Capture 14 [93%] Front Right: Capture 14 [93%] Simple mixer control 'Capture Attenuate Switch (-6dB)',0 Capabilities: volume volume-joined penum Playback channels: Mono Capture channels: Mono Limits: 0 - 2 Mono: 2 [100%] Simple mixer control 'Capture Mux',0 Capabilities: enum Items: 'MIC_IN' 'LINE_IN' Item0: 'LINE_IN' Simple mixer control 'Capture ZC',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [on]
The testing is not currently very reasonable. I have to reboot my machine after every single recording because of "busy" bug.
I reproduced your issue. It seems the root cause is that you used the wrong device to record. The record device is 1. root@freescale ~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: mxssgtl5000 [mxs_sgtl5000], device 0: HiFi Playback sgtl5000-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: mxssgtl5000 [mxs_sgtl5000], device 1: HiFi Capture sgtl5000-1 [] Subdevices: 1/1 Subdevice #0: subdevice #0 Can you try again with below command? arecord -D hw:0,1 -d 5 -f S16_LE -r 44100 -c 2 1.wav However, i think it is an issue of the driver that it should report an error if find user are using a device to do playback or capture without that capability. I'm wondering soc-core may need provide an interface for user to change the DAI capability according to the real using, e.g: only playback are used. I'm not sure if we already have one. Will do some research on it. Regards Dong Aisheng
On 07/25/2012 09:44 AM, Dong Aisheng wrote:
I reproduced your issue. It seems the root cause is that you used the wrong device to record. The record device is 1.
That was the problem. I used wrong device. I tried to record without parameter -D.
Can you try again with below command? arecord -D hw:0,1 -d 5 -f S16_LE -r 44100 -c 2 1.wav
This works fine. Thanks! Lauri
participants (5)
-
Dong Aisheng -
Lauri Hintsala -
Mark Brown -
Måns Rullgård -
Shawn Guo