Volume change steps not changing

ARM Technical Assistance
1

The setting is: Manjaro ARM, Pipewire and my bluetooth earbuds.

The problem is, even if i change the volume change steps in KDE Plasma’s audio settings to 1% (which is very granular volume control), the minimum amount of volume steps stay the same which is around 6%. I tried to figure out where exactly the volume levels change and here are some of the exact volume steps in which the volume “actually” changes:
30 to 31
36 to 37
42 to 43
49 to 50
55 to 56
61 to 62… etc.

So basically, if i increase the volume from 43 to 49 for example, there is no audible change. The volume does not increase until you get it to 50 and after that 56 and after that 62. For sensitive ears, these are huge jumps. Is it possible that the recent updates caused this?:

[2024-11-03T17:23:27+0300] [ALPM] upgraded bluez (5.78-1 → 5.79-1)
[2024-11-03T17:23:27+0300] [ALPM] upgraded bluez-libs (5.78-1 → 5.79-1)
[2024-11-03T17:23:27+0300] [ALPM] upgraded bluez-utils (5.78-1 → 5.79-1)

2

Something I have to ask: has it always behaved this way? I suspect not, from the wording?

I’d just like to (potentially) rule out a possible hardware limitation. :wink:

3

I honestly do not know if it was always like this, i can not be sure. However, i think i know the cause. I have tried a different bluetooth headset and it actually allowed a finer volume control than the previous one i tried. I am assuming that whatever bluetooth audio interface is being used in Manjaro, it is allowing the volume control to be done by the actual bluetooth device itself, just like the android’s “absolute volume” (which can be disabled from the developer options). And whatever volume steps the particular device has can not be changed by the Plasma shell’s setting, because it is not actually controlling the volume.

So if i want the KDE Plasma’s volume app to actually control the bluetooth volume (basically disable the absolute volume), how can i do that?

4

I have found this thread in the forum, it did not really help me (i tried the solution to no avail) but maybe it can help others:

https://forum.manjaro.org/t/how-to-disable-absolute-volume-with-pipewire-pulse/162105

5

I have a similar issue on usual x86 since 2 months or so.

Previously, volume was changing from 1-100% nicely and then after the update, the only change is between 1-6%, while 7-100% are doing nothing because 6% is already a previous 100% volume.

I changed in Plasma volume step from 5% to 1% and basically control the volume between 2-7%. So each % increases volume 20%.

My findings are, that there is some mismatch between Plasma volume and pipewire. Haven’t found any fix to that so far.

6

Your issue is more serious than mine. Maybe you can open a bug report to pipewire github or something. My volume can go from 0 to 100. Only issue i have is that volume is not increasing or decreasing in small increments even if i try to do it. I have to raise/reduce it to certain percentages for it to change which means the volume control is not granular. It is more like how it is on an android phone. They have 15 levels for volume and you have to select one of those levels basically.

7

You misunderstood me. My volume goes to 100% but 100% is with 6%. So basically:
1% is about 16 % real volume
2% is 33%
3% is 50%
4% is 66%
5% is 83%
6% is 100%

I still can go to 7-100%, but it doesn’t change anything as it already is at the maximum (however, I can still go over the 100% to 150% and in 100-150% range I can hear volume increase once more). So it looks for me like you have a similar or exactly the same problem, but results are somewhat different. For me the real volume change happens between 0-6% of system volume, for you at some thresholds.

I know exactly in which update it happened, but going back and freezing the system updates is not a solution. Some critical security issues were patched in that time, and I would not be able to install any app from the repo, if the system is not up-to-date.

I tried to downgrade all sound related packages, but it didn’t help. Restoring backup did help, but as already said, couldn’t wait indefinitely and apply the update once again.

All in all, I can live with this bug and as you have said, the volume control is not as granular as it was before.

8

No no, it is not the same. Your problem is more serious. You basically have 6 levels of volume. I have more (dont know how many but more than 6) and i can increase my volume between 0 to 100 and when i go to 100, it is the max.

Have you tried connecting a different device and test the volume? A cabled earphone for example. Or a different bluetooth headset. If i swap my headset the volume changes become more granular actually. So i assume that at some point, pipewire (or wireplumber) has switched to “absolute volume” just like in android, which allows whatever device is connected, to adjust the volume from within and that change is reflected in the system. In android, absolute volume can be disabled. I have tried the trick in that aforementioned thread i posted but it didn’t change it for me, maybe it can help you. Just try it.

