Bug 205

Sometimes happens that the pulseaudio volume is low.
This can be checked from the pulseaudio volume control (pavu) in the tab output devices
* I remember a laptop (i dont remember the brand) that the sound was low (even in maximum) not only in linux but in windows too.

CC: (none) => dglent

Yeah, as Dimitrios said, check the sound level in pavucontrol.

i couldn't find pavucontrol (is it installed? i donno), but i checked in alsamixer and noted that the "speaker" volume level was only at 19% . is there a way to get this fixed?

because since pulseaudio, these sort of volume levels are hard to find. and i have no trouble with it, but the 2010.0 which was installed before with pulseaudio as well on this exact same laptop, did not have this issue.

i remember all volume levels after install mostly to be between 60% and 75% .

Can you attach "pacmd list" and "amixer -c0" (assuming the problem is with alsa card 0?).

If possible, run both these commands when some music is playing and is quieter than you expect.

Cheers.

CC: (none) => mageia

it appeared that task-pulseaudio wasn't installed pa control apps weren't there.

in the mean time i had installed this, and used alsamixer to upgrade that "speaker" from 19% to 74% .

i'll see if i can give you that output

If you have to adjust the "Speaker" element in alsamixer, then generally speaking you should pick a "Speaker" port/connector in pavucontrol's Output Devices tab (or in KDE's Speaker Setup tab in System Settings).

pacmd list would allow me to tell you more precisely what to do :)

Created attachment 60 [details]
amixer -c0

Created attachment 61 [details]
pacmd list

OK, you already have analog-output-speaker selected (which should be the default anyway). This *should* control the "Speaker" alsa element but probably only after "Master" has been exhausted (e.g. the full range of master is used up and we need more adjustment). Can you confirm this is the case? i.e. run alsamixer -c0 and then reduce the volume in pavucontrol. You should see Master changing and then when it drops to 0 (or the last step before zero depending on quirks), the Speaker element should start going down instead.

If this is the case we have to wonder why Master isn't affecting the volume on this card. But if you could confirm the above first that would be awesome. I can then ask upstream ALSA guys about the Master not affecting volume issue.

Cheers!

ok, i didn't know this was possible, but it's different than you say.

there is a little wheel in front of laptop, which i used.


at 0, both PCM and Master are at 0.
at a tiny movement (1), PCM becomes 100, master stays zero
2 steps further, PCM becomes 97, master stays zero
1 step further, PCM is 97, master is 13
all steps further master increases, but PCM goes from 97 to 100 to 97 to 100.

speaker doesn't move.

Interesting... Strange that PCM jumps to 100 and then back down to 97.

Other than not controlling Speaker (and still using PCM) the behaviour is correct. PA should basically try to set the volume with Master, then if it's still not accurate enough (or it's run out of range), go along ot the next kcontrol, i.e. PCM and make the additional adjustment there.

I'm not sure why the Speaker port in PA would not be controlling the Speaker kcontrol however... I'll have to investigate (sadly I don't have such h/w to test but I should be able to do something)...

if you want me to test something, you can ask, but i'm not sure i'll be having this mageia setup for long.

chances are probably high that it's  a stupid mistake like a typo somewhere...

Our PA packages are very close to upstream so this problem should affect most distros anyway :)

I'll see what I can dig out. I'm wondering if I can perhaps reproduce via some kind of hda-emu thingy (I don't know much about it).

Created attachment 72 [details]
Maarten's alsa-info output

Status: NEW => ASSIGNED
Assignee: bugsquad => mageia

Any news on this bug? Can it be closed?

CC: (none) => m.van.waes

Good question Marja.

I've done a lot of work on various paths relating to sink ports in upstream PA. Certain aspects of it are now handled much better (before if one port could not handle h/w volumes it meant none of them could - this is now much more granular with each port able to do it's own thing).

I suspect the underlying problems could be potentially solved, but it would need a bit of testing to confirm.

@ Thierry:

You changed assignee from Colin to bugsquad even before Colin replied. I'm trying to understand why, but actually I don't. Can you please explain?

@ Colin

Thanks for keeping us informed

@ Thierry

I already know, it happened because you corrected the wrong component

Assignee: bugsquad => mageia

(In reply to comment #16)
> I suspect the underlying problems could be potentially solved, but it would
> need a bit of testing to confirm.

Colin, if you need something for me, you can ask :-)

AL13N, if you have access to a Cauldron install with this hardware, the test would be as follows:

 1. Use pavucontrol and set the "Port" (on the "Output Devices" tab) to "Speaker".
 2. Run "alsamixer -c0" in a terminal and make sure you can view the alsa Speaker kcontrol on screen.
 3. Use pavucontrol to adjust the sink volume. Do you see the alsa Speaker kcontrol move up and down accordingly (they are likely not 1:1 e.g. 50% in pavucontrol will likely not be 50% in alsa but that's expected - the fact they both move is the main thing :D)

not atm, but maybe this could be arranged. i'll look into this test

ping? Or can we close this one as old?

let's close it as old... too much kernel and pa changes in between... we'll see if it's been fixed later on, we can always reopen it...

(In reply to comment #23)
> let's close it as old... too much kernel and pa changes in between... we'll see
> if it's been fixed later on, we can always reopen it...

So closing

Thanks Al13n :)

Status: ASSIGNED => RESOLVED
Resolution: (none) => OLD