We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1011

Summary: Wrong application name appears in Sound Preferences when using pulseaudio
Product: SDL Reporter: Daniel Ellis <mail>
Component: audioAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: blocker    
Priority: P1 CC: jspradlin, mail, moimael, slouken
Version: HG 2.0Keywords: target-2.0.0
Hardware: Other   
OS: Linux   
Attachments: Patch to not specify an application name when creating a pulse audio context.

Description Daniel Ellis 2010-06-25 15:20:31 UTC 
Created attachment 512 [details]
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.
Comment 1 Maël Lavault 2011-01-15 09:42:12 UTC 
Any progress on this bug ? It would be nice if we could fix this bug in openshot !
Comment 2 Sam Lantinga 2011-01-23 21:51:58 UTC 
Thanks, your change is in the repository!
Comment 3 Sam Lantinga 2011-01-23 21:54:16 UTC 
This is fixed in SDL 1.3.  The code for SDL 1.2 looks very different and might need additional review.
Comment 4 Sam Lantinga 2011-02-16 04:13:50 UTC 
This appears to have caused bug 1119.
Can someone take a look and see what's going on here?

Thanks!
Comment 5 Daniel Ellis 2011-02-16 05:15:43 UTC 
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?
Comment 6 Sam Lantinga 2011-02-24 18:16:40 UTC 
Assigning to Ryan for his audio cleanup.
Comment 7 Sam Lantinga 2013-05-21 01:16:17 UTC 
Ryan, can you take a look and see if this is still active for the 2.0 release?
Comment 8 Ryan C. Gordon 2013-07-12 18:52:43 UTC 
(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.
Comment 9 Ryan C. Gordon 2013-07-30 01:39:42 UTC 
Bug #1119 is fixed now, so I'm resolving this bug, too.

--ryan.