ALSA SOC driver for s3c24xx: 8 bit sound fix
PATCH 1/1 ALSA SOC driver for s3c24xx: 8 bit sound fix
fixes playing/recording of 8 bit audio files.
Generated on 20081108 against v2.6.27
--- sound/soc/s3c24xx/s3c24xx-i2s.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-)
sound/soc/s3c24xx/s3c24xx-i2s.c +7 -0
@@ -261,10 +261,17 @@ static int s3c24xx_i2s_hw_params(struct snd_pcm_substream *substream,switch (params_format (params)) {case SNDRV_PCM_FORMAT_S8 : + iismod &= ~S3C2410_IISMOD_16BIT ; + ((struct s3c24xx_pcm_dma_params *) + rtd->dai->cpu_dai->dma_data)->dma_size =1 ;break ;case SNDRV_PCM_FORMAT_S16_LE : iismod |=S3C2410_IISMOD_16BIT ; + ((struct s3c24xx_pcm_dma_params *) + rtd->dai->cpu_dai->dma_data)->dma_size =2 ;break ; +default : +return -EINVAL ; }writel (iismod, s3c24xx_i2s.regs +S3C2410_IISMOD );
--
1.4.4.4
At Sat, 8 Nov 2008 08:44:16 +0100,
Quoted 18 lines · Christian Pellegrin
fixes playing/recording of 8 bit audio files.
Generated on 20081108 against v2.6.27
Signed-off-by Christian Pellegrin <[email protected]>--- sound/soc/s3c24xx/s3c24xx-i2s.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-)sound/soc/s3c24xx/s3c24xx-i2s.c +0
-0@@ -261,10 +261,17 @@ static int s3c24xx_i2s_hw_params(struct snd_pcm_substream *substream,switch (params_format (params)) {
sound/soc/s3c24xx/s3c24xx-i2s.c static int s3c24xx_i2s_hw_params(struct snd_pcm_substream *substream, · line 272
Quoted 10 lines
sound/soc/s3c24xx/s3c24xx-i2s.c +5
-0case SNDRV_PCM_FORMAT_S8 : + iismod &= ~S3C2410_IISMOD_16BIT ; + ((struct s3c24xx_pcm_dma_params *) + rtd->dai->cpu_dai->dma_data)->dma_size =1 ;break ;case SNDRV_PCM_FORMAT_S16_LE : iismod |=S3C2410_IISMOD_16BIT ; + ((struct s3c24xx_pcm_dma_params *) + rtd->dai->cpu_dai->dma_data)->dma_size =2 ;break ;
I don't think it's good to overwrite the global variables in this way.
And, what if playback and capture use the different formats in full duplex streams...?
thanks,
Takashi
Hi,
Quoted 4 lines · Takashi Iwai
At Sat, 8 Nov 2008 08:44:16 +0100,
I don't think it's good to overwrite the global variables in this way.
I see. I just tried to keep the modifications minimal. Perhaps Ben Dooks, the author of the code, can suggest a better way to proceed. I will be happy to follow his suggestion.
Quoted 3 lines
And, what if playback and capture use the different formats in full duplex streams...?
I dont' think that this is possible on the S3C24{1,4}0 since the configuration registers are shared between playback and record path (so this applies to sample frequency too for example). I guess you are suggesting that given parameters should be checked against those of the currently playing stream to see if they are compatible?
Signature · 5 lines
Christian Pellegrin, see http://www.evolware.org/chri/ "Real Programmers don't play tennis, or any other sport which requires you to change clothes. Mountain climbing is OK, and Real Programmers wear their climbing boots to work in case a mountain should suddenly spring up in the middle of the computer room."
At Mon, 10 Nov 2008 08:20:13 +0100,
Quoted 4 lines · chri
Hi,
On Mon, Nov 10, 2008 at 7:50 AM, Takashi Iwai <[email protected]> wrote:
Quoted 8 lines
Quoted 4 lines
At Sat, 8 Nov 2008 08:44:16 +0100,
I don't think it's good to overwrite the global variables in this way.
I see. I just tried to keep the modifications minimal. Perhaps Ben Dooks, the author of the code, can suggest a better way to proceed. I will be happy to follow his suggestion.
OK.
Quoted 9 lines
Quoted 3 lines
And, what if playback and capture use the different formats in full duplex streams...?
I dont' think that this is possible on the S3C24{1,4}0 since the configuration registers are shared between playback and record path (so this applies to sample frequency too for example). I guess you are suggesting that given parameters should be checked against those of the currently playing stream to see if they are compatible?
Yes. Without a proper check and/or hw_param constraints, the driver thinks the streams are individual and allows apps to set up independent parameters, which may result in a hardware error.
Creating hw constraints sharing both playback and capture streams is a bit tricky and even racy. But, it'd be much better than nothing.
thanks,
Takashi
Quoted 3 lines · Takashi Iwai
Yes. Without a proper check and/or
hw_paramconstraints, the driver thinks the streams are individual and allows apps to set up independent parameters, which may result in a hardware error.
Of course, since the driver isn't doing this yet we probably shouldn't hold up any other fixes for it - it's needed anyway :/