Wrong application name appears in Sound Preferences when using pulseaudio

[SDLBugzilla]

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch to not specify an application name when creating a pulse audio context. (dont-specify-appname.patch, text/plain, 2010-06-25 15:20:31 +0000, 1210 bytes)

Reported in version: HG 2.0
Reported for operating system, platform: Linux, Other

Comments on the original bug report:

On 2010-06-25 15:20:31 +0000, Daniel Ellis wrote:

Created attachment 512
Patch to not specify an application name when creating a pulse audio context.

I created the following bug on launchpad and thought I should raise it upstream. https://bugs.launchpad.net/ubuntu/+source/libsdl1.2/+bug/597859

---

SDL based applications sometimes display the wrong application name in the Sound Preferences dialog when using pulseaudio.

I can see from the code that the SDL pulse module is initiating a new pulse audio context and passing an application name using the function get_progname().

The get_progname() function returns the name of the current process. However, the process name is often not a suitable name to use. For example, the OpenShot video editor is a python application, and so "python" is displayed in the Sound Preferences window (see Bug # 596504), when it should be displaying "OpenShot".

PulseAudio allows applications to specify the application name, either at the time the context is created (as SDL does currently), or by special environment variables (see http://www.pulseaudio.org/wiki/ApplicationProperties). If no name is specified, then pulseaudio will determine the name based on the process.

If you specify the application name when initiating the pulseaudio context, then that will override any application name specified using an environment variable.

As libsdl is a library, I believe the solution is for libsdl to not specify any application name when initiating a pulseaudio context, which will enable applications to specify the application name using environment variables. In the case that the applications do not specify anything, pulseaudio will fall back to using the process name anyway.

The attached patch removes the get_progname() function and passes NULL as the application name when creating the pulseaudio context, which fixes the issue.

On 2011-01-15 09:42:12 +0000, Maël Lavault wrote:

Any progress on this bug ? It would be nice if we could fix this bug in openshot !

On 2011-01-23 21:51:58 +0000, Sam Lantinga wrote:

Thanks, your change is in the repository!

On 2011-01-23 21:54:16 +0000, Sam Lantinga wrote:

This is fixed in SDL 1.3. The code for SDL 1.2 looks very different and might need additional review.

On 2011-02-16 04:13:50 +0000, Sam Lantinga wrote:

This appears to have caused bug 1119.
Can someone take a look and see what's going on here?

Thanks!

On 2011-02-16 05:15:43 +0000, Daniel Ellis wrote:

I suspect allowing NULL as a parameter to pa_context_new was introduced in a newer version at some point.

So what we need to find out in order to handle old and new versions of PulseAudio is:-

1. Can we determine the version of PulseAudio at runtime?

2. Which version of PulseAudio introduced the ability to pass NULL as the application name?

From the looks of SDL_pulseaudio.c it is already checking the PulseAudio version using:

#if (PA_API_VERSION < 12)

The doxygen for PulseAudio does not help much:-

http://0pointer.de/lennart/projects/pulseaudio/doxygen/context_8h.html#a2784c754947a97f02c78b73d7b1c2d5f

Does anyone know? Or do we have to go through the PulseAudio source history?

On 2011-02-24 18:16:40 +0000, Sam Lantinga wrote:

Assigning to Ryan for his audio cleanup.

On 2013-05-21 01:16:17 +0000, Sam Lantinga wrote:

Ryan, can you take a look and see if this is still active for the 2.0 release?

On 2013-07-12 18:52:43 +0000, Ryan C. Gordon wrote:

(Sorry if you get a lot of copies of this email, we're touching dozens of bug reports right now.)

Tagging a bunch of bugs as target-2.0.0, Priority 1.

This means we're in the final stretch for an official SDL 2.0.0 release! These are the bugs we really want to fix before shipping if humanly possible.

That being said, we don't promise to fix them because of this tag, we just want to make sure we don't forget to deal with them before we bless a final 2.0.0 release, and generally be organized about what we're aiming to ship.

Hopefully you'll hear more about this bug soon. If you have more information (including "this got fixed at some point, nevermind"), we would love to have you come add more information to the bug report when you have a moment.

Thanks!
--ryan.

On 2013-07-30 01:39:42 +0000, Ryan C. Gordon wrote:

Bug # 1119 is fixed now, so I'm resolving this bug, too.

--ryan.