Launchpad has imported 13 comments from the remote bug at https://bugs.kde.org/show_bug.cgi?id=254793.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2010-10-20T21:10:27+00:00 Murz wrote: Version: 3.7 (using KDE 4.5.2) OS: Linux I have use pulseaudio with Surround 5.1 speakers. And I setup different volume per each channel for normal volume near computer, it looks like this: http://imagebin.ca/img/0wF1MTI.png But when I change volume to 0% and 100% via kmix, and revert volume back to near 50%, kmix broke my volume configuration and do the same volume for each channel! And after this channels volume looks like this: http://launchpadlibrarian.net/56971008/snapshot2.png Via pactl command I see that each pulseaudio sink have per-channel volumes and base volume, for example in my situation it looks like this: --------------------------------- Sink #1 State: RUNNING Name: alsa_output.pci-0000_00_14.2.analog-surround-51 Description: Internal Audio Analog Surround 5.1 Driver: module-alsa-card.c Sample Specification: s16le 6ch 48000Hz Channel Map: front-left,front-right,rear-left,rear-right,front-center,lfe Owner Module: 1 Mute: no Volume: 0: 28% 1: 27% 2: 30% 3: 30% 4: 33% 5: 21% 0: -33.05 dB 1: -34.11 dB 2: -31.36 dB 3: -31.36 dB 4: -29.02 dB 5: -40.33 dB balance -0.02 Base Volume: 63% -12.00 dB Monitor Source: alsa_output.pci-0000_00_14.2.analog-surround-51.monitor Latency: 153185 usec, configured 156000 usec Flags: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY --------------------------------- And kmix changes volume of each channel: Volume: 0: 33% 1: 32% 2: 35% 3: 35% 4: 38% 5: 26% But better is to change base volume of channel, because it didn't break anything! I can do it manually via command pactl set-sink-volume 1 [0-65535] and it works very good. So I think that kmix must switch to base volume changing instead of change volume for each channel in pulseaudio sink! Reproducible: Always OS: Linux (x86_64) release 2.6.35-22-generic Compiler: cc Reply at: https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/4 ------------------------------------------------------------------------ On 2010-10-20T21:16:36+00:00 Murz wrote: Here is screenshot of my kmix window: http://img28.imageshack.us/img28/3052/21717927.png Reply at: https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/5 ------------------------------------------------------------------------ On 2010-10-20T22:44:09+00:00 Ym8-colin-nbv wrote: Please right click on the slider in kmix and choose the "Split Channels" option (this could arguably be better exposed but that is something that is technically separate from the PA backend specifically - ideally I'd also like to label the different channels, but no framework inside kmix for this exists yet either) Reply at: https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/6 ------------------------------------------------------------------------ On 2010-10-21T07:17:59+00:00 Murz wrote: If I do the "Split Channels", I see all 6 channels in Kmix window, but when I change volume via mouse whell on tray icon, I have same problem! All channels goes to same volume after changing to near 0% and near 100%! So, your method didn't solve the problem! Reply at: https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/7 ------------------------------------------------------------------------ On 2010-11-06T10:05:35+00:00 Murz wrote: This is the video that demonstrates the problem visually: http://www.youtube.com/watch?v=zjPbBd2CCzc Reply at: https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/8 ------------------------------------------------------------------------ On 2010-11-08T10:14:35+00:00 Ym8-colin-nbv wrote: Thanks for the video. I'm not really sure what can be done about that however. pavucontrol itself behaves a similar way when using the mouse wheel. The kmix mousewheel slider integration (as with the keys on multimedia keyboards and laptops etc) are designed to give a nice, simple interface to volume adjustment. As soon as you break the "simple" controls (e.g. by controlling left and right channels independently), then that's the price to pay. There are several different modes of operation here that would support a "fix" anyway. Keep the relative balance stored somehow, and "compress" the ratio as it gets to the upper limits and reinstate it when the volume is reduced sufficiently to allow it again is one method. Blocking any further volume increases is another. I could do the latter in kmix itself probably (although I'm not certain of this as the decisions on the could actually be further up the kmix stack - can't remember off hand). The former would really have to be done in PA itself (doing "intelligent" volume handling as the PA client application level has a very nasty habit of creating "feedback loops" - the same thing happened with the initial Gnome volume control applet). But even if the first suggestion above was acceptable, the question of precisely what upper limit is presented also comes into play. At the moment, I only expose the 100% aka 0dB point in Kmix but there are people who want to expose up to ~150% (~+11dB). This is software amplification territory. The principles of how to present this are tricky but it's certainly the case that some users need this kind of extra boost. The way it's handled in gnome is inconsistent (the main application allowing up to 150% and the applet capped at 100% - presenting these concepts to the user is trick to say the least). So I suspect that the first solution is the desired one, but with the added issues of upper bounds capping, the problem does get harder. I'll certainly discuss the problem upstream and see if there is a general consensus on the issues involved. Reply at: https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/10 ------------------------------------------------------------------------ On 2010-11-08T10:48:43+00:00 Murz wrote: I check this issue in gnome and see that issue exists only on 0% volume, when changing volume to 100% it does not break per-channel configuration. Maybe kmix can do something like in gnome? As workaround I can offer the method for 0% volume: We can analyse new per-channel volumes before do the change, and if some of channel will have 0% volume, do the mute instead of decrease volume for each channel and breaking current per-volume config. And about 150-200% we can add option for maximum channel volume in kmix, and do the change between 0 and this value. Reply at: https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/11 ------------------------------------------------------------------------ On 2010-11-08T11:07:08+00:00 Murz wrote: And I do some another checks via pulseaudio console utility pactl: I can change the volume of sink via command $ pactl set-sink-volume 0 10000 # volume is from 0 to 65535. When I changing it to maximum value (65535), it don't break channel balance and set 100% volume only for channel with maximum level. But when I set volume to 0, it breaks balance :( I created the issue about this in pulseaudio tracker: http://pulseaudio.org/ticket/874 So, at now for solve 0% problem I see only the workaround from previous post, but for solve problem on 100% you can change the volume increase method in kmix to like in gnome. Reply at: https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/12 ------------------------------------------------------------------------ On 2010-11-08T11:50:54+00:00 Ym8-colin-nbv wrote: Hmmm, yes, looking again the the gnome stuff, it is handled in a nicer way. It seems to scale the left+right balance better and blocks when one channel hits 100%. For me, when getting to 0 the balance got gradually more "even" and then muted, but scrolling up again seemed to retain the balance originally chosen. I'm not quite sure how this works, but I presume there is some kind of client side balance algorithm involved. I'll try and take a look at the code to see how that works. So ultimately, for me at least, the gnome volume worked pretty much exactly how you suggest. Incidentally the numbers you mentioned for volume are slightly incorrect. The 65535 value corresponds with 0dB aka 100% aka PA_VOLUME_NORM. The maximum volume is technically uint32(-1). Which is substantially larger than the 65k value. The GUIs and tools limit this upper range however, so it's not completely relevant here (there are reasons that it becomes relevant such as the exposure of volumes > 100% as previously mentioned - and this is a problem that is not yet solved on the Gnome side either FWIW). Reply at: https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/13 ------------------------------------------------------------------------ On 2010-11-08T12:10:22+00:00 Murz wrote: Thanks, I looking forward to new release, pleas inform about news :) And one more idea: via pactl command in sinks I see the "Base Volume" value for each sink. Maybe we can change via api this volume to 0% and 100% without breaking per-channel setup? But I can't found the way to change it via pactl to check. Reply at: https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/14 ------------------------------------------------------------------------ On 2010-11-08T12:34:32+00:00 Ym8-colin-nbv wrote: The base volume is really not something that you can change. It's a product of what comes from the hardware. A lot of hardware does not provide this information and thus Base Volume == PA_VOLUME_NORM == 0dB == 100% It is only really relevant for initial volume choices for new users and to display to the user that anything above the base volume can be subject to some degree of clipping/artefacts. For reference, some documents about how to present volume sliders is present here: http://pulseaudio.org/wiki/WritingVolumeControlUIs#Colouredvolumesliders No-one has yet implemented such a coloured scheme (with the exception of VLC which uses a very similar mechanism, in it's native GUI, but with no direct relation to PA and base volumes. It also uses a completely different dB->percentage mapping to that used by PA) Reply at: https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/15 ------------------------------------------------------------------------ On 2010-11-08T12:35:25+00:00 Ym8-colin-nbv wrote: Oh and with regards to keeping informed of the work I do, I suggest you follow either my own blog or Planet KDE as I usually blog about new things via this channel. Reply at: https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/16 ------------------------------------------------------------------------ On 2011-12-30T13:04:04+00:00 Christian Esken wrote: Yes. The topic of volume "balance" is a actually more complicated than one would assume. The issues are (as described in the former comments) how to handle "upper bound" and "lower bound", and also whether to store (internally and for persisting/restoring) absolute or relative (or both) values and possible issues with rounding for controls that do not use the range 0-100. I think something like the "upper bound" handling like in Gnome can be done easily. Reply at: https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/17 ** Bug watch added: PulseAudio sound server #874 http://pulseaudio.org/ticket/874 -- You received this bug notification because you are a member of Kubuntu Bugs, which is subscribed to kdemultimedia in Ubuntu. https://bugs.launchpad.net/bugs/653446 Title: kmix breaks pulseaudio volume per channel setup when changing volume to 100% or 0% To manage notifications about this bug go to: https://bugs.launchpad.net/kdemultimedia/+bug/653446/+subscriptions -- kubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs
