[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(-)

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