Fwd: Audio-Visual zones in the car
Oh I forgot MeeGo mailing lists are somewhat "special".. Thanks Marjan
for the notice, forwarding the right way to the list..
---------- Forwarded message ----------
From: Marco Ballesio <gibrovacco@...>
Date: Wed, Feb 2, 2011 at 11:24 PM
Subject: Re: [MeeGo-ivi] Audio-Visual zones in the car
To: "Komatovic, Marjan" <marjan.komatovic@...>
jumping into this interesting thread even though it somewhat is not my area.
First of all, my opinion about the open question Marjan has posted in
the wiki (copied/pasted here):
"Where is IIR and/or FIR filtering best handled - GStreamer or Pulse?
GStreamer has some implementations, is that the most appropriate
The answer is "well, it depends" ;). GStreamer already comes with
plenty of filters and effects for audio ("Audio effects" aka audiofx
plugin), here you go for some references:
No filters of that kind exist (so far) in pulseaudio but, in case you
want to make applications agnostic for such a filtering, you'll have
to do it in the sound server, maybe implementing your own "effects"
some more coins worth 5 cents below..
On Wed, Feb 2, 2011 at 2:33 PM, Komatovic, Marjan
> In regards to your question, this is something that can’t be done
> statically. We need to have some policy framework that would sit on top of
> Pulse Audio and use its stream control capability. For example, the
> “proximity” application would compete for resources (speakers) with other
> applications based on priority.
Isn't it possible to have them playing at the same time? For instance,
should the player be paused while the proximity sensor beeps on a
> Assuming highest priority, policy framework
> would allow “proximity” application to use resources while either stopping,
> pausing other applications or just corking audio streams at source/sink
> side. To my best knowledge, that kind of policy handling capability already
> resides in Resource Management component:
this document is for the application developers' bookshelf, and does
not reveal too much about how to actually write an enforcement point.
In the following, keep the slides of my presentation under the eyes
The pieces of code you might be interested into are here:
the xpolicy.conf file under the "examples" folder is an example
configuration to feed the enforcement point beast with. You'll find
there a set of elements with the "groups", "group", "device" and
"stream" tag, each of those exposing some attributes (for instance,
To understand a little more about the meaning of the tags within [..]
you'll have to switch to the policy ruleset, which instructs the
engine to decide as we wish to. This other piece is here:
This is a restricted set of rules for the decision point. For instance, here:
you can find a declarative list of example groups and group types
(compare them with the ones in the enforcement point configuration to
understand what they're for).
Now, let's go back to xpolicy.conf and its attributes. They're
unfortunately undocumented but it's easy to guess what they do by
their name. For instance cork_stream means that applications
pertaining to the given group can be corked if needed. In case of
doubt.. use the source (and the mailing list), Luke!
Maybe I'm running too long with the email (and I recognize what I'm
writing is just an appetizer), but the last question I'd like to give
some clues about is "and how is it decided when to cork an application
Two files in the resource policy settings are of major interest for
the rule of corking we've analyzed so far:
basic/policy/policy.dres: it's the dependency resolver configuration
file. As in a Makefile (well, the syntax is not exactly as in a
Makefile, but almost the same), it declares which dependencies must be
satisfied when a given fact has changed in the store. Let's jump to
the following target:
$audio_cork[group] |= prolog(set_corks)
It means that when something has changed in an entry of the
resource_owner variable (see at the beginning of the file to know more
about its simple structure) it triggers the audio_cork target, which
calls the prolog rule "set_corks" and updates the state of the
audio_cork variable (again, see at the beginning of the file).
basic/policy/audio_cork.pl: here are the prolog rules executed from
the audio_cork target. The file is pretty simple, but it's in Prolog
and related to concepts and functions also defined in the dependency
resolver itself, available at:
As a leap of faith, believe me that those functions are modifying
appropriately the entries in the audio_cork variable ;). For more
details, a little more knowledge about declarative languages is needed
(not that much to be honest).
As a note of interest, the action of corking a stream modifies (as
already said) the audio_cork target, which in turn triggers the
targets "audio_actions" and "all". Well, if you go and check the code
it's easy to guess that the first one will eventually trigger a dbus
message towards the enforcement point. How? It's specified into a
Resource Policy Framework/ohm plugin (guess which one) you can
retrieve from here:
Sorry for the long email, but hopefully it gives some basic hints on
how to start hacking. Maybe we could make a wiki out of it..