thesofproject / sof

Sound Open Firmware
Other
541 stars 309 forks source link

[FEATURE] Missing codec adapter control for Waves MaxxAudio #7004

Open ignapk opened 1 year ago

ignapk commented 1 year ago

Describe the bug Lenovo Chromebook Flex 5i 13-ITL6 (LILLIPUP) on ChromeOS I have following controls:

localhost / # amixer -c 0 controls | grep Maxx
numid=76,iface=MIXER,name='CODEC_ADAPTER1.0 MaxxChrome Runtime 1'
numid=77,iface=MIXER,name='CODEC_ADAPTER1.0 MaxxChrome Setup 1'
numid=81,iface=MIXER,name='CODEC_ADAPTER2.0 MaxxChrome Runtime 2'
numid=80,iface=MIXER,name='CODEC_ADAPTER2.0 MaxxChrome Setup 2'

while no such controls are available on linux, and even though the sound is working, it's impossible to use following lines in ucm configuration:

cset-tlv "name='CODEC_ADAPTER1.0 MaxxChrome Setup 1' /opt/waves/lillipup/waves_params_speaker.bin"
cset-tlv "name='CODEC_ADAPTER2.0 MaxxChrome Setup 2' /opt/waves/lillipup/waves_params_headphone.bin"

which when present in ChromeOS give louder and richer sound compared to when deleted, and the comparison is analogous to that between ChromeOS with those lines and Linux.

To Reproduce amixer -c 0 controls | grep Maxx

Reproduction Rate all the time

Expected behavior Being able to see the CODEC_ADAPTER1.0 and 2.0 MaxxChrome controls

Impact It's rather a slight annoyance as in some situations the speakers aren't loud enough and it's sometimes hard to hear sound

Environment 1) Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).

dmesg.log, the kernel is patched with https://lore.kernel.org/lkml/394ec60d-33c0-1386-9445-eb0c596cc46c@collabora.com/T/

plbossart commented 1 year ago

It's not a bug @ignapk, it's just that you can't expect the firmware generated without closed-source libraries to behave the same as the one with closed-source libraries. sof-bin is based on publicly available code, the firmware used in ChromeOS is different.

ignapk commented 1 year ago

Thanks for quick reply and sorry for mistakenly reporting this as a bug. Could this maybe be changed to a Feature Request then? Do you know how I could debug this further, maybe extract necessary closed-source libraries from ChromeOS and somehow use them with Linux?

I've recorded some audio clip in ChromeOS with those cset-tlv commands in HiFi.conf and without them, and the same sound in Linux, and here are screenshots of audacity showing the difference in sound quality:

  1. The left part is without the commands, the right part is with them (both on ChromeOS) chromeos-comparison

  2. The left part is Linux, the right part is ChromeOS with the commands chromeos-linux-comparison

plbossart commented 1 year ago

There are no plans to include such closed-source libraries in sof-bin, due to obvious code license issues and lack of redistribution rights. You would have the same issue with Chromium I guess.

I can't comment on using closed-source binaries, the only 'open' recommendation I could make if you are trying to work-around loudness issues is to look at the DRC solution provided in the SOF tree (https://github.com/thesofproject/sof/tree/main/src/audio/drc) by @singalsu. That may be an option, though you may also need access to a Tensilica compiler to generate your own firmware.

BTW there are also closed-source firmware versions with speaker protection processing libraries, so you want to be careful with loudness experiments and not damage prematurely your hardware by driving those tiny speakers too hard.

singalsu commented 1 year ago

Some comments about open-source audio processing components.

We don't have examples but the IIR EQ and DRC can be used to enhance the speaker. If it's a small speaker, you could just with IIR in the speaker path suppress the low frequencies, e.g. like 4th order high-pass at 200 Hz and give something like 6 - 10 dB boost with the headroom from suppressed bass. With added DRC the boost & limiting could be done better there without clipping.

I've made an EQ tutorial but it has not yet been merged to SOF Docs https://github.com/thesofproject/sof-docs/pull/417 :(. Look at examples in tools/tune/eq. For DRC look at example in tools/tune/drc.

If the topology in the device is such that speaker is using a dedicated DAI that is not shared with headset path, the settings for EQ and DRC can be fixed and embedded to topology. No need to switch between flat and processed in runtime with UCM.

To get the processing to speaker path you need to learn to customize the topologies and replace pass-through or volume pipelines with processing pipelines.