Bug 6694 - (int-150671) libplayback missing -doc package
(int-150671)
: libplayback missing -doc package
Status: RESOLVED FIXED
Product: Multimedia
gstreamer
: 5.0:(10.2010.19-1)
: All Windows
: Unspecified major with 24 votes (vote)
: 5.0/(20.2010.36-2)
Assigned To: unassigned
: gstreamer-bugs
:
:
:
: 7497 8699 7682
  Show dependency tree
 
Reported: 2009-12-08 00:46 UTC by Thomas Perl
Modified: 2010-10-25 17:12 UTC (History)
15 users (show)

See Also:


Attachments
Playbin2-utilizing app with working sound in silent mode (2.94 KB, text/plain)
2009-12-24 04:17 UTC, Faheem Pervez
Details
Python method of setting properties (2.33 KB, text/x-python)
2010-06-15 20:16 UTC, Faheem Pervez
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Thomas Perl (reporter) 2009-12-08 00:46:38 UTC
SOFTWARE VERSION:
5.0/(1.2009.42-11)

EXACT STEPS LEADING TO PROBLEM: 
1. Switch N900 to "Silent" profile
2. Install gstreamer0.10-tools (for the test below)
3. Open xterm and enter this command:
   gst-launch0.10 playbin2 uri=file:///home/user/MyDocs/somesong.mp3

(Of course, the URI should point to an existing audio file.. ;)

EXPECTED OUTCOME:

Music starts playing even in Silent mode

ACTUAL OUTCOME:

Music does not play.

REPRODUCIBILITY:
always

OTHER COMMENTS:

I need this functionality (playing music even in Silent mode) for a media
player (Panucci). At the moment, users have to switch to the General profile in
order to hear music. The built-in media player is not affected by this
restriction.

Related mailing list post:
http://lists.maemo.org/pipermail/maemo-developers/2009-November/022646.html
Comment 1 Ville Reijonen 2009-12-08 10:44:48 UTC
I have noticed this bug too, or some related bug. Select silent profile and put
the volume up. At least following applications are affected: bounce evolution,
solarwolf, mancala, tuner tool, recorder and panucci. I didn't try all the
applications, just some where I expected sound. As there is already a bunch of
affected programs, and more are coming, I bumped the priority and severity up
:)

