Re: Getting equalizer to work on T14 Intel Gen 3 ( Alder Lake )
On Tue, 2023-08-08 at 17:27 +0200, Sylvain Munaut wrote:
Hi Seppo,
Thanks for the answer.
I had figured out some things on my own since originally asking the question and figured out how to create a topology file that had all the "normal" features in my default file (deep buffer and dynamic pipes for instance) and also add the 'eq' with a FIR and IIR in the playback path.
Warning: Do not play loud sounds from speakers to avoid damage! If the speaker sound is distorted, stop the playback immediately and drop the volume control.
Oh wow, I didn't know that was a possibility, thanks for the warning !
To set up equalizing this should be useful:
https://thesofproject.github.io/latest/algos/eq/equalizers_tuning.html
Yes, I've read that very attentively. Even got myself a UMIK-1 to make the measurements.
Nice, I think it's good value for money.
This was a quick test I made with REW (Room Eq Wizard) to capture the response : https://assets.chaos.social/media_attachments/files/110/735/051/339/246/082/...
That's a very good clean response to equalize, much better than what I saw in my T480 notebook. You could try to boost the mid frequencies with parameteric IIR EQ to not lose much of the loud bass resonance at ~800 Hz. Alternatively the FIR procedure might do everything automatically in 1k - 7k band.
Cutting the lowest bass should give practical headroom and give some protection for the speaker. The speaker displacement usually increases a lot below the resonance. Hitting the displacement limits will in long term break the speaker.
We don't have high-pass by default for speaker path in SOF. We could do it in platforms with separate speaker and headphone DAI but in HDA it's shared. You would need to set with sof-ctl the equalizers to pass- through when using headphones.
I didn't get a chance yet to actually try and design filters and load them. I'd like to do that using scipi instead of octave (just because I like making things harder for myself apparently :) and I haven't dug yet into what format the configuation of the filter is. I guess I need to read the octave code to know what all those numbers mean.
You can feed your measured response to example Octave scripts scripts and see what happens ;D Scipy seems to have a quite similar basic signal processing library as Octave and Matlab so should be possible to convert without need to re-invent everything if you like.
Probably something like 2nd or 4th order high-pass around 100 - 200 Hz is suitable. The band 500 - 10 kHz can be likely made flatter if you are able to measure the frequency response. With the added high-pass there should be practical signal-headroom to amplify in the EQ with few decibels. You should be able to create a custom topology to use for T14 so there is no need to run sof-ctl every time to set up the filters.
This was definitely an enlightening read, I must admit I had never thought about cutting off the low frequency there was no hope to recover to make head room to amplify/flatten the rest of the band.
The DRC component is not part of the signed firmware image, but I hope it will be later in future. It would be useful to make the speaker sound louder. But EQ should already give a noticeable improvement.
Ah yeah, I had seen the DRC mentioned a couple of times reading around SOF and was wondering if this could help too. Didn't realize of course you need the actual component to be present in the actual firmware for it to be loadable. I do have one of those upsquared sbc as well and I seem to remember those can load unsigned firmware so I could also use that for experimentation.
Yep, UP2, UPX, and Chromebooks in developer mode allow to run all open- source components. We don't have in git main support for UP2, but UPX with TGL platform is supported. SOF v2.2 works with UP2.
We are developing also an ALSA plugin version of SOF. It will enable to run all same algorithms in main CPU user space without restrictions.
Cheers, Seppo
Cheers,
Sylvain
--------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
On 8/9/23 06:10, Ingalsuo, Seppo wrote:
On Tue, 2023-08-08 at 17:27 +0200, Sylvain Munaut wrote:
Hi Seppo,
<snip>
Yep, UP2, UPX, and Chromebooks in developer mode allow to run all open- source components. We don't have in git main support for UP2, but UPX with TGL platform is supported. SOF v2.2 works with UP2.
We are developing also an ALSA plugin version of SOF. It will enable to run all same algorithms in main CPU user space without restrictions.
Not meaning to hijack the thread - but it triggered my filters because of it being a Lenovo platform and then tweaked my interest (I'm the technical lead for the Lenovo Linux program)
I frequently get complaints about the audio quality on our platforms in Linux related to Windows. I am *not* an audiophile...but I know it's something that really bothers folks.
Windows has all the Dolby audio processing which Linux doesn't get (potentially we could get it one day...but as it would be closed source I don't know that I'm enthusiastic about it anyway.
The page linked to (https://thesofproject.github.io/latest/algos/eq/equalizers_tuning.html) was really interesting. It's quite a bit outside my experience - but if there's any opinion or thoughts on if Lenovo should perhaps look at doing some internal tuning for our Linux certified platforms and how easy/hard that would be I'd be interested.
We're a small team with limited resources but....we have the platforms and I'm sure I can wrangle some budget for some test equipment and then it's just finding the time and skills needed to make it work. Is it a systematic process that can be followed or is it something where there is personal opinion/flavour that gets added and is better left alone? I don't know if it's realistic to have a goal of some equaliser files that people could use...maybe as a starting point? Curious to get input from folk who actually work with this stuff as to what might be a good target and doable (and if there is anything we can help with).
Regardless - thanks for the conversation - it's interesting to follow along. Sylvain - hope the T14 is treating you well :)
Mark
On Wed, 2023-08-09 at 16:05 -0400, Mark Pearson wrote:
On 8/9/23 06:10, Ingalsuo, Seppo wrote:
On Tue, 2023-08-08 at 17:27 +0200, Sylvain Munaut wrote:
Hi Seppo,
<snip> > Yep, UP2, UPX, and Chromebooks in developer mode allow to run all open- > source components. We don't have in git main support for UP2, but UPX > with TGL platform is supported. SOF v2.2 works with UP2. > > We are developing also an ALSA plugin version of SOF. It will enable to > run all same algorithms in main CPU user space without restrictions.
Not meaning to hijack the thread - but it triggered my filters because of it being a Lenovo platform and then tweaked my interest (I'm the technical lead for the Lenovo Linux program)
Thanks for chiming in and great that you are subscribed!
I frequently get complaints about the audio quality on our platforms in Linux related to Windows. I am *not* an audiophile...but I know it's something that really bothers folks.
Windows has all the Dolby audio processing which Linux doesn't get (potentially we could get it one day...but as it would be closed source I don't know that I'm enthusiastic about it anyway.
The page linked to (https://thesofproject.github.io/latest/algos/eq/equalizers_tuning.html) was really interesting. It's quite a bit outside my experience - but if there's any opinion or thoughts on if Lenovo should perhaps look at doing some internal tuning for our Linux certified platforms and how easy/hard that would be I'd be interested.
The needed measurements can be done with hobby grade tools in normal work environments or with very professional calibrated equipment in anechoic chambers. Audible improvements are possible with first, but compliance to standards like telecommunications require the latter level. In this case I don't think any standards control the results. If a pre-installed operating system is shipped with some communications suite, need to check case by case if there are. But in any case, tuned is better and closer to possible requirements than non-tuned.
The basic acoustical measurement, tuning and small expert groups evaluation of tuning options is not a big task per product if the logistics with topologies those hold the tunings is solved.
My colleagues who know better the options may chime in. We may have in ALSA user space, linux kernel and firmware & topology everything needed in place but we do not have in SOF a full example to follow.
We're a small team with limited resources but....we have the platforms and I'm sure I can wrangle some budget for some test equipment and then it's just finding the time and skills needed to make it work. Is it a systematic process that can be followed or is it something where there is personal opinion/flavour that gets added and is better left alone?
Since the equalizers tuning is never perfect even in a limited frequency band there is always subjective part left for the result. Few options to flatten the response with least side effects (loss of loudness, increased distortion) can be checked and subjectively tested in small scale (expert listening, or with tools like those simulate subjective opinion) but usually the decisions are made in a small team.
Objective measurements like loudness and distortion can support the subjective decisions. If there are no standards based requirements and no need for certification the process is simple.
ITU-T standards are always a good resource for this subject of objective and subjective audio quality.
I don't know if it's realistic to have a goal of some equaliser files that people could use...maybe as a starting point? Curious to get input from folk who actually work with this stuff as to what might be a good target and doable (and if there is anything we can help with).
I've worked myself in the past with smartphones where the process with 3GPP requirements was on the heavy side. Most possible objective measurable parameters had a range to comply with. In this case I think it's good to evaluate a very light process first and see if it's feasible for "ROI".
Regardless - thanks for the conversation - it's interesting to follow along. Sylvain - hope the T14 is treating you well :)
Yep, very interesting and welcome topic, thanks for sharing it to us on this list!
Cheers, Seppo
Mark
--------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Hi,
On Fri, 11 Aug 2023, Ingalsuo, Seppo wrote:
The basic acoustical measurement, tuning and small expert groups evaluation of tuning options is not a big task per product if the logistics with topologies those hold the tunings is solved.
My colleagues who know better the options may chime in. We may have in ALSA user space, linux kernel and firmware & topology everything needed in place but we do not have in SOF a full example to follow.
we indeed already have the infra in place to do per-product tunings.
ALSA allows to load UCM files per DMI id, so a specific product model can be identified by its DMI information, and a tailored UCM file can be used (e.g. instead of the generic UCM file for HDA-codec equipped laptops). In the UCM file, a typical addition is to ensure that the EQ/DRC is only applied when the PCM is routed to speakers, and disabled when headset or a line output is used (by default we should have neutral processing for this case).
Second part is to instruct the kernel to load an alternative SOF DSP topology file for the product (so that needed components like EQ are loaded to the DSP). A tried and tested solution to do this is to ship a udev file that checks the DMI id, and modifies the tplg name when loading SOF module.
This allows to proceed incrementally. I.e. tuning can be provided to a subset of products and rest of the systems are unaffected. No changes to kernel or firmware are needed, so this can be done with user-space packages/changes alone, with UCM and tplg files.
Br, Kai
Hi all,
On 8/11/23 09:54, Kai Vehmanen wrote:
Hi,
On Fri, 11 Aug 2023, Ingalsuo, Seppo wrote:
The basic acoustical measurement, tuning and small expert groups evaluation of tuning options is not a big task per product if the logistics with topologies those hold the tunings is solved.
My colleagues who know better the options may chime in. We may have in ALSA user space, linux kernel and firmware & topology everything needed in place but we do not have in SOF a full example to follow.
we indeed already have the infra in place to do per-product tunings.
ALSA allows to load UCM files per DMI id, so a specific product model can be identified by its DMI information, and a tailored UCM file can be used (e.g. instead of the generic UCM file for HDA-codec equipped laptops). In the UCM file, a typical addition is to ensure that the EQ/DRC is only applied when the PCM is routed to speakers, and disabled when headset or a line output is used (by default we should have neutral processing for this case).
Second part is to instruct the kernel to load an alternative SOF DSP topology file for the product (so that needed components like EQ are loaded to the DSP). A tried and tested solution to do this is to ship a udev file that checks the DMI id, and modifies the tplg name when loading SOF module.
This allows to proceed incrementally. I.e. tuning can be provided to a subset of products and rest of the systems are unaffected. No changes to kernel or firmware are needed, so this can be done with user-space packages/changes alone, with UCM and tplg files.
Br, Kai
Thanks Kai & Seppo for the replies - sorry for the slow response :)
This sounds awesome - and I'd love to look at the next steps. I think I'd need to know what to do next. We do have all the professional acoustic chambers etc in the labs in Japan that are used for Thinkpad /w Windows (I got to visit them recently which was fun). We don't do anything for Linux but I'd like to try and see if we can - I just never knew where to start. We don't have any standards to hit - my aim is just to make the audio experience 'better'.
I'll ask the Japan team if anybody there is willing to take on the first steps of trying the tuning and see where we get. It might take a bit to get to (we're still working on getting our Linux preloads done for the 2023 platforms) but we usually get a bit of quiet(ish) time towards the end of the year where this would be a fun project.
Thanks again
Mark
participants (3)
-
Ingalsuo, Seppo -
Kai Vehmanen -
Mark Pearson