9

I can switch the volume quicker, since I don’t have to go through the empty percents, so I’m not sure if that is more serious. Sure, I have less volume levels and that sucks, but it’s not tragic.

The issue happens only on built-in laptop speakers. For Bluetooth devices it works correctly. Or it seems so. Actually, I haven’t been paying attention to volume progress, so it is possible that it may behave like in your case. I will have to check it.

Despite the differences, there is some mismatch between actual volume level and the system volume setting in both cases.

If I had known what element is to blame, I would already file a bug report.

10

Have you tried this: https://forum.manjaro.org/t/how-to-disable-absolute-volume-with-pipewire-pulse/162105

11

No, I haven’t. It is for bluetooth, which works fine. The volume levels are correct and change as before from 0-100%. The only issue is with default, inbuilt laptop speakers.

Just to list additional info:

pactl list sinks
Sink #53
        State: SUSPENDED
        Name: alsa_output.pci-0000_69_00.6.HiFi__Speaker__sink
        Description: Family 17h/19h/1ah HD Audio Controller Speaker
        Driver: PipeWire
        Sample Specification: s32le 2ch 48000Hz
        Channel Map: front-left,front-right
        Owner Module: 4294967295
        Mute: no
        Volume: front-left: 1966 /   3% / -91,37 dB,   front-right: 1966 /   3% / -91,37 dB
                balance 0,00
        Base Volume: 65536 / 100% / 0,00 dB
        Monitor Source: alsa_output.pci-0000_69_00.6.HiFi__Speaker__sink.monitor
        Latency: 0 usec, configured 0 usec
        Flags: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY 
        Properties:
                alsa.card = "3"
                alsa.card_name = "HD-Audio Generic"
                alsa.class = "generic"
                alsa.components = "HDA:14f120d0,278212c3,00100001"
                alsa.device = "0"
                alsa.driver_name = "snd_hda_intel"
                alsa.id = "CX11970 Analog"
                alsa.long_card_name = "HD-Audio Generic at 0xdc5c0000 irq 126"
                alsa.mixer_device = "_ucm0004.hw:Generic_1"
                alsa.mixer_name = "Conexant CX11970"
                alsa.name = "CX11970 Analog"
                alsa.resolution_bits = "16"
                alsa.subclass = "generic-mix"
                alsa.subdevice = "0"
                alsa.subdevice_name = "subdevice #0"
                alsa.sync.id = "00000000:00000000:00000000:00000000"
                api.alsa.card.longname = "HD-Audio Generic at 0xdc5c0000 irq 126"
                api.alsa.card.name = "HD-Audio Generic"
                api.alsa.open.ucm = "true"
                api.alsa.path = "hw:Generic_1"
                api.alsa.pcm.card = "3"
                api.alsa.pcm.stream = "playback"
                audio.channels = "2"
                audio.position = "FL,FR"
                card.profile.device = "0"
                device.api = "alsa"
                device.class = "sound"
                device.id = "44"
                device.profile.description = "Speaker"
                device.profile.name = "HiFi: Speaker: sink"
                device.routes = "1"
                factory.name = "api.alsa.pcm.sink"
                media.class = "Audio/Sink"
                device.description = "Family 17h/19h/1ah HD Audio Controller"
                node.name = "alsa_output.pci-0000_69_00.6.HiFi__Speaker__sink"
                node.nick = "CX11970 Analog"
                node.pause-on-idle = "false"
                object.path = "alsa:acp:Generic_1:0:playback"
                port.group = "playback"
                priority.driver = "1000"
                priority.session = "1000"
                factory.id = "19"
                clock.quantum-limit = "8192"
                client.id = "41"
                node.driver = "true"
                node.loop.name = "data-loop.0"
                library.name = "audioconvert/libspa-audioconvert"
                object.id = "53"
                object.serial = "53"
                api.acp.auto-port = "false"
                api.acp.auto-profile = "false"
                api.alsa.card = "3"
                api.alsa.use-acp = "true"
                api.dbus.ReserveDevice1 = "Audio3"
                api.dbus.ReserveDevice1.Priority = "-20"
                device.bus = "pci"
                device.bus_path = "pci-0000:69:00.6"
                device.enum.api = "udev"
                device.icon_name = "audio-card-analog-pci"
                device.name = "alsa_card.pci-0000_69_00.6"
                device.nick = "HD-Audio Generic"
                device.plugged.usec = "8486538"
                device.product.id = "0x15e3"
                device.product.name = "Family 17h/19h/1ah HD Audio Controller"
                device.subsystem = "sound"
                sysfs.path = "/devices/pci0000:00/0000:00:08.1/0000:69:00.6/sound/card3"
                device.vendor.id = "0x1022"
                device.vendor.name = "Advanced Micro Devices, Inc. [AMD]"
                device.string = "3"
        Ports:
                [Out] Speaker: Speaker (type: Speaker, priority: 100, availability unknown)
        Active Port: [Out] Speaker
        Formats:
                pcm

