Re: [pulseaudio-discuss] Mic Boost on AC97 audio causes bad behavior of mic volume control
> > > http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Clients/WritingVolumeControlUIs/ > > As I already wrote, the way it is today, if I set 100%/0dB either with > the GNOME volume control, "alsamixer -D pulse", or "pactl > set-source-volume 2 100%", the result is 30dB Capture + 24dB Boost, > which is *not* maximum level. So the user is currently not correctly > informed about the "real 0dB", even if you factor in the boost. http://freedesktop.org/software/pulseaudio/doxygen/volume.html pulseaudio documentation/wiki on volume only mention sink > > > However, for line in, the jumpy behavior of the current input control > would be even worse than for the Mic. My guess would be that for line > in, Boost had better be set to 0dB all the time, and "real 0dB" would be > "30dB Capture + 0dB Boost". You just gave another argument for not > merging "Mic Boost" into the overall volume. How did you add Line in support ? 1) use hint add_jack_modes = 1 2) retask mic in jack to line in jack by early patching https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/Documentation/sound/alsa/HD-Audio.txt - add_jack_modes (bool): add "xxx Jack Mode" enum controls to each I/O jack for allowing to change the headphone amp and mic bias VREF capabilities - line_in_auto_switch (bool): enable/disable the line-in auto-switch feature; default false For line in recording, user expect pavucontrol provide a point at the volume slider which set Capture Volume and Line Boost at 0dB and no pulseaudio software volume similar to spdif passthrough to prevent clipping occur https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/log/sound/pci/hda?qt=grep&q=mic+boost HDA driver have quirks about limiting the internal mic boost, The base volume of pulseaudio source is not constant any more https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=3e0d611b2045b230c3acfb05c3b5ce53b09f6cdd ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Mic Boost on AC97 audio causes bad behavior of mic volume control
> I did observe something by ear, but it's a long story. Since you asked > for it, the full story is related to > http://lists.nongnu.org/archive/html/qemu-devel/2015-04/msg02271.html, > and goes like this: > > I (have to) run Microsoft Lync for telephone conferencing in a Windows > guest on Qemu/KVM under Linux. I use Qemu's spice audio protocol to link > my sound sources/sinks to the Windows guest. The Windows guest sees an > emulated Intel HD Audio codec (ICH6 or ICH9) that has a 74dB volume > scale for capture. For unknown reasons, Windows uses only the upper > ~30dB. Therfore setting the Windows volume slider to 1% lets the "HW" > volume in the emulated HD audio chip jump ~40% immediately. See the > above qemu-devel post for details. > > The libvirt spice server communicates this percentage to PA. PA is > using the "48dB Capture + 36dB Boost" = 84dB volume scale. Setting this > to 40% results in Capture=+30dB (maximum) and Boost=+12dB. Again, this > happens if I set just 1% volume under Windows, about the lowest possible > setting! > are you using pulseaudio as backend ? http://git.qemu.org/?p=qemu.git;a=commitdiff;h=6e7a7f3d9bc2031b4c93c05400b18775ba1b1f55;hp=a394aed235d6b3f048eeae83289f4d21eca7023c qemu seem using stream volume control pa_context_set_source_volume_by_index() instead of source volume control ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] Add a .travis.yml for Travis CI
Installs all the build dependencies, and runs make check and check-daemon. V1: Based on Arun Raghavan's travis file. Added trusty repositories to get newer libs. V2: Explicitly list all dependencies instead of relying on the Ubuntu package Build-Dependencies. Send notifications to pulseaudio-discuss V3: Install libsystemd-daemon-dev, libsystemd-id128-dev, libsystemd-journal-dev, and libsystemd-login-dev. Send notifications to pulseaudio-commits. Drop libjson0-dev, libjson-c-dev is the package to depend on. --- The change to p-commits means that the travis bot should be whitelisted. The mail is bui...@travis-ci.org .travis.yml | 64 + 1 file changed, 64 insertions(+) create mode 100644 .travis.yml diff --git a/.travis.yml b/.travis.yml new file mode 100644 index 000..0bf77d5 --- /dev/null +++ b/.travis.yml @@ -0,0 +1,64 @@ +language: c + +compiler: + - gcc + #- clang + +before_install: + - sudo sh -c 'echo "deb http://archive.ubuntu.com/ubuntu/ trusty main universe\ndeb-src http://archive.ubuntu.com/ubuntu/ trusty main universe" >> /etc/apt/sources.list' + - sudo apt-get -qq update +install: + - > +sudo apt-get -qq install +git-core +autopoint +autoconf +automake +intltool +check +libasound2-dev +libasyncns-dev +libatomic-ops-dev +libavahi-client-dev +libbluetooth-dev +libsbc-dev +libcap-dev +libfftw3-dev +libgconf2-dev +libglib2.0-dev +libgtk-3-dev +libice-dev +libjack-dev +libjson-c-dev +liblircclient-dev +libltdl-dev +liborc-0.4-dev +libsamplerate0-dev +libsndfile1-dev +libspeexdsp-dev +libssl-dev +libtdb-dev +libudev-dev +libwebrtc-audio-processing-dev +libwrap0-dev +libx11-xcb-dev +libxcb1-dev +libxtst-dev +libsystemd-daemon-dev +libsystemd-id128-dev +libsystemd-journal-dev +libsystemd-login-dev + +before_script: + # can't run git-version-gen on a shallow clone or without tags + - if [[ -a .git/shallow ]]; then git fetch --unshallow; fi + - git fetch --tags + - NOCONFIGURE=1 ./bootstrap.sh + +script: + - ./configure --localstatedir=/var && make && make check && make check-daemon + +notifications: + email: +recipients: + - pulseaudio-comm...@lists.freedesktop.org -- 2.1.4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Mic Boost on AC97 audio causes bad behavior of mic volume control
On Mi, 2015-04-29 at 19:17 +0300, Tanu Kaskinen wrote: > > The graphical volume controls don't reflect this; thus user control > > input volume is almost impossible at higher levels than 25%. Volume will > > appear to change non-predictably to users. > > PulseAudio compensates coarse hardware volume by applying software > volume when necessary. This means that users get a smooth volume curve. > For example, you presented a nice table of different volume levels, and > there was this line: > > PA(%) PA(dB) Captu Boost Capture+Boost-66dB > 56% -15.00 30.00 12.00 -24.00 > > The ideal situation would be where the second and the last column would > be equal, but in this case there's a 9dB difference. But no worries, > PulseAudio compensates that by amplifying the signal by 9dB in software. OK, I didn't know that. Thank you. I still think that Pulseaudio should rather apply the hardware volume control in "coarse first, fine later" order, eliminating the need for software volume compensation (which would infer distortion unless I am mistaken). > Did you observe some volume problems by ear, or did you only notice > "weird behaviour" by looking at the alsa mixer? I did observe something by ear, but it's a long story. Since you asked for it, the full story is related to http://lists.nongnu.org/archive/html/qemu-devel/2015-04/msg02271.html, and goes like this: I (have to) run Microsoft Lync for telephone conferencing in a Windows guest on Qemu/KVM under Linux. I use Qemu's spice audio protocol to link my sound sources/sinks to the Windows guest. The Windows guest sees an emulated Intel HD Audio codec (ICH6 or ICH9) that has a 74dB volume scale for capture. For unknown reasons, Windows uses only the upper ~30dB. Therfore setting the Windows volume slider to 1% lets the "HW" volume in the emulated HD audio chip jump ~40% immediately. See the above qemu-devel post for details. The libvirt spice server communicates this percentage to PA. PA is using the "48dB Capture + 36dB Boost" = 84dB volume scale. Setting this to 40% results in Capture=+30dB (maximum) and Boost=+12dB. Again, this happens if I set just 1% volume under Windows, about the lowest possible setting! Microsoft Lync, in turn, has the unpleasant habit to try and regulate input volume automatically. This fails utterly because a minimal change in the windows guest causes the HW volume to jump back and forth. The end result was that my phone peers complained about miserable sound quality (noise) on my part. Basically I had to stay mute. This problem is caused by a combination of various things: 1) the weird behavior of the windows volume control, and the fact that Lync's auto-volume-adjustment can't be switched off 2) the unrealistically large volume scale of the emulated "Capture" device in QEMU 3) the fact QEMU doesn't have a "dB" volume scale, rather all controls work in arbitrary "percentage" units 4) the merging of "Capture" and "Boost" by PA, blowing up the volume scale from 48dB to 84dB. By now, I have combined various measures in order to work around this problem: - for 4): Using a fixed value for "Mic Boost" in PA makes the overall volume scale of the input control smaller, mitigating the problem - for 4): Switching off PA's "flat volumes" avoids Lync->Windows guest->QEMU->spice->PA cranking up the hardware volume control of the host - for 2): I applied a QEMU patch (see thread above) to present a smaller, more realistic Capture amplifier to the guest, but that patch has been rejected by the QEMU folks so far because it's a guest-visible change. This yields a big improvement. I can't do anything about 1), and fixing 3) would be project too large for me at the moment. While I was pulling my hair trying to understand what happened in this complex scenario, I found the volume control strangeness that I have tried to report here. If only that was fixed by reverting commit e6051cdf, the volume control would at least behave more "smoothly". It wouldn't suffice to fix my problem though. Martin ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Problem with remapping sinks to separate outputs
Hi everyone I've been stumped on that for a few months now and can't figure it out anymore. What I am trying to do is separate front left/right, center left/right and back left/right into separate stereo channels. Oddly, this used to work until I reinstalled Kubuntu a few months ago (failed HD). Now it fails in a strange way. I have and use three outputs: ALC889 built-in sound chip, using the analog 7.1 outputs HDMI via nVidia GPU (HDMI outputs not always connected) Bluetooth Headset on-demand (i.e. not always connected) I've added these lines to the end of /etc/pulse/default.pa, everything else is completely default: # Split outputs and add echo cancellation service load-module module-remap-sink sink_name=earphones sink_properties=device.description="Earphones" remix=no master=alsa_output.pci-_00_14.2.analog-surround-71 channels=2 master_channel_map=side-left,side-right channel_map=front-left,front-right load-module module-remap-sink sink_name=headset sink_properties=device.description="Headset" remix=no master=alsa_output.pci-_00_14.2.analog-surround-71 channels=2 master_channel_map=rear-left,rear-right channel_map=front-left,front-right load-module module-remap-sink sink_name=speakers sink_properties=device.description="Speakers" remix=no master=alsa_output.pci-_00_14.2.analog-surround-71 channels=2 master_channel_map=front-left,front-right channel_map=front-left,front-right load-module module-echo-cancel And that's where it gets odd. The "earphones" and "speakers" sinks work. The "headset" sink does not, it's silent even though it does show up as output in both pacmd list-sinks and in the KDE mixer. The weird thing: If i go directly to the soundcard sink, I can play sounds on all channels - separately or simultaneously. And of course, this worked before, why doesn't it work now? What am I missing? Jenni Knoell Network Administrator Surefoot Main Office [1] 1500 Kearns Blvd., Suite A-50 Park City, UT 84060 P: (435) 655 8110 x109 F: (435) 649 0663 _Visit us:_ [2] [3] [4] [5] [6] [7] [8] Links: -- [1] http://maps.google.com/?q=1500%20Kearns%20Blvd,%20Park%20City,%20UT%2084060 [2] http://www.surefoot.com [3] http://www.skiboots.com [4] https://www.facebook.com/customskiboots [5] https://twitter.com/#!/surefootskiing [6] http://www.linkedin.com/company/626481?trk=tyah [7] https://plus.google.com/109265101162931134389/posts [8] http://www.youtube.com/surefootskiing ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Mic Boost on AC97 audio causes bad behavior of mic volume control
On Mon, 2015-04-20 at 16:56 +0200, Wilck, Martin wrote: > Hello, > > there has been some discussion about Mic Boost / Dock Mic Boost in the > past already. Some have reported no Mic output at all without Boost, > other say that enabling Boost will cause high noise on their systems. > > I have another point here that AFAICS hasn't been reported yet. > > It has been caused by the commit e6051cdf "alsa-mixer: Prefer moving > "Capture" before moving boosts" > (http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=e6051cdf8db554c0bbd4257959c37a7ecc9c10c5) > (see also > https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1085402). > > In short, on my system, input volume control is hardly possible above > 25% because of this patch. > > The effect that I am seeing is as follows: I have two merged volume > controls for my Mic, "Capture" and "Dock Mic Boost". They are applied by > PA in the order encountered in the path conf file. On my system (Fujitsu > Lifebook E744 with Realtek ALC282 Codec), the "Capture" Amp has a range > of -18..30 dB in 0.75 dB steps, and "Dock Mic Boost" has 4 12dB steps > (0, 12, 24, 36). PA merges these two controls to a single volume control > with an overall range of -18..66dB. Normalizing at the max, PA converts > this to -84..0dB, where the Boost comes in at -36dB, or 25% of the > scale. The "base volume", calculated from the "offset" of the ALSA amp, > is at -66dB or 8%. > > Because of the above patch, the "Capture" control is used first. Thus > the range from -84...-36 dB (or 0..25%, because of the non-linearity of > PA's volume control) is covered with "Capture". Above that level, > "Capture" is always held at 100% and only "Doc Mic Boost" changes. This > means that above 25%, there are only 3 steps that are actually possible: > -24dB / 40%, -12dB / 63%, and 0dB / 100%. > => There is no "smooth" volume control above 25%. > The graphical volume controls don't reflect this; thus user control > input volume is almost impossible at higher levels than 25%. Volume will > appear to change non-predictably to users. PulseAudio compensates coarse hardware volume by applying software volume when necessary. This means that users get a smooth volume curve. For example, you presented a nice table of different volume levels, and there was this line: PA(%) PA(dB) Captu Boost Capture+Boost-66dB 56% -15.00 30.00 12.00 -24.00 The ideal situation would be where the second and the last column would be equal, but in this case there's a 9dB difference. But no worries, PulseAudio compensates that by amplifying the signal by 9dB in software. Did you observe some volume problems by ear, or did you only notice "weird behaviour" by looking at the alsa mixer? -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Patch review status wiki page updated
Patch review status updated: http://www.freedesktop.org/wiki/Software/PulseAudio/PatchStatus/ Statistics: * 2015-04-29 * 73 patches are pending review. * The oldest pending patch is 283 days old. * 2015-04-21 * 71 patches are pending review. * The oldest pending patch is 275 days old. * 2015-04-13 * 74 patches are pending review. * The oldest pending patch is 267 days old. * 2015-04-01 * 80 patches are pending review. * The oldest pending patch is 255 days old. * 2015-03-24 * 70 patches are pending review. * The oldest pending patch is 247 days old. * 2015-03-16 * 45 patches are pending review. * The oldest pending patch is 239 days old. * 2015-02-23 * 25 patches are pending review. * The oldest pending patch is 218 days old. * 2015-02-02 * 22 patches are pending review * The oldest pending patch is 197 days old. * 2015-01-28 * 22 patches are pending review. * The oldest pending patch is 192 days old. * 2015-01-19 * 26 patches are pending review. * The oldest pending patch is 183 days old. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v3 3/6] core-util: Make pa_parse_volume() more strict
On Tue, 2015-04-28 at 09:32 +0200, David Henningsson wrote: > > On 2015-04-27 13:34, Tanu Kaskinen wrote: > > Previously pa_parse_volume() clamped the value to fit in the valid > > range, but I think it's better to reject values outside the valid > > range. > > It looks like pa_parse_volume is only used from module-role-ducking (via > pa_modargs_get_value_volume) so I guess this should be okay without much > regression risk. > > Acked. Thanks, pushed. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
