maemo.org - Talk - [application] pyRadio (Pandora)

maemo.org - Talk (https://talk.maemo.org/index.php)

- Multimedia (https://talk.maemo.org/forumdisplay.php?f=32)

- - [application] pyRadio (Pandora) (https://talk.maemo.org/showthread.php?t=56036)

Re: [application] pyRadio (Pandora)

Quote:

Originally Posted by fatalsaint (Post 716235)

Basically, if anyone can tell me how to do this:

Code:

pa_proplist *proplist = pa_proplist_new (); 

pa_proplist_sets (proplist, PA_PROP_EVENT_ID, "ringtone-preview");

In python.. I would appreciate it.

Heh, it's me that wrote #33...

PulseAudio doesn't seem to have Python bindings but http://gnome-pulse-applet.googlecode...inloop_glib.py seems to wrap it. I'll try it out.

Re: [application] pyRadio (Pandora)

This workaround works.

Setting the application name to FMRadio. I really don't like how ugly this is to work around this problem.

Is there a "proper" way to do this? I still would like any information on setting the pulseaudio proplist like above.. it seems a better solution than "mimicking" another application that has a proper police.

Is the "proper" way to modify the xpolicy file and create my own block for my own app?

Meh. Ugly.

But, my phone is currently playing Pandora while in Silent Mode. I'm not home, or I'd build a package and submit it.. I'll have something up tonight though.

Re: [application] pyRadio (Pandora)

Quote:

Originally Posted by qwerty12 (Post 716238)

Heh, it's me that wrote #33...

PulseAudio doesn't seem to have Python bindings but http://gnome-pulse-applet.googlecode...inloop_glib.py seems to wrap it. I'll try it out.

Yeah I tried merging that into my app... wasn't working right. I didn't want to have to download and include two additional modules (PulseGlib and lib_pulseaudio) just for this one workaround.

If I could figure out just exactly the necessary CDLL calls to create and edit the proplist..specifically, working with these areas:

Code:

pa_context_new_with_proplist = pulse_lib.pa_context_new_with_proplist

pa_context_new_with_proplist.restype = POINTER(PA_CONTEXT)

pa_context_new_with_proplist.argtypes = [

        POINTER(PA_MAINLOOP_API),

        c_char_p,

        POINTER(PA_PROPLIST)

]



#

# pa_proplist_*

pa_proplist_new = pulse_lib.pa_proplist_new

pa_proplist_new.restype = POINTER(PA_PROPLIST)

pa_proplist_new.argtypes = [ ]



pa_proplist_sets = pulse_lib.pa_proplist_sets

pa_proplist_sets.restype = c_int

pa_proplist_sets.argtypes = [

        POINTER(PA_PROPLIST),

        c_char_p,

        c_char_p

]

Re: [application] pyRadio (Pandora)

Of course.. then the question becomes:

Is pretending my app is a ringtone-preview any better than just pretending my app is FMRadio? :rolleyes:

Re: [application] pyRadio (Pandora)

Quote:

Originally Posted by fatalsaint (Post 716254)

I don't really like that workaround because the policy system will group your app into the radio category, which has less privileges than one in the "player" category. If you want to edit xpolicy.conf, check out my headset-control package which'll add the information to whitelist headset-control (I do some libplayback stuff in it) and adds a trigger so that if xpolicy.conf is replaced by another package, headset-control's postinst will add it back in. (I happened to test that when dist-upgrading from leaked PR 1.2 to "proper" PR 1.2.)

Re: [application] pyRadio (Pandora)

Quote:

Originally Posted by qwerty12 (Post 716266)

Yeah but working through the CDLL lib's requires creating several class structures, building several variables, to create the proplist, editing the proplist and then setting it in the pulsesink gst audio-sink.

It's a mess. The alternative is I download 2 additional .py's, distribute them with my package, and import them in my radio app.

This is an awful low of work just to get around a stupid "Silent" profile policy.

I mean.. I do have to agree that I find it a bit silly that people expect sound to play when the phone is on "Silent"... to me "Silent" means just that.. Silence. I find it odd that even the built-in player gets around the Silent profile.

But I've seen this crop up in several threads .. and has been mentioned to me often so figured WTH.. since you and Flandry found me work arounds I'll go ahead and implement them. Especially since, this appears to be the only way we can avoid having the problem of pyRadio being unlistenable if you're constantly texting someone because the system sounds override gstreamer (instead of just playing over background audio it actually takes control, stops your playing, and plays the system sound. Ridiculous again. If Linux was still stuck in the days of only playing one-sound at a time we'd have gotten no where..) Now we can just set the phone to the Not-Really-But-Badly-Named-And-Incorrect "Silent" profile.

Oh well.. I guess I'm just venting some frustration here.

Specifically tho: Being in the radio category, what privileges exactly am I missing? Cause I'll be honest.. adding 1 line and no additional includes to work around the simple Silent problem is a lot more appealing to me than bringing along two full modules that envelope the entire pulseaudio wrappings; and/or writing my own small piece of code to work just with proplists. The work or bulk outweigh the benefits I'm thinking.

However, will being in the 'player' category prevent the audio hiccup when the screen dims to black as well? Because currently as a 'radio' app, I still suffer from that problem.

Re: [application] pyRadio (Pandora)

Quote:

Originally Posted by fatalsaint (Post 716287)

However, will being in the 'player' category prevent the audio hiccup when the screen dims to black as well? Because currently as a 'radio' app, I still suffer from that problem.

Yes, it will. The built in Media Player uses this category to play its stuff. I have yet to notice it stuttering when the display goes off.

If you don't want to go the ctypes route, then editing xpolicy.conf is the way to go. I can't figure out how to pass the proplist in pulsesink's set_property function as it wants a GParamSpecPointer. How the **** am I meant to provide that? That bit of C I posted works fine because it expects a pointer and recieves one. Man, no wonder people prefer PyQt to PyGTK...

Re: [application] pyRadio (Pandora)

Thanx! This app is killer. The buffering fixed Pianobar for me!

Re: [application] pyRadio (Pandora)

Quote:

Originally Posted by qwerty12 (Post 716294)

Did you manage to see This??

I was using that in-tandem with the lib_pulseaudio source to work with it. I would expect (though haven't tried it) that if properly imported:

Code:

    self.pa_proplist_p = pa_proplist_new()

    self.set_proplist({

        "window.name":          self.client_name,

        "media.name":           self.client_name,

        "application.name":     self.client_name

    })



    #self.pa_context_p = pa_context_new_with_proplist(

    #                            self.pa_mainloop_api_p,

    #                            self.client_name)

    self.pa_context_p = pa_context_new_with_proplist(

                                self.pa_mainloop_api_p,

                                self.client_name,

                                self.pa_proplist_p)

The self.pa_context_p would be a proper type to what the set_properties needs? Is this not the case?

Re: [application] pyRadio (Pandora)

Quote:

Originally Posted by les_garten (Post 716298)

Thanx! This app is killer. The buffering fixed Pianobar for me!

Well.. not really.. it replaced pianobar for you :). Pianobar is no longer used.