[application] pyRadio (Pandora) - Page 3 - maemo.org

Active Topics

Firefox with Leste (10)
to Maemo 7 / Leste by teroyk - 3 days, 5 hrs ago
more...

Page 3 of 100

< Prev

Next >

Last »

Thread Tools

	qwerty12	2010-06-15 , 15:15
	Posts: 4,274 \| Thanked: 5,358 times \| Joined on Sep 2007 @ Looking at y'all and sighing	#21

Originally Posted by fatalsaint

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.

Quote & Reply |

fatalsaint	2010-06-15 , 15:29
Posts: 3,428 \| Thanked: 2,856 times \| Joined on Jul 2008	#22

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.

__________________
If I've helped you or you use any of my packages feel free to help me out.
-----------------------------------------------------------------------------------
Maintaining:
pyRadio - Pandora Radio on your N900, N810 or N800!

Quote & Reply |

The Following User Says Thank You to fatalsaint For This Useful Post:
Flandry

fatalsaint	2010-06-15 , 15:32
Posts: 3,428 \| Thanked: 2,856 times \| Joined on Jul 2008	#23

Originally Posted by qwerty12

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
]

Quote & Reply |

fatalsaint	2010-06-15 , 15:35
Posts: 3,428 \| Thanked: 2,856 times \| Joined on Jul 2008	#24

Of course.. then the question becomes:

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

Quote & Reply |

	qwerty12	2010-06-15 , 15:36
	Posts: 4,274 \| Thanked: 5,358 times \| Joined on Sep 2007 @ Looking at y'all and sighing	#25

Originally Posted by fatalsaint

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.

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.)

Quote & Reply |

fatalsaint	2010-06-15 , 15:53
Posts: 3,428 \| Thanked: 2,856 times \| Joined on Jul 2008	#26

Originally Posted by qwerty12

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.)

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.

Last edited by fatalsaint; 2010-06-15 at 15:56.

Quote & Reply |

The Following User Says Thank You to fatalsaint For This Useful Post:
Flandry

	qwerty12	2010-06-15 , 15:59
	Posts: 4,274 \| Thanked: 5,358 times \| Joined on Sep 2007 @ Looking at y'all and sighing	#27

Originally Posted by fatalsaint

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...

Last edited by qwerty12; 2010-06-15 at 16:01. Reason: Err... I mean yes

Quote & Reply |

The Following User Says Thank You to qwerty12 For This Useful Post:
fatalsaint

les_garten	2010-06-15 , 16:03
Posts: 1,283 \| Thanked: 370 times \| Joined on Sep 2009 @ South Florida	#28

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

__________________
N900 as a Drive Letter in Windows, FULL Root access!!
Maemo! There's a BUG for that!
Cutomize Maemo!
Noobies - Noobies 2 - Maemo 5 - 101
Maemo FAQ

Quote & Reply |

fatalsaint	2010-06-15 , 16:23
Posts: 3,428 \| Thanked: 2,856 times \| Joined on Jul 2008	#29

Originally Posted by qwerty12

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...

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?