What I am curious about is this line:

        Volume: front-left: 1966 /   3% / -91,37 dB,   front-right: 1966 /   3% / -91,37 dB

When I changed volume to 4% it shows:

        Volume: front-left: 2621 /   4% / -83,88 dB,   front-right: 2621 /   4% / -83,88 dB

Why does it shows dB with minus? Is it correct?

After many updates and a lot of time passed, it wasn’t fixed. Since this is an issue only on my end and was triggered by the update, this has to be some weird, unusual hardware interaction. This means, it probably wasn’t reported. However, I don’t know what is happening and why, so I don’t know where to report. It can be on Plasma level (plasma-pa), it may be alsa, pipewire or something else related.

Sound system on Linux is too complex and confusing, so any info about it feels like some disjointed, confusing data, which doesn’t explain anything, because the whole picture is too big and without understanding it. There is no needed context, and the articles never explain or point to it.

12

It is. You should see a value of 0dB at maximum volume. The scale represents attenuation, rather than gain.

1 Like
13

Thanks!

I checked the different volumes and it theory it looks all right:

Volume: front-left: 3277 /   5% / -78,06 dB,   front-right: 3277 /   5% / -78,06 dB
Volume: front-left: 3932 /   6% / -73,31 dB,   front-right: 3932 /   6% / -73,31 dB
Volume: front-left: 4588 /   7% / -69,29 dB,   front-right: 4588 /   7% / -69,29 dB
Volume: front-left: 5243 /   8% / -65,81 dB,   front-right: 5243 /   8% / -65,81 dB
...
Volume: front-left: 32768 /  50% / -18,06 dB,   front-right: 32768 /  50% / -18,06 dB

...
Volume: front-left: 65536 / 100% / 0,00 dB,   front-right: 65536 / 100% / 0,00 dB

However, the biggest and most perceive difference is to 6%, while between 7-100% there is some slight and hardly defined difference, but it’s more a matter of voice sound rather than volume.

Something is still not right and the system is not reacting correctly.

1 Like
14

Those steps indeed look wrong to me. I hope one of our members more knowledgeable about audio stuff can assist? Maybe @nikgnomic if he’s not too tied up already.

I see that each “percentage” is making a 3dB or 4dB step. 3dB is, perceptively, about half or double the volume level. You’d want steps in under one decibel to achieve a decent 0-100 range and this might also need to be logarithmic, so something is indeed stuffed up there.

If I think of anything actually useful to post in the meantime, I will do.

Just to add: I might be getting this completely cockeyed but I think we perceive more volume difference at the lower end, so the scaling seems to be reversed?

1 Like
15

Some users reported a similar issue in the past with PulseAudio levels not scaling correctly. Issue was resolved by re-configuring PulseAudio to ignore decibel scaling (ignore_dB=1)
PulseAudio/Troubleshooting - No sound below a volume cutoff or Clipping on a particular output device - ArchWiki

Wireplumber has a similar option to ignore decibel scaling

Archwiki also suggests using a software volume control

PipeWire - No sound from USB DAC until 30% volume - ArchWiki

Some USB DACs will have no sound output until a certain level of volume is reached Typically this is around 25% - 30% which then leads to an uncomfortably loud initial volume and the inability to maintain a low volume. The solution is to ignore hardware mixer volume control by setting api.alsa.soft-mixer to true.

2 Likes