Bug 1218369 - The volume bar has notable steps that don't match the fake granularity it displays at all, and they're too big
Summary: The volume bar has notable steps that don't match the fake granularity it dis...
Status: NEW
Alias: None
Product: openSUSE Distribution
Classification: openSUSE
Component: Sound (show other bugs)
Version: Leap 16.0
Hardware: Other Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Takashi Iwai
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-12-23 05:54 UTC by ell1e
Modified: 2024-01-03 11:30 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
alsa-info.sh output (35.71 KB, text/plain)
2024-01-02 17:12 UTC, ell1e
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ell1e 2023-12-23 05:54:30 UTC
The volume bar has notable steps that don't match the fake granularity it displays at all. This affects both the gnome-shell volume bar and the one in pavucontrol, but for the latter it's an even more obvious mismatch because pavucontrol pretends there's an exact dB value changing with every pixel of the bar when large chunks of the bar audibly map to a fixed volume step.

Even worse howev4er is that these steps are simply too big. I can't actually pick a comfortable volume to listen at because it's between two of the big steps.

GNOME Shell 45.1, pipewire compiled with libpipewire 0.3.85 linked with libpipewire 0.3.85.
Comment 1 Takashi Iwai 2024-01-02 17:03:25 UTC
Hm, I thought PW does the software volume control.  At least for mixing, you can adjust the application-specific volume and this must be in software, i.e. not restricted with the hardware mixer capability.
e.g. with pavucontrol, you can see the application volume in "Playback" tab while playing and adjust as you like -- this should be fine adjustable.

Or even does it show a similar granularity problem?

In anyway, please give alsa-info.sh output for your hardware details.  Run it with --no-upload option and attach the output.
Comment 2 ell1e 2024-01-02 17:11:25 UTC
I can't fully tell for the Applications list on pavucontrol > Playback, but I think it doesn't have that problem, so you may be correct.

pavucontrol > Output Devices > [device specific volume bar] however does have the problem as well.
Comment 3 ell1e 2024-01-02 17:12:00 UTC
Created attachment 871621 [details]
alsa-info.sh output
Comment 4 ell1e 2024-01-02 23:48:20 UTC
I completely forgot to mention, the affected device is the Anker SoundCore Life Q30, so bluetooth is involved too. So I'm guessing something along the chain of pavucontrol, pipewire, and the bluetooth stack maybe isn't quite optimally working. (Is alsa actually somewhere involved in that? Maybe it's not actually that relevant)
Comment 5 Takashi Iwai 2024-01-03 11:30:11 UTC
OK, if it's a BT audio, it's a completely different code flow than USB and other audio devices, and of course it's not shown in alsa-info.sh output.