00:24 <clover[m]> I guess I should change the wiki

01:13 <steev> i really don't mind - but i grabbed what one mine should be by opening device manager and looking at what it was assigning. at some point, we'll hopefully have a way of grabbing it from wherever it gets stored in the system

02:50 <cenunix[m]> Clover you should use steevs method of setting bt address as well IMO, well at least on NixOS I was running into issues trying to use btmgmt in a service. It’s working now though and I’ll have the new overrides pushed to the x13s repo later today

06:19 <martiert> cenunix[m]: Are you running NixOS on the x13s? You don't happen to have a nix expression for that I can look at? It boots now, but strugling with some of the firmware

06:19 <steev> what firmware are you strugling with?

06:21 <martiert> the wifi firmware right now. It's more of a packaging issue for NixOS I think. I pull it from the aarch64-firmware repo, and the ath11k firmware repo. It looks similar to what I have on arch, but won't load amss.bin

06:23 <steev> by default, iirc, it looks in hw2.1 which should be a symlink to hw2.0 no idea why)

06:24 <steev> what is the error message you're getting though?

06:24 <martiert> yes for some reason the symlink is compressed. It exists in hw2.0, but the hw2.1 link is no longer a symlink

06:25 <steev> then symlink the file instead of the directory, should work

06:25 <steev> e.g. instead of hw2.1->hw2.0, hw2.1/amss.bin -> hw2.0/amss.bin

06:27 <steev> i think debian does it that way

06:27 <martiert> yeah I see that's how nix wants to do it, so that's what I'm trying to do now

06:36 <martiert> yeah, that worked. NixOS firmware is a symlink hell, so trying to symlink to ../hw2.0/amss.bin from different packages got weird. Had to patch the firmware I needed into the linux-firmware package, which was easy enough, though not as elegant as I hoped. Would still love to see cenunix[m] nix expressions though :)

06:43 <martiert> next up is installing pd-mapper and the alsa ucm config, and I'll have a working NixOS running on this thing. Which means I can again maintain all my computers with a single git repository :)

10:29 <srinik> steev: rx macro default digital gains are set to (0dB), but then again pa/pipewire voulme control for Headset are wired up to this digital gain which can go up to 40dB. which i guess is not correct I guess.

10:30 <srinik> steev: user changing volume with these controls will get an overly digital amplified audio.. i will look in the codec to see if there are any analog controls that i can wire up to volume control or limit this gain to some reasonable value

10:56 <ungeskriptet> hexdump0815: Did you manage to test UFS on sc7180?

14:24 <srinik> steev: https://termbin.com/cb0n this should help with headset high volume issue, let me know if it works for you, I can send a proper patch after that

14:32 <broonie> srinik: That isn't something I'd expect to see in the kernel, I'd expect it to be controlled in UCM.

14:33 <broonie> Headphone outputs are also line outputs normally and people do sometimes want to get full scale volume out.

14:39 <srinik> broonie: i looked at ucm in first place to limit this, but I could not spot any such facility, is snd_soc_limit_volume() not the right choice for machine drivers ?

14:40 <broonie> srinik: _limit_volume() is for things likemelting speakers due to putting too much power through them.

14:41 <broonie> In UCM I'd expect some other volume control in the path to be set such that no matter what the controls that applications get pointed at are set to the volumes are in a reasonable range, possibly it needs extending with some hints about sutiable defaults?

14:43 <srinik> broonie: this control has a range of -84dB to 40dB of digital gain, exposing all that range to user is really not desirable for quaulity reasons.

14:44 <broonie> I'm not sure you really need to limit here so much as to make sure that things pick a sensible value by default.

14:45 <broonie> Exposing things to the user != exposing things to userspace - I'd not expect the off the shelf volume control presented to the user to just be that if that's the raw value range.

14:45 <srinik> broonie: default these are set to 0dB which is good, but these are mapped to volume controls, which is the issue..

14:46 <broonie> Perhaps some other volume control should be picked?

14:50 <srinik> broonie: interestingly there is no other volume control in this digital path, there is HPHL, HPHR volume in analog path but it not having a impact, But I can try to play around that and see.

14:51 <broonie> I would expect the analog volume to be what userspace is told to control?

14:51 <broonie> But if it's not working that's obviously an issue.

14:52 <broonie> In general you want to leave the digital gains at roughly full scale and do as much control as possible in analog, this preserves the maximum resolution from the DAC.

14:52 <srinik> broonie: it works, but not as impact full as the digital one, may be the code is broken.. will debug..

14:53 <broonie> With a huge range like the digital gains have the extremes of gains are going to be much larger than most analog gains, modulo mutes.

18:46 <hexdump0815> ungeskriptet: sorry - i did not get to it last weekend, this week is very full, hopefully i'll be able to test it next weekend