[pulseaudio-discuss] ANN: automatic multichannel profile selection for PulseAudio
I have just released pautosurround — a companion for PulseAudio to be used in HTPC and home theater scenarios. The code is here: https://github.com/Rudd-O/pautosurround Many people have been, through fortune or hard work, blessed with the opportunity to have a home cinema. Quite a few of those people run an HTPC with Linux (and PulseAudio) on it. This HTPC tends to be connected — through either HDMI or a multichannel sound card — to an advanced receiver or home theater system, with support for multichannel audio (5.1, 7.1 or more). If you are fortunate enough to find yourself in this scenario, PulseAudio is fantastic for you. Through the PulseAudio volume control, it lets you select whether you want your audio to be stereo, or 5.1, or 7.1. When listening to tunes, you select stereo, and enjoy your home theater's intelligent upmixing of sound. When watching movies, you select 5.1 or 7.1, and the receiver gets the full multichannel signal from your favorite media player. As long as you remember to switch to the appropriate profile, you should be good. But, if you don't, well, things don't sound very well: * If you play stereo music in multichannel mode, the receiver thinks it's getting multichannel sound, and so it can't intelligently upmix or do Dolby Pro Logic. * If you play movies in stereo mode, the receiver doesn't get all the channels — you might miss the center channel, the surround sounds will be faked, and you'll get no subwoofer / LFE signal either. Come to think of it, that's a bit of a bother. Shouldn't the profile be automatic? After all, the media player already knows it's either playing stereo sound or multichannel sound. You already know the computer is connected to a multichannel receiver. Why can't the computer know to select the appropriate output mode? Well, now it can. With pautosurround, the computer autoselects 5.1 when multichannel content is played, and reverts back to its previously-selected profile once it's done. This is something that not even Windows has. -- Rudd-O https://rudd-o.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [pulseaudio-discuss] Force SRC even when sample rates are the same
On 11/10/2021 18.03, Timur Aydin wrote: Hello folks, Is there a way to force pulse audio to use SRC even when the input and output sample rates are the same? Why? -- Rudd-O https://rudd-o.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [pulseaudio-discuss] Start condition failed - ConditionUser=!root not met
Hi. I've made a note on the blog post you cited, saying that `ConditionUser=!root` should not be added. The point of the system service *is* after all to be started by root. On 11/10/2021 21.41, Joel Miller wrote: OS: openSuSE Leap 15.3; KDE plasma desktop To enable a system instance of pulseaudio, I made the following file modifications suggested on the freedesktop.org (https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/SystemWide/) and rudd-o websites (https://rudd-o.com/linux-and-free-software/how-to-make-pulseaudio-run-once-at-boot-for-all-your-users): Per freedesktop.org: set autospawn = no in /etc/pulse/client.conf added "root" and "jm" to pulse-access Per rudd-o: in /etc/systemd/system/pulseaudio.service, modified text for [service] and [Install] (see rudd-o) used systemctl to enable, start, and check the status of pulseaudio The status request yields the following: linux-6:/etc/systemd/system # systemctl --system status pulseaudio.service ● pulseaudio.service - Sound Service Loaded: loaded (/etc/systemd/system/pulseaudio.service; enabled; vendor preset: disabled) Active: inactive (dead) TriggeredBy: ● pulseaudio.socket Condition: start condition failed at Wed 2021-10-06 12:16:38 EDT; 4s ago └─ ConditionUser=!root was not met * * * Your suggestions and advice are welcome. Joel 973 736 8306 -- Rudd-O https://rudd-o.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [pulseaudio-discuss] High CPU Usage in System Mode
On 01/07/2020 18.32, jtharkey wrote:
> In the source I found this in daemon/main.c:
>
> if (conf->system_instance && !conf->disable_shm) {
> pa_log_notice(_("Running in system mode, forcibly disabling
> SHM mode."));
> conf->disable_shm = true;
> }
>
> I commented that out and built it, things seemed to work and work
> faster. Will commenting that out have some side effect I'm not aware of?
>
Yes, SHM mode is not safe when multiple users are using it. SHM will
give you more performance but hostile users may compromise your
PulseAudio daemon.
--
Rudd-O
http://rudd-o.com/
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] allow-passthrough: Change the name of null-sink
On 04/19/2017 02:36 AM, Jungsup Lee wrote:
> Sink's "media.name" property is mostly NULL, therefore
> using sink's name instead of sink's "media.name" property.
> ---
> src/modules/module-allow-passthrough.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/src/modules/module-allow-passthrough.c
> b/src/modules/module-allow-passthrough.c
> index 31ff270..856c6c6 100644
> --- a/src/modules/module-allow-passthrough.c
> +++ b/src/modules/module-allow-passthrough.c
> @@ -59,7 +59,6 @@ static pa_sink *ensure_null_sink_for_sink(struct userdata
> *u, pa_sink *s, pa_cor
> pa_module *m;
> pa_sink *sink;
> uint32_t idx;
> -const char *name;
>
> sink = pa_hashmap_get(u->null_sinks, s);
> if (sink != NULL) {
> @@ -67,10 +66,8 @@ static pa_sink *ensure_null_sink_for_sink(struct userdata
> *u, pa_sink *s, pa_cor
> return sink;
> }
>
> -name = pa_proplist_gets(s->proplist, PA_PROP_MEDIA_NAME);
> -
> t = pa_sprintf_malloc("sink_name=allow_passthrough_null_%s
> sink_properties='device.description=\"%s\"'",
> - name ? name : "", _("Dummy Output"));
> + s->name, _("Dummy Output"));
> m = pa_module_load(c, "module-null-sink", t);
> pa_xfree(t);
>
Nono, please, do not remove this option. Sometimes we have programs
(like mixing boards) that load null sinks and *need* to name them so the
end user knows to distinguish them from actual null sinks that get
loaded by default when there's no output. Do not remove features just
because *you* do not see the use case.
--
Rudd-O
http://rudd-o.com/
signature.asc
Description: OpenPGP digital signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [BUG] MSI PX60 6QE Laptop : headphones jack not detected but more or less working
On 01/10/2017 07:56 PM, GMAIL wrote: > Hi everyone, and Happy New Year to PA developers around the world ! :-) Not to discourage you, but your issue sounds like an ALSA driver deficiency, as the volume regulators are usually managed through ALSA-provided information files. You may want to cross-post to the ALSA mailing list, or test whether the various ALSA volumes (alsamixer -c0) do affect your headphone listening experience. If PA is not controlling the right know in alsamixer (you can run pavucontrol and alsamixer simultaneously to verify this) it's most likely an ALSA information file deficiency. -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] 98766: Bug and bounty to improve HDMI handling in PA
On 09/21/2016 12:55 AM, Manuel Amador (Rudd-O) wrote: > Another concern which just occurred to me. This policy module I am > proposing needs to disable DPMS screen standby/off, but it must NOT > interfere with actual screen saving or locking functions. That is, if > the user runs a screen saver, it should trigger normally, and so should > the locking feature — it is only the display that must never turn off > (or at least while their music / sound app is playing to HDMI devices). > > Otherwise we risk this policy module breaking security policy. Update w.r.t. this: Plasma KDE does not allow this as of now (according to my own tests). I have filed a ticket to get this looked into: https://bugs.kde.org/show_bug.cgi?id=369129 -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] 98766: Bug and bounty to improve HDMI handling in PA
On 09/20/2016 01:36 PM, Felipe Sateler wrote:
> On 19 September 2016 at 15:00, Manuel Amador (Rudd-O)
> wrote:
>
>> I believe that there's a good compromise to be made:
>>
>> 1. if PulseAudio ('s D-Bus session) is tied to a GUI session in X11 or
>> Wayland,
> It appears the world is moving towards per-user daemons from the
> per-session model.
Not quite, as the portals work I'm pretty sure will require some sort of
sub-sessions, but I get the meaning of what you are saying.
It will still probably suffice to ask the current session's D-Bus daemon
if the org.freedesktop.ScreenSaver service is available. That suffices
as a check, and it works both in X11 and Wayland. See my other e-mail
about D-Bus APIs to interact with the screensaver.
> This means this part may not be valid. However, a
> different solution might be to use the logind api[1] to determine if
> there is any graphical session by the current user attached to the
> seat corresponding to the hdmi device (this can be obtained via the
> ID_SEAT udev property, or seat0 as fallback).
Interesting analysis.
Let me try to break it down from a desktop session perspective.
If PulseAudio knows of >0 HDMI audio output devices, you know one of two
things:
1. The screensaver can set the HDMI port to DPMS off / standby. This
is the case when you have an HDMI port that is connected to a
monitor which is configured as part of the overall display surface.
2. The CRTCs of the HDMI port are simply offline, thus no audio will
come out anyway. This is typically the case when you have an HDMI
port that is connected to nothing, or you have an HDMI port that is
connected to a monitor but the monitor is not part of the overall
configured display surface.
It would be a mistake to prevent screen saving if audio was "playing"
(quotes, because no actual sound will come out) to one of the ports
known to be in state (2), but it would be correct to prevent screen
saving if audio was playing to one of the ports in state (1).
I think this describes your concern well.
Under those circumstances, what the module-prevent-hdmi-screensaving
needs to do, is collect and maintain a list of HDMI devices that are
active parts of the display surface (of course, if such a list cannot be
collected, the module will simply do nothing).
You can obtain which devices are part of the display surface (in KDE) by
talking to org.kde.KScreen (path /backend) and subscribing to the D-Bus
signal org.kde.KScreen.Backend.ConfigChanged. I don't understand the
returned data, but I know it mentions the HDMI port number, and that can
be correlated to the HDMI display device that loginctl knows of.
You can also obtain which devices are part of the user session by
talking to loginctl seat-status .
The PROBLEM with this data, is that the user session data does not tell
you which HDMI "sound card" corresponds to which HDMI display device,
which you need to know in order to figure out which HDMI "sound card" is
actually active and connected to a monitor that is part of the display
surface (otherwise the CRTC will be off, and no sound will come out).
So there is literally no way of figuring out a solution to your concern.
It's therefore far easier (if not 100% correct in all cases) to just
assume any playback of audio on any HDMI device means that screen saving
should be blocked. And, for that other 1% of the cases where people are
doing "weird shit" (I know of someone who runs a virtual X server which
owns his HDMI port, just so the port can be active and he can play audio
to his receiver), the setting "do not inhibit screen saver" should suffice.
Another concern which just occurred to me. This policy module I am
proposing needs to disable DPMS screen standby/off, but it must NOT
interfere with actual screen saving or locking functions. That is, if
the user runs a screen saver, it should trigger normally, and so should
the locking feature — it is only the display that must never turn off
(or at least while their music / sound app is playing to HDMI devices).
Otherwise we risk this policy module breaking security policy.
Anyway, anyone interested in collecting the bounty for a minimum viable
thing that I can test?
--
Rudd-O
http://rudd-o.com/
signature.asc
Description: OpenPGP digital signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] 98766: Bug and bounty to improve HDMI handling in PA
On 09/19/2016 06:00 PM, Manuel Amador (Rudd-O) wrote:
> 1. if PulseAudio ('s D-Bus session) is tied to a GUI session in X11 or
> Wayland,
> 4. and there is a spec-compliant screen saver on the same D-Bus session
> bus (GNOME's or KDE's, for example),
> 2. and at least one audio stream is playing to a sink, which has the
> HDMI profile selected (we will call this a "qualifying stream"),
> 5. then it may be plausible to use D-Bus messages to delay screen saving
> until all qualifying streams pause or stop playback.
>
The relevant D-Bus APIs to inhibit and uninhibit screen saving are:
method uint org.freedesktop.ScreenSaver.Inhibit(string application_name,
string reason_for_inhibit)
and uninhibit()
under org.freedesktop.ScreenSaver /ScreenSaver
--
Rudd-O
http://rudd-o.com/
signature.asc
Description: OpenPGP digital signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] 98766: Bug and bounty to improve HDMI handling in PA
From https://bugs.freedesktop.org/token.cgi?t=yKdSDlY31y
PulseAudio should block display DPMS when playing audio on HDMI devices
The HDMI spec makes it so that when audio is playing through an HDMI
output (the sink, set to profile HDMI), audio stops playing. This
causes problems such as music players appearing to "stop playback" (but
silently continuing playback), or YouTube playback (even in fullscreen)
appearing to "shut up", when the desktop environment / X11 window system
tells the display to save power.
There are three workarounds to this problem, both of which are inadequate:
i. Wiggling the mouse to get the display to remain on. This is
exceedingly annoying and shouldn't be required of the user.
ii. Extending the display DPMS (power-saving) timeout. This merely
extends the need to do (i), as well as wasting power when the machine
isn't playing sounds at all.
iii. Simulating user interaction with an external program that detects
when streams play in PulseAudio to HDMI devices. This doesn't require
(i) or (ii), but it does mean that we waste power polling PulseAudio in
a loop within such a program. It may also mean that the computer itself
will fail to execute on other power policy, such as suspend on low battery.
I believe that there's a good compromise to be made:
1. if PulseAudio ('s D-Bus session) is tied to a GUI session in X11 or
Wayland,
4. and there is a spec-compliant screen saver on the same D-Bus session
bus (GNOME's or KDE's, for example),
2. and at least one audio stream is playing to a sink, which has the
HDMI profile selected (we will call this a "qualifying stream"),
5. then it may be plausible to use D-Bus messages to delay screen saving
until all qualifying streams pause or stop playback.
When any of these circumstances are not met, the policy module operates
exactly as a no-op. It's my honest belief that this will improve the
desktop experience for many users of PulseAudio especially high-end
users who connect their HTPCs to their receivers and other equipment as
well as keep the user experience unaltered for anyone else.
This could be implemented as a policy module. As an implementation
detail, prospectively, this could be an enhancement to the
stream-interaction subsystem that already exists in PulseAudio.
Remaining questions to be tackled:
a. Do we need to inform the user that the screen saver is blocked while
sound is playing back? If so, how?
b. Do we provide a mechanism to turn the policy off / on? If so, how?
(In paprefs? / As a module option?)
c. Do we load this proposed policy module by default? In many (if not
most) use cases, it seems that this should in fact be the default.
I really would like to get this issue solved, but my own technical
expertise with C and the PulseAudio internals make it very hard for me
to do the necessary contribution to solve this issue.
Therefore, I volunteer U.S. $500 as a bounty for an initial
proof-of-concept in-tree (to mean, e.g., a Github fork of PulseAudio
that compiles and runs) policy module that would enact this very
behavior as specified above. To engage with me for the bounty, just
contact me at my e-mail address rudd-o+bou...@rudd-o.com. I will then
help you steward the necessary changes to get the module upstreamed and
into PulseAudio.
Thank you in advance for considering this proposal.
--
Rudd-O
http://rudd-o.com/
signature.asc
Description: OpenPGP digital signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
