[alsa-devel] [PATCH] ALSA SOC driver for s3c24xx: 8 bit sound fix
fixes playing/recording of 8 bit audio files.
Generated on 20081108 against v2.6.27
Signed-off-by: Christian Pellegrin chripell@fsfe.org --- sound/soc/s3c24xx/s3c24xx-i2s.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/sound/soc/s3c24xx/s3c24xx-i2s.c b/sound/soc/s3c24xx/s3c24xx-i2s.c index ba4476b..c18977b 100644 --- a/sound/soc/s3c24xx/s3c24xx-i2s.c +++ b/sound/soc/s3c24xx/s3c24xx-i2s.c @@ -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, Christian Pellegrin wrote:
fixes playing/recording of 8 bit audio files.
Generated on 20081108 against v2.6.27
Signed-off-by: Christian Pellegrin chripell@fsfe.org
sound/soc/s3c24xx/s3c24xx-i2s.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/sound/soc/s3c24xx/s3c24xx-i2s.c b/sound/soc/s3c24xx/s3c24xx-i2s.c index ba4476b..c18977b 100644 --- a/sound/soc/s3c24xx/s3c24xx-i2s.c +++ b/sound/soc/s3c24xx/s3c24xx-i2s.c @@ -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;((struct s3c24xx_pcm_dma_params *)rtd->dai->cpu_dai->dma_data)->dma_size = 2;
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,
On Mon, Nov 10, 2008 at 7:50 AM, Takashi Iwai tiwai@suse.de wrote:
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.
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?
At Mon, 10 Nov 2008 08:20:13 +0100, chri wrote:
Hi,
On Mon, Nov 10, 2008 at 7:50 AM, Takashi Iwai tiwai@suse.de wrote:
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.
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
On Mon, Nov 10, 2008 at 08:30:19AM +0100, Takashi Iwai wrote:
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.
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 :/
participants (4)
-
chri -
Christian Pellegrin
-
Mark Brown -
Takashi Iwai