bluetooth offload: sof_ipc4_init_input_audio_fmt: Unsupported audio format: 48000Hz, 16bit, 1 channels #1185
Comments
|
And FYI @fredoh9 aplay -Dhw:0,2 -r 48000 -c 1 -f S16_LE -d 3 /dev/zero -v -q Is not expected to work, so the test case runs the wrong commeand, but also this fails aplay -Dhw:0,2 -r 16000 -c 1 -f S16_LE -d 3 /dev/zero -v -q |
|
@kv2019i, what is in dmesg? What are not finding? |
Commit c77a4fe ("topology2: pcm_caps: Remove defaults for rate_min/rate_max") changed how rate constraints are described in topology. After this change, the rate_min/max was ignored by SOF Linux driver and the rate was incorrectly limited to 48000Hz for these topologies. Fix this issue by enumerating the supported sampling rates with "rates". Link: https://github.com/thesofproject/sof/issues/9067 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
|
So the rate was limited to 48000 always- Fix in thesofproject/sof#9068. There remains an issue with sof-test #1174 . The change to prioritize 48000 ("intentionally put 48000 first to make first in the list") has the unwanted side-effect that our "check-playback-all-formats" test plan will now try to play with: aplay -Dhw:0,2 -r 48000 -c 1 -f S16_LE -d 3 /dev/zero -v -q while before this tplgtool.py change, test was done with: aplay -Dhw:0,2 -r 8000 -c 1 -f S16_LE -d 3 /dev/zero -v -q Now both are actually within the capabilities advertized. The ALSA PCM capabilities do not allow us to describe the limitation that we don't support 48kHz 1ch 16bit on this PCM, so this will return an error if "hw:0,2" PCM access is used. |
|
Following sof-test patch avoids the problem and makes the daily test plan pass (with thesofproject/sof#9068), but not really a fix right: |
|
I wonder if the same issue present with other setups: |
|
As expected, all MTLP_RVP_NOCODEC-bluetooth-offload tests still failing in today's daily 40182 |
Commit c77a4fe ("topology2: pcm_caps: Remove defaults for rate_min/rate_max") changed how rate constraints are described in topology. After this change, the rate_min/max was ignored by SOF Linux driver and the rate was incorrectly limited to 48000Hz for these topologies. Fix this issue by enumerating the supported sampling rates with "rates". Link: https://github.com/thesofproject/sof/issues/9067 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
|
Daily tests 40387 are still all failing on MTLP_RVP_NOCODEC-bluetooth-offload even with today's commit 278ecc5b74ad "fix rate constraints". |
marc-hb
changed the title
|
@marc-hb wrote:
This is expected. The SOF tplg is now correct and FW behaves as expected. The test fails as sof-test tries a combination that is not supported: The PCM does not support opening 48kHz in mono/1ch mode, so this command is expected to fail. The problem is now how can sof-test no what to test. Current code assumes all combinations of supported channels and support sampling rates are supported, but this is not the case. Earlier this worked with some luck as sof-test picked a combination to test that happened to work. In any case, this is a sof-test problem now. |
I was about to transfer this issue to sof-test to avoid creating a new one (the context is spread in too many Github places already) but I'm not so sure now. Someone named @kv2019i wrote this: thesofproject/sof#9068 (comment)
If the required information isn't available in the first place then sof-test cannot divine it and this is just not usable and not testable, is it? Let's leave sof-test aside for a moment and focus on real use cases (which sof-test should be as close to as possible). How does "real" software know which combinations are valid versus not? Some UCM magic maybe? |
|
@marc-hb There are a possibilities. The alsa-lib C interface allows applications to discover such complex constraints. I.e. application can leave channel count as "open" or use the "_near" variants to ask a specific value but be open to adjust to hardware capabilities. sof-test does not use this interface, but rather it implements its own discover of capability and aplay/arecord are instructed to use specific settings via the "hw:x" layer and explicit setting of all key audio parameters. This makes sense as we want to specifically test the audio drivers and want to control the audio parameters used in the tests. In the specific case of BT, the set of supported audio formats comes from the set of Bluetooth profiles we support. That is currently HFP and A2DP and there is a enumerated set of formats the Bluetooth chip and audio DSP support. So it's hardcoded in the user-space code for BT offload that these specific audio formats are used. So a pragmatic solution would perhaps be to detect (in sof-test) we are testing Bluetooth offload, and ignore known bad audio format combinations. |
OK but how? In pseudo-code. cc: @yongzhi1 |
marc-hb
changed the title
marc-hb
changed the title
|
@kv2019i, in the kernel we can have rules (with |
|
@marc-hb I have no easy answer. Something along the lines of: Not sure how to implement the if condition check. This is a property of the tplg in the end. This is a clunky solution perhaps, but if the idea was to not write a completely new test for BT offload, we need to somehow figure out a way to decorate the generic test code so it can work with this specific type of tplg. |
|
right, a kernel side of hw_rule would not work for this for sure. If user space asks for not supported combination of channel and rate then ALSA will not allow it, but in a higher level, I guess we fail now with the copier format or blob lookup. |
It makes sense for sof-test to explicitly set parameters but it does not make sense for sof-test to be ignorant and not use the same discovery APIs as other ALSA applications (trying all combinations). sof-test is really an ALSA test suite in disguise, so ALSA discovery APIs should be part of the sof-test coverage - and this would also provide the data that has been missing here. In any case this looks like a major sof-test change. |
Trying to summarize a quick call with @ranj063 (thanks!), we have 4 more possible solutions:
|
The more I think about it. this seems like the most logical solution. Advertising a combination of rates/channels that cannot possibly work doesn't seem like the right thing to do |
|
@ranj063 wrote:
But this is not according to the design we have with CRAS. We identify a single PCM for offload and that single PCM is expected to support Bluetooth audio configurations. The number of configurations will increase later, so it will not scale to have distinct PCM for all possible combinations. The valid PCM values are standardized in the Bluetooth standards, so I'm not sure why we need to solve the discovery problem in a more generic fashion than is required for product use. |
|
I tend to agree with @kv2019i, here the test should know what it is testing. BT offload is a special case, needing special treatment. There is always going to be a corner case and whack a mole is not fun in a long run. But, if we really want to do this then we need topology change and kernel change to bring up the rules to aid discovery (which application can just not use and go hard for the non supported combination - again). |
marc-hb
added
the
type:test coverage gap
EDIT: this was https://github.com/thesofproject/sof/issues/9067, now transferred to sof-test
Describe the bug
SOF commit c77a4feb2f1f15a3a29edf49b091b4b4a507be48 breaks BT offload tplgs like sof-nocodec-bt-mtl-lbm.tplg .
To Reproduce
TPLG=/lib/firmware/intel/development/sof-nocodec-bt-mtl-lbm.tplg MODEL=MTLP_RVP_NOCODEC-bluetooth-offload SOF_TEST_INTERVAL=5 ~/sof-test/test-case/check-playback.sh -d 3 -l 1 -r 1 -F
Reproduction Rate
100%
Expected behavior
Playback works.
Impact
Playback fails.
Environment
SOF Commit:
c77a4feb2f1f
Linux Commit:
4ede2a0ed114
Name of the topology file
Name of the platform(s) on which the bug is observed.
Screenshots or console output
cc:
The text was updated successfully, but these errors were encountered: