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.