[PATCH 1/2] ASoC: intel: atom: Stop advertising non working S24LE support
The SST firmware's media and deep-buffer inputs are hardcoded to S16LE, the corresponding DAIs don't have a hw_params callback and their prepare callback also does not take the format into account.
So far the advertising of non working S24LE support has not caused issues because pulseaudio defaults to S16LE, but changing pulse-audio's config to use S24LE will result in broken sound.
Pipewire is replacing pulse now and pipewire prefers S24LE over S16LE when available, causing the problem of the broken S24LE support to come to the surface now.
Cc: stable@vger.kernel.org BugLink: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/866 Signed-off-by: Hans de Goede hdegoede@redhat.com --- sound/soc/intel/atom/sst-mfld-platform-pcm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c b/sound/soc/intel/atom/sst-mfld-platform-pcm.c index 9e9b05883557..aa5dd590ddd5 100644 --- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c +++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c @@ -488,14 +488,14 @@ static struct snd_soc_dai_driver sst_platform_dai[] = { .channels_min = SST_STEREO, .channels_max = SST_STEREO, .rates = SNDRV_PCM_RATE_44100|SNDRV_PCM_RATE_48000, - .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE, + .formats = SNDRV_PCM_FMTBIT_S16_LE, }, .capture = { .stream_name = "Headset Capture", .channels_min = 1, .channels_max = 2, .rates = SNDRV_PCM_RATE_44100|SNDRV_PCM_RATE_48000, - .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE, + .formats = SNDRV_PCM_FMTBIT_S16_LE, }, }, { @@ -506,7 +506,7 @@ static struct snd_soc_dai_driver sst_platform_dai[] = { .channels_min = SST_STEREO, .channels_max = SST_STEREO, .rates = SNDRV_PCM_RATE_44100|SNDRV_PCM_RATE_48000, - .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE, + .formats = SNDRV_PCM_FMTBIT_S16_LE, }, }, {
The media and deep-buffer DAIs only support 48000 Hz samplerate, remove the 44100 sample-rate from their descriptions.
Signed-off-by: Hans de Goede hdegoede@redhat.com --- sound/soc/intel/atom/sst-mfld-platform-pcm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c b/sound/soc/intel/atom/sst-mfld-platform-pcm.c index aa5dd590ddd5..4124aa2fc247 100644 --- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c +++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c @@ -487,14 +487,14 @@ static struct snd_soc_dai_driver sst_platform_dai[] = { .stream_name = "Headset Playback", .channels_min = SST_STEREO, .channels_max = SST_STEREO, - .rates = SNDRV_PCM_RATE_44100|SNDRV_PCM_RATE_48000, + .rates = SNDRV_PCM_RATE_48000, .formats = SNDRV_PCM_FMTBIT_S16_LE, }, .capture = { .stream_name = "Headset Capture", .channels_min = 1, .channels_max = 2, - .rates = SNDRV_PCM_RATE_44100|SNDRV_PCM_RATE_48000, + .rates = SNDRV_PCM_RATE_48000, .formats = SNDRV_PCM_FMTBIT_S16_LE, }, }, @@ -505,7 +505,7 @@ static struct snd_soc_dai_driver sst_platform_dai[] = { .stream_name = "Deepbuffer Playback", .channels_min = SST_STEREO, .channels_max = SST_STEREO, - .rates = SNDRV_PCM_RATE_44100|SNDRV_PCM_RATE_48000, + .rates = SNDRV_PCM_RATE_48000, .formats = SNDRV_PCM_FMTBIT_S16_LE, }, },
On 3/9/21 4:55 AM, Hans de Goede wrote:
The media and deep-buffer DAIs only support 48000 Hz samplerate, remove the 44100 sample-rate from their descriptions.
Signed-off-by: Hans de Goede hdegoede@redhat.com
This only worked when an SRC was added, but I don't think it was ever released, so
Acked-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com
sound/soc/intel/atom/sst-mfld-platform-pcm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c b/sound/soc/intel/atom/sst-mfld-platform-pcm.c index aa5dd590ddd5..4124aa2fc247 100644 --- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c +++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c @@ -487,14 +487,14 @@ static struct snd_soc_dai_driver sst_platform_dai[] = { .stream_name = "Headset Playback", .channels_min = SST_STEREO, .channels_max = SST_STEREO,
.rates = SNDRV_PCM_RATE_44100|SNDRV_PCM_RATE_48000,
.rates = SNDRV_PCM_RATE_48000,
.rates = SNDRV_PCM_RATE_44100|SNDRV_PCM_RATE_48000,
.rates = SNDRV_PCM_RATE_48000,@@ -505,7 +505,7 @@ static struct snd_soc_dai_driver sst_platform_dai[] = { .stream_name = "Deepbuffer Playback", .channels_min = SST_STEREO, .channels_max = SST_STEREO,
.rates = SNDRV_PCM_RATE_44100|SNDRV_PCM_RATE_48000,
.rates = SNDRV_PCM_RATE_48000,
On 3/9/21 4:55 AM, Hans de Goede wrote:
The SST firmware's media and deep-buffer inputs are hardcoded to S16LE, the corresponding DAIs don't have a hw_params callback and their prepare callback also does not take the format into account.
So far the advertising of non working S24LE support has not caused issues because pulseaudio defaults to S16LE, but changing pulse-audio's config to use S24LE will result in broken sound.
Pipewire is replacing pulse now and pipewire prefers S24LE over S16LE when available, causing the problem of the broken S24LE support to come to the surface now.
Cc: stable@vger.kernel.org BugLink: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/866 Signed-off-by: Hans de Goede hdegoede@redhat.com
Humm, that is strange. I can't recall such limitations in the firmware, and the SSP support does make use of 24 bits. Please give me a couple of days to double-check what's missing.
sound/soc/intel/atom/sst-mfld-platform-pcm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c b/sound/soc/intel/atom/sst-mfld-platform-pcm.c index 9e9b05883557..aa5dd590ddd5 100644 --- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c +++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c @@ -488,14 +488,14 @@ static struct snd_soc_dai_driver sst_platform_dai[] = { .channels_min = SST_STEREO, .channels_max = SST_STEREO, .rates = SNDRV_PCM_RATE_44100|SNDRV_PCM_RATE_48000,
.formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
.formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE,
.formats = SNDRV_PCM_FMTBIT_S16_LE,@@ -506,7 +506,7 @@ static struct snd_soc_dai_driver sst_platform_dai[] = { .channels_min = SST_STEREO, .channels_max = SST_STEREO, .rates = SNDRV_PCM_RATE_44100|SNDRV_PCM_RATE_48000,
.formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
Hi,
On 3/9/21 4:42 PM, Pierre-Louis Bossart wrote:
On 3/9/21 4:55 AM, Hans de Goede wrote:
The SST firmware's media and deep-buffer inputs are hardcoded to S16LE, the corresponding DAIs don't have a hw_params callback and their prepare callback also does not take the format into account.
So far the advertising of non working S24LE support has not caused issues because pulseaudio defaults to S16LE, but changing pulse-audio's config to use S24LE will result in broken sound.
Pipewire is replacing pulse now and pipewire prefers S24LE over S16LE when available, causing the problem of the broken S24LE support to come to the surface now.
Cc: stable@vger.kernel.org BugLink: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/866 Signed-off-by: Hans de Goede hdegoede@redhat.com
Humm, that is strange. I can't recall such limitations in the firmware, and the SSP support does make use of 24 bits. Please give me a couple of days to double-check what's missing.
Note this is not about the format between the DSP (the DSP's SSP) and the codec, this is the format between userspace and the DSP.
As is mentioned by the reporter of this issue: https://github.com/thesofproject/sof/issues/3868#issuecomment-796809535 Both in that issue but also here: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/530#note_791736
And independently reproduced by my here: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/866#note_830336
The S24LE format ATM does not work when passed from userspace, this is supposed to take 24 bits sampled packed into 32 bits ints (so padded with 1 0 byte to make 32 bits per sample), but to actually get working playback with the SST driver, the following commands are necessary:
ffmpeg -i /usr/share/sounds/alsa/Side_Left.wav -ar 96000 -f s32le -ac 2 test.raw aplay --dump-hw-params -D"hw:1,0" -r48000 -c2 -fS24_LE test.raw
Note how the ffmpeg command to generate a working set of raw samples is set to convert to full 32 bit samples, rather then 0 padded 24 bit samples. Generating a .raw file with the same -f s32le argument to ffmpeg and then playing it with aplay -fS24_LE while using the SOF driver results in static. Where as with the SST driver it results in working sound. This shows that the 2 clearly interpret the format differently and it looks like the SST driver is interpreting it wrong.
Maybe the SST driver should advertise S32_LE support instead, SOF advertised both S24_LE and S32_LE and the S32_LE format is the one which works with .raw files generated with ffmpeg's -f s32le option when using the SOF drv.
Note the format is not the only issue though, to get normal speed / pitch playback, the file needs to be converted to a sample rate of 96KHz and then played back at 48 KHz, hence the "-ar 96000" argument to ffmpeg to get normal playback when using aplay -fS24_LE with the SST driver.
Because of both these fmt and playback speed issues I decided to just drop the SNDRV_PCM_FMTBIT_S24_LE support in my patch. I guess we could try to fix it, but since the plan is the phase out the SST support for these devices this year I believe that we should not spend too much time on trying to fix the SST driver here. Dropping the SNDRV_PCM_FMTBIT_S24_LE is a simple workaround to bridge the time until we complete drop the SST support.
Regards,
Hans
sound/soc/intel/atom/sst-mfld-platform-pcm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c b/sound/soc/intel/atom/sst-mfld-platform-pcm.c index 9e9b05883557..aa5dd590ddd5 100644 --- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c +++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c @@ -488,14 +488,14 @@ static struct snd_soc_dai_driver sst_platform_dai[] = { .channels_min = SST_STEREO, .channels_max = SST_STEREO, .rates = SNDRV_PCM_RATE_44100|SNDRV_PCM_RATE_48000, - .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE, + .formats = SNDRV_PCM_FMTBIT_S16_LE, }, .capture = { .stream_name = "Headset Capture", .channels_min = 1, .channels_max = 2, .rates = SNDRV_PCM_RATE_44100|SNDRV_PCM_RATE_48000, - .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE, + .formats = SNDRV_PCM_FMTBIT_S16_LE, }, }, { @@ -506,7 +506,7 @@ static struct snd_soc_dai_driver sst_platform_dai[] = { .channels_min = SST_STEREO, .channels_max = SST_STEREO, .rates = SNDRV_PCM_RATE_44100|SNDRV_PCM_RATE_48000, - .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE, + .formats = SNDRV_PCM_FMTBIT_S16_LE, }, }, {
On 3/11/21 10:44 AM, Hans de Goede wrote:
Hi,
On 3/9/21 4:42 PM, Pierre-Louis Bossart wrote:
On 3/9/21 4:55 AM, Hans de Goede wrote:
The SST firmware's media and deep-buffer inputs are hardcoded to S16LE, the corresponding DAIs don't have a hw_params callback and their prepare callback also does not take the format into account.
So far the advertising of non working S24LE support has not caused issues because pulseaudio defaults to S16LE, but changing pulse-audio's config to use S24LE will result in broken sound.
Pipewire is replacing pulse now and pipewire prefers S24LE over S16LE when available, causing the problem of the broken S24LE support to come to the surface now.
Cc: stable@vger.kernel.org BugLink: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/866 Signed-off-by: Hans de Goede hdegoede@redhat.com
Humm, that is strange. I can't recall such limitations in the firmware, and the SSP support does make use of 24 bits. Please give me a couple of days to double-check what's missing.
Note this is not about the format between the DSP (the DSP's SSP) and the codec, this is the format between userspace and the DSP.
As is mentioned by the reporter of this issue: https://github.com/thesofproject/sof/issues/3868#issuecomment-796809535 Both in that issue but also here: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/530#note_791736
And independently reproduced by my here: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/866#note_830336
The S24LE format ATM does not work when passed from userspace, this is supposed to take 24 bits sampled packed into 32 bits ints (so padded with 1 0 byte to make 32 bits per sample), but to actually get working playback with the SST driver, the following commands are necessary:
ffmpeg -i /usr/share/sounds/alsa/Side_Left.wav -ar 96000 -f s32le -ac 2 test.raw aplay --dump-hw-params -D"hw:1,0" -r48000 -c2 -fS24_LE test.raw
Note how the ffmpeg command to generate a working set of raw samples is set to convert to full 32 bit samples, rather then 0 padded 24 bit samples. Generating a .raw file with the same -f s32le argument to ffmpeg and then playing it with aplay -fS24_LE while using the SOF driver results in static. Where as with the SST driver it results in working sound. This shows that the 2 clearly interpret the format differently and it looks like the SST driver is interpreting it wrong.
Maybe the SST driver should advertise S32_LE support instead, SOF advertised both S24_LE and S32_LE and the S32_LE format is the one which works with .raw files generated with ffmpeg's -f s32le option when using the SOF drv.
Note the format is not the only issue though, to get normal speed / pitch playback, the file needs to be converted to a sample rate of 96KHz and then played back at 48 KHz, hence the "-ar 96000" argument to ffmpeg to get normal playback when using aplay -fS24_LE with the SST driver.
Because of both these fmt and playback speed issues I decided to just drop the SNDRV_PCM_FMTBIT_S24_LE support in my patch. I guess we could try to fix it, but since the plan is the phase out the SST support for these devices this year I believe that we should not spend too much time on trying to fix the SST driver here. Dropping the SNDRV_PCM_FMTBIT_S24_LE is a simple workaround to bridge the time until we complete drop the SST support.
ok, I agree. I added this capability back in 2015 in the upstream code based on the Android versions, and I *think* it was tested, but since there's overwhelming evidence of multiple issues let's revert this.
Fixes: 098c2cd281409 ("ASoC ASoC: Intel: Atom: add 24-bit support for media playback and capture") Acked-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com
On Tue, Mar 09, 2021 at 11:55:19AM +0100, Hans de Goede wrote:
Fixes: 098c2cd281409 ("ASoC ASoC: Intel: Atom: add 24-bit support for media playback and capture") Acked-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com
Fixes tag: Fixes: 098c2cd281409 ("ASoC ASoC: Intel: Atom: add 24-bit support for media playback and capture") Has these problem(s): - Subject does not match target commit subject Just use git log -1 --format='Fixes: %h ("%s")'
On Tue, 9 Mar 2021 11:55:19 +0100, Hans de Goede wrote:
The SST firmware's media and deep-buffer inputs are hardcoded to S16LE, the corresponding DAIs don't have a hw_params callback and their prepare callback also does not take the format into account.
So far the advertising of non working S24LE support has not caused issues because pulseaudio defaults to S16LE, but changing pulse-audio's config to use S24LE will result in broken sound.
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ASoC: intel: atom: Stop advertising non working S24LE support commit: aa65bacdb70e549a81de03ec72338e1047842883 [2/2] ASoC: intel: atom: Remove 44100 sample-rate from the media and deep-buffer DAI descriptions commit: 632aeebe1b7a3a8b193d71942a10e66919bebfb8
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
participants (3)
-
Hans de Goede -
Mark Brown -
Pierre-Louis Bossart