View Single Post
Posts: 3,428 | Thanked: 2,855 times | Joined on Jul 2008
Originally Posted by qwerty12 View Post
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.
If I've helped you or you use any of my packages feel free to help me out.
pyRadio - Pandora Radio on your N900, N810 or N800!

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

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