As I understand the profile is for communication events (calls, sms, im) and it
should switch the event sounds and vibra. Alarm sound should be always on and
loud. Therefore, the volume adjustment should modify application sound level
(i.e. not "phone"). Due to this bug, the "phone" adjustment affects the
application side too, so if I want to have voiceless phone but play audio it
does not work in some applications. This bug creates confusion - what the
profile is for and what is the volume adjustment for?
Comment 2 Andre Klapper maemo.org 2009-12-14 17:25:19 UTC
Confirming in 2009.50-7 - media player works, but gstreamer does not.
Comment 3 Stefan Kost 2009-12-14 17:56:33 UTC
For short sounds it would be enough to tag the streams going to pulseaudio to
make the policy react on them. For long streams like music playback, background
musics, ... applications should use the libplayback api to classify themself
and also react on the resource policy decissions (see libplayback-1-dev).
Comment 4 Thomas Perl (reporter) 2009-12-15 12:02:39 UTC
(In reply to comment #3)
> For short sounds it would be enough to tag the streams going to pulseaudio to
> make the policy react on them. For long streams like music playback, background
> musics, ... applications should use the libplayback api to classify themself
> and also react on the resource policy decissions (see libplayback-1-dev).
> 

I could not find a link to libplayback's documentation at
http://maemo.org/development/sdks/maemo_5_api_documentation/

Before I create a bug report for that maybe you can point me to the right
direction (link) in case the documentation already exists?
Comment 5 Andra┼ż 'ruskie' Levstik 2009-12-15 13:19:20 UTC
I've had the same experience with mplayer and xmms2 both using pulse and xmms2
even specifying sink.music for the sink.

What does mediaplayer do differently in this case?
Comment 6 Stefan Kost 2009-12-15 16:12:07 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > For short sounds it would be enough to tag the streams going to pulseaudio to
> > make the policy react on them. For long streams like music playback, background
> > musics, ... applications should use the libplayback api to classify themself
> > and also react on the resource policy decissions (see libplayback-1-dev).
> > 
> 
> I could not find a link to libplayback's documentation at
> http://maemo.org/development/sdks/maemo_5_api_documentation/
> 
> Before I create a bug report for that maybe you can point me to the right
> direction (link) in case the documentation already exists?
> 

I've have asked you to install the -dev package. It is a very small library and
you can find out how to use it from that. It does not have any docs
unfortunately (yet). I filed a bug internaly, but that might take a bit (x-mas
is comming).
Comment 7 Thomas Perl (reporter) 2009-12-15 20:35:01 UTC
(In reply to comment #6)
> I've have asked you to install the -dev package. It is a very small library and
> you can find out how to use it from that. It does not have any docs
> unfortunately (yet). I filed a bug internaly, but that might take a bit (x-mas
> is comming).

I have installed libplayback-1-dev and looked at its header files. Basically my
GStreamer playback streams are linked to the "pb_playback_t" in the same
process, right? What if I have multiple streams in a process? (how do I get the
stream name that I can obviously assign to the "pb_playback_t" using
"pb_playback_set_stream"?)

Also, what does a usual "media player" application do (initialization, setting
up callbacks, code of the callbacks, destruction). Example code would be really
nice here, which saves me time (that I don't have) of guessing the functions
and trial-and-error discovery of the meaning and functionality of the library.

Maybe we should transform this bug into a documentation bug for libplayback?

Also, you mentioned in comment #3 that tagging streams is possible (eliminating
the need for libplayback) - how can I do this with the GStreamer API?
Comment 8 Ville Reijonen 2009-12-19 17:06:50 UTC
*** Bug 7121 has been marked as a duplicate of this bug. ***
Comment 9 Martin Grimme 2009-12-21 19:37:40 UTC
adding myself to CC
Comment 10 Faheem Pervez maemo.org 2009-12-24 04:17:17 UTC
Created an attachment (id=1841) [details]
Playbin2-utilizing app with working sound in silent mode

OK, I figured it out.

Compile the attached (gcc gcc_hello.c -o gcc_hello $(pkg-config --cflags --libs
gstreamer-0.10 dbus-glib-1 libplayback-1), move the resultant binary into
/usr/bin, add the following into /usr/share/policy/etc/rx51/pulse/xpolicy.conf:
[stream]
exe   = gst_hello
group = player

Save and reboot. 

Set profile to silent mode and run:
gst_hello file:///home/user/MyDocs/.sounds/"Eazy-E - Real Muthaphuckkin Gs.mp3"
(or whatever).

Obviously, if you use a different class, you set the correct poilcy line in
that text file etc.

thp, "event-id" is the tagging scheme used. Look at libcanberra's patches and
that policy text file for more info.
Comment 11 Stefan Kost 2009-12-24 13:46:47 UTC
(In reply to comment #10)
> Created an attachment (id=1841) [details] [details]
> Playbin2-utilizing app with working sound in silent mode
> 
> OK, I figured it out.
> 
> Compile the attached (gcc gcc_hello.c -o gcc_hello $(pkg-config --cflags --libs
> gstreamer-0.10 dbus-glib-1 libplayback-1), move the resultant binary into
> /usr/bin, add the following into /usr/share/policy/etc/rx51/pulse/xpolicy.conf:
> [stream]
> exe   = gst_hello
> group = player
> 
> Save and reboot. 
> 
> Set profile to silent mode and run:
> gst_hello file:///home/user/MyDocs/.sounds/"Eazy-E - Real Muthaphuckkin Gs.mp3"
> (or whatever).
> 
> Obviously, if you use a different class, you set the correct poilcy line in
> that text file etc.
> 
> thp, "event-id" is the tagging scheme used. Look at libcanberra's patches and
> that policy text file for more info.
> 

That is the problem. This is NOT how to do it (yes it works). There will be a
libplayback doc package that describes it. If you can't wait try to snoop the
dbus traffic for media player.
Comment 12 Faheem Pervez maemo.org 2009-12-24 13:56:14 UTC
Or, perhaps, you could just tell us now instead of just dropping useless hints?
Comment 13 Thomas Perl (reporter) 2009-12-27 02:35:55 UTC
(In reply to comment #11)
> That is the problem. This is NOT how to do it (yes it works). There will be a
> libplayback doc package that describes it. If you can't wait try to snoop the
> dbus traffic for media player.

As Faheem already pointed out, it would be really helpful if you could provide
short instructions on how to do it. I don't really feel like snooping D-Bus
traffic and spending time on this. If not, I guess I'll just use the method
described in comment 10 to get playback working.

Faheem: I suppose I could leave out the libplayback integration and just add a
new entry for my application in /usr/share/policy/etc/rx51/pulse/xpolicy.conf
to get audio in "Silent" mode, or do I really need it? (I'm using Python for my
application, so I would have to use ctypes to load libplayback or ask the
PyMaemo devs for bindings to this underdocumented library - I'd rather just
install the policy and skip the libplayback part, even if it's "The Wrong Way")
Comment 14 Faheem Pervez maemo.org 2009-12-27 11:10:39 UTC
(In reply to comment #13)
> Faheem: I suppose I could leave out the libplayback integration and just add a
> new entry for my application in /usr/share/policy/etc/rx51/pulse/xpolicy.conf
> to get audio in "Silent" mode, or do I really need it?
> 

It seems not. I just built a gst_hello binary that does not use any libplayback
functions, and it still plays fine (I still have the clause in the xpolicy.conf
allowing it).

And, come think of it, what does Media Player do that's any different? *Every*
app that comes with Maemo, that is allowed to play in Silent Mode (Mahjong,
Marbles, etc.), has an entry in xpolicy.conf. The Media Player is not exempt
from this, either; search for mafw-dbus-wrapper. 

Attempting to use libplayback (and the code was taken from a proper source -
hildon-thumbnail) without the lines in xpolicy.conf resulted in blank sound.
Gee, I can't wait to see this "super example" that will come with the
libplayback documentation (in time...).
Comment 15 Martin Grimme 2009-12-27 14:08:07 UTC
I very much dislike the idea of having packages modify essential system files
through scripts at installing. What is needed would be a xpolicy.d directory
for throwing in stuff instead.

Now imagine every app that plays some sound messing around with the policy file
through some obscure sed commands that work on some devices, but fail on
others, possibly bricking the device.
This cannot be an acceptable solution IMHO.
Comment 16 Thomas Perl (reporter) 2009-12-27 14:32:03 UTC
(In reply to comment #15)
> I very much dislike the idea of having packages modify essential system files
> through scripts at installing. What is needed would be a xpolicy.d directory
> for throwing in stuff instead.

Maybe someone can write a tool that we can depend on and call in postinst and
postrm to add and remove the necessary settings. For xpolicy, it seems like we
only need the binary name and the "class", and the tool can work from that.
This tool can then be written to be very stable, take care of maintaining the
xpolicy.conf and (in case the configuration file changes for other versions) do
the necessary "translations". It could also be provided on Maemo 4, but be a
no-op command, so that packaging for both versions is easier.

Something like this command (assuming it's called pulse-xclient-tool):

  pulse-xclient-tool add /usr/bin/panucci music
  pulse-xclient-tool remove /usr/bin/panucci music

Anyone up for the task? (Or does such a utility already exist?)

(Alternatively, just create a utility that will create such a xclient.d
directory and have a "xclient-update" utility that will merge all files from
xclient.d to xclient.conf and have applications install their own file in
xclient.d - the "real" xclient.conf should then be backed up and copyied to
xclient.d on installation of said utility.)
Comment 17 Faheem Pervez maemo.org 2009-12-27 14:44:06 UTC
I used grep and echo in a hacked build of MPlayer...

Although, pycage, in your case you may not need to do anything: PR1.1 has rules
for fmradio, and a rule to use that policy if application.name == "FMRadio"
and, indeed, if I run FMRadio from the console, I see policy-related output. I
can't actually verify if it works, however, due to not being able to find my
earphones.
Comment 18 Martin Grimme 2009-12-27 14:46:20 UTC
What will happen if a SSU wants to update the xpolicy file and finds out that
it has been modified? Will the app manager override the modification, fail to
update that file, or hang because of waiting for some debian-style
user-interaction, which isn't supported by the app manager?
Comment 19 Stefan Kost 2009-12-27 14:53:43 UTC
The policy config file is maemo internal api. I guess an update will overwirte
it. It s also subject to chages. I can only repeat that people maemo will
publish the docs, its just not in my hands to make it happen. Please be
patient.
Comment 20 Marko Nykanen nokia 2009-12-29 15:03:59 UTC
*** Bug 7371 has been marked as a duplicate of this bug. ***
Comment 21 Thomas Perl (reporter) 2009-12-30 18:15:09 UTC
(In reply to comment #20)
> *** Bug 7371 has been marked as a duplicate of this bug. ***

Marko: Is this really a duplicate? I think that even when this bug (6694) is
fixed, the Recorder app has to somehow "tag the stream" correctly, so wouldn't
it be better to mark this bug a dependency of bug 7371? According to comment 3,
this won't be fixed directly in playbin2, but rather we will get documentation
on how to tag our streams correctly so that the policy can act on our streams.
Comment 22 Martin Grimme 2010-01-06 14:11:22 UTC
*** Bug 7702 has been marked as a duplicate of this bug. ***
Comment 23 Martin Grimme 2010-01-26 01:20:22 UTC
OK, I found out that I can make FMRadio work in silent mode when changing the
process name with prctl, due to the FMRadio entry in the policy file.

import dl
libc = dl.open("/lib/libc.so.6")
libc.call("prtcl", 15, "FMRadio\0", 0, 0, 0)

I wonder why nobody from Nokia ever told me about this after the entry has been
silently added to the policy file by Nokia.

Still, prctl is no general solution as FMRadio is the only one whitelisted this
way. But since nobody cares about the process name (not even ps displays it),
panucci could set the same process name. Hackish, but at least it doesn't
require modifying system files. And we need a safe solution for this obvious
design bug.
Comment 24 Thomas Perl (reporter) 2010-01-27 00:32:44 UTC
(In reply to comment #23)
> OK, I found out that I can make FMRadio work in silent mode when changing the
> process name with prctl, due to the FMRadio entry in the policy file.
> 
> import dl
> libc = dl.open("/lib/libc.so.6")
> libc.call("prtcl", 15, "FMRadio\0", 0, 0, 0)
> 
> I wonder why nobody from Nokia ever told me about this after the entry has been
> silently added to the policy file by Nokia.
> 
> Still, prctl is no general solution as FMRadio is the only one whitelisted this
> way. But since nobody cares about the process name (not even ps displays it),
> panucci could set the same process name. Hackish, but at least it doesn't
> require modifying system files. And we need a safe solution for this obvious
> design bug.

Yes, many users report this as an important issue, so I'm probably going to add
this to Panucci. Sad to see we have to rely on such hack-ish mechanisms to get
the expected behavior. Feel free to stop me introducing this Dirty Hack(tm) by
providing the necessary APIs and documentation on how to do it properly (and
provide Python bindings for the necessary libs, please).

That's not to say that the idea of having a proper audio routing/tagging policy
is a bad one - I really like it. But please, please make it accessible to third
party developers. Just whitelisting FMRadio (and not telling its developer
about it :p) is not the solution.

I see there's an internal bug for this already, and I know nobody will tell me
about its status.. but maybe someone with access to it can ping the
corresponding developers to tell them it's still an important issue waiting to
be fixed ;)

Sorry for the rant.
Comment 25 Martin Grimme 2010-01-27 18:48:49 UTC
*** Bug 8570 has been marked as a duplicate of this bug. ***
Comment 26 Alberto Garcia Gonzalez 2010-01-29 14:25:57 UTC
(In reply to comment #23)
> OK, I found out that I can make FMRadio work in silent mode when
> changing the process name with prctl, due to the FMRadio entry in
> the policy file.

> import dl
> libc = dl.open("/lib/libc.so.6")
> libc.call("prtcl", 15, "FMRadio\0", 0, 0, 0)

Hmm... I tried this from C code without success. Do you have to make
this call at any particular point of the program?
Comment 27 Martin Grimme 2010-01-29 14:43:51 UTC
No, I think prctl was not the reason why it was working. It was the name of the
symlink (/usr/bin/FMRadio).

I tried the same with MediaBox to no avail.
But then I created a symlink ~/FMRadio pointing to /usr/bin/MediaBox and it
magically worked without prctl.
The app must be started under the name "FMRadio". Only then it appears to work.
Would be quite a hack to have the Exec line in the D-Bus service file for
MediaBox point to /opt/mediabox/FMRadio instead of symlink /usr/bin/MediaBox to
make it work, but I guess it's the only option for now.
Comment 28 Alberto Garcia Gonzalez 2010-01-29 18:50:54 UTC
(In reply to comment #27)
> Would be quite a hack to have the Exec line in the D-Bus service
> file for MediaBox point to /opt/mediabox/FMRadio instead of symlink
> /usr/bin/MediaBox to make it work, but I guess it's the only option
> for now.

I've just tested it, it doesn't seem to work.
Comment 29 Alberto Garcia Gonzalez 2010-01-29 19:23:32 UTC
(In reply to comment #27)
> Would be quite a hack to have the Exec line in the D-Bus service
> file for MediaBox point to /opt/mediabox/FMRadio instead of symlink
> /usr/bin/MediaBox to make it work, but I guess it's the only option
> for now.

Ah, it's much easier:

g_set_application_name("FMRadio");

That's it. No other file has to be changed or renamed. I haven't
noticed any other strange effect.
Comment 30 Martin Grimme 2010-01-30 20:52:05 UTC
This works with Python, too:

import gobject
gobject.set_application_name("FMRadio")
Comment 31 Alberto Garcia Gonzalez 2010-01-31 17:13:30 UTC
(In reply to comment #29)
> g_set_application_name("FMRadio");
>
> That's it. No other file has to be changed or renamed. I haven't
> noticed any other strange effect.

Well, there is. Some libraries fall back to g_get_application_name()
when the application name is not specified using their API.

Example: GtkAboutDialog

We should also check what happens if there are two apps running with
the same name.
Comment 32 Martin Grimme 2010-01-31 19:43:55 UTC
The two apps with the same name issue appears to be harmless.
I tried this.
Comment 33 Faheem Pervez maemo.org 2010-04-17 19:47:09 UTC
An alternate way that doesn't require the policy file to be modified is this:

pa_proplist *proplist = pa_proplist_new (); 
pa_proplist_sets (proplist, PA_PROP_EVENT_ID, "ringtone-preview");
//pa_proplist_sets (proplist, "module-stream-restore.id",
"x-maemo-applet-profiles");
GstElement *sound_player, *pulsesink;
playbin2 = gst_element_factory_make("playbin2", NULL);
pulsesink = gst_element_factory_make ("pulsesink", NULL);
g_object_set (G_OBJECT (pulsesink), "proplist", proplist, NULL); 
pa_proplist_free (proplist); 
g_object_set(sound_player, "audio-sink", pulsesink, NULL);

According to the policy configuration, setting the event.id to
"ringtone-preview" will add your program to the player group.
Comment 34 Andre Klapper maemo.org 2010-04-19 15:06:24 UTC
So, the original issue here is INVALID according to internal comments.
What is valid is that libplayback is missing a -doc package that explains the
situation. :)
Comment 35 Faheem Pervez maemo.org 2010-06-15 20:16:26 UTC
Created an attachment (id=2886) [details]
Python method of setting properties

I've given up all hope on seeing this doc package. Luckily, thanks to all the
contributors here, we've got three ways of working around this.

Here's a Python application doing what I suggest in #33: Setting the
pulsesink's event.id to "ringtone-preview". This way, your program gets added
to the player group automatically without having to modify xpolicy.conf. For
people using C, please look at #33.

I recommend people either modify xpolicy.conf or use the ringtone-preview hack
as this will add your program to the "player" group instead of the "radio"
group. The player group has less restrictions placed on it.

In headset-control, I am modifiying xpolicy.conf but I've added a Debian
trigger so that if xpolicy.conf is replaced, the trigger will automatically
whitelist headset-control again.
Comment 36 Andre Klapper maemo.org 2010-07-08 14:07:13 UTC
This has been fixed in package
libplayback 0.5-22+0m5
which is part of the internal build version
2010.26-8
(Note: 2010 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Comment 37 Thomas Perl (reporter) 2010-07-16 23:27:14 UTC
*** Bug 10548 has been marked as a duplicate of this bug. ***
Comment 38 Andre Klapper maemo.org 2010-10-25 17:12:06 UTC
The problem reported here should be fixed in the update that was released today
for public: The Maemo5 update version 20.2010.36-2 (also called "PR1.3"
sometimes). Please leave a comment if the problem is not fixed for you in this
update version.