Wrong application name appears in Sound Preferences when using pulseaudio

Bug #597859 reported by Daniel Ellis
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libsdl
Fix Released
Critical
libsdl1.2 (Ubuntu)
Triaged
Low
Unassigned

Bug Description

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.

Revision history for this message
Daniel Ellis (danellisuk) wrote :
tags: added: patch
Revision history for this message
In , Daniel Ellis (danellisuk) 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.

Adam Guthrie (therigu)
tags: added: patch-forwarded-upstream
Revision history for this message
In , Moimael-3 (moimael-3) wrote :

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

Revision history for this message
In , Sam Lantinga (slouken) wrote :

Thanks, your change is in the repository!

Revision history for this message
In , Sam Lantinga (slouken) wrote :

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

Revision history for this message
In , Sam Lantinga (slouken) wrote :

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

Thanks!

Revision history for this message
In , Daniel Ellis (danellisuk) 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?

Revision history for this message
In , Sam Lantinga (slouken) wrote :

Assigning to Ryan for his audio cleanup.

Daniel T Chen (crimsun)
Changed in libsdl1.2 (Ubuntu):
status: New → Triaged
importance: Undecided → Low
Changed in libsdl:
importance: Unknown → Medium
status: Unknown → In Progress
Revision history for this message
In , Sam Lantinga (slouken) wrote :

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

Changed in libsdl:
importance: Medium → Critical
Revision history for this message
In , Ryan C. Gordon (icculus) 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.

Revision history for this message
In , Ryan C. Gordon (icculus) wrote :

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

--ryan.

Changed in libsdl:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.