Hello,
You are right, the murphy-ivi.lua is not fully transparent for example
in the type definition sense and we should probably do something about
it at some point.
The node types that can be used for outputs and application class
definitions are defined in scripting.c in the
pulseaudio-module-murphy-ivi source code:
"input" nodes (app classes):
{ "radio" , mir_radio },
{ "player" , mir_player },
{ "navigator" , mir_navigator },
{ "game" , mir_game },
{ "browser" , mir_browser },
{ "camera" , mir_camera },
{ "phone" , mir_phone },
{ "alert" , mir_alert },
{ "event" , mir_event },
{ "system" , mir_system },
"output" nodes:
{ "speakers" , mir_speakers },
{ "microphone" , mir_microphone },
{ "jack" , mir_jack },
{ "spdif" , mir_spdif },
{ "hdmi" , mir_hdmi },
{ "wired_headset" , mir_wired_headset },
{ "wired_headphone" , mir_wired_headphone },
{ "usb_headset" , mir_usb_headset },
{ "usb_headphone" , mir_usb_headphone },
{ "bluetooth_sco" , mir_bluetooth_sco },
{ "bluetooth_a2dp" , mir_bluetooth_a2dp },
{ "bluetooth_carkit" , mir_bluetooth_carkit },
{ "bluetooth_source" , mir_bluetooth_source },
{ "bluetooth_sink" , mir_bluetooth_sink },
This is a consequence of our concept of being able to write stuff
either in lua or C or both. However it should be more clear.
So how things work: inside pulseaudio-module-murphy-ivi we are having
heuristics to guess the output node type from alsa and bluetooth sinks
coming from udev and bluez. So if you use pulseaudio-module-murphy-ivi
in common desktop it should work quite well out of the box.
What if you have some exotic alsa that is not discovered by udev or
you want to override the discovery mechanism? Then you can load sink
and sources manually with pulseaudio. Then you have to configure
pulseaudio's configure file (like default.pa) and load the sink with
node.type property -> which tells pulseaudio-module-murphy-ivi who you
are.
Example:
load-module module-alsa-sink device=hw:0,3 sink_properties="node.type=hdmi"
Now this will be categorized as hdmi output by
pulseaudio-module-murphy-ivi and then you can use "hdmi" in the
routing group definition.
***********************************************************
Unfortunately we have at the moment only internal docs about the
configuration, but I'll try to put them online what we have asap.
br,
Jaska
P.S. Yu, please read the other mail I sent to the list, I hope it will
give you answers how the "role" is affecting the categorization to app
classes (input nodes).
________________________________________
From: 虞申鹏 [[email protected]]
Sent: Wednesday, December 17, 2014 10:15 AM
To: [email protected]
Cc: Uimonen, Jaska; [email protected]
Subject: Re: [IVI] Audio stream routing
Hi,
Thanks for the tips.
Now,I want to do a test which set different outputs by
[pulseaudio-module-murphy-ivi].
When I want to edit the [murphy-ivi.lua] file, This is a question about it.
> 1) I changed the default_driver routing group _not_ to route ever to
> usb_headset
Q: When I want to do it, I don't understand where [node.usb_headset] is defined?
And I want to know where define the [node].
And I have some questions about [murphy-ivi.lua] file.
Q1: If we don't define the [binaries] in application_class. When the App play
the Audio file,
The APP how to associate to the [application_class]?
Q2: What is the meaning for the [roles] setting.
By the way,Is there any documents about [murphy-ivi.lua]file?
------
Yu
2014-12-16 22:34 GMT+08:00 Uimonen, Jaska
<[email protected]<mailto:[email protected]>>:
Hello,
I apologize for the horribly long email, but it is hard to
explain this in shorter message.
First: Are you using the exactly same binary to play the 2 files?
There is a conceptual difficulty of identifying where the apps
need to be routed if we can't separate them or they are not
providing additional information through the audio API to be
handled by the policy engine. So apps would need to set some environment
variable, come from different sessions, set some properties on the
audio API's. Or then just they have to be different binaries...
*****************************
Second: Which API are the apps using for audio playback? 1) pulseaudio,
2) gstreamer or 3 some higher level API (like QT or similar)?
With 1 and 2 you can set properties to indicate where to route, or
what is your application class. With 3 it depends on the API can
you pass properties to underlying layers.
So for example with pulseaudio API I can just define the routing
target where to play. In my IVI box:
paplay -d
alsa_output.usb-Logitech_Logitech_USB_Headset-00-Headset.analog-stereo test1.wav
paplay -d alsa_output.pci-0000_00_1b.0.analog-stereo test2.wav
*******************************
pulseaudio-module-murphy-ivi can do automatic routing and its configuration
file is murphy-ivi.lua. There you define zones, routing groups and application
classes. Application class binds together zones and routing groups.
Unfortunately
you can't bind binary names to zones (and on to different routing groups) and if
you are using the same binary, that would not even work for you.
Here's what I changed in murphy-ivi.lua:
routing_group {
name = "default_driver",
node_type = node.output,
accept = function(self, n)
return (n.type ~= node.bluetooth_carkit and n.type ~= node.hdmi and
n.type ~= node.usb_headset)
end,
compare = builtin.method.compare_default
}
routing_group {
name = "default_passanger2",
node_type = node.output,
accept = function(self, n)
return (n.type == node.usb_headset or n.name<http://n.name> == 'Silent')
end,
compare = builtin.method.compare_default
}
application_class {
class = "player",
node_type = node.player,
priority = 1,
route = {
output = { driver = routing_group.default_driver_output,
passanger1 = routing_group.default_passanger1_output,
passanger2 = routing_group.default_passanger2_output}
},
roles = { music = {0, "mandatory", "exclusive"},
video = {0, "mandatory", "exclusive"},
test = {0, "mandatory", "exclusive"},
bt_music = no_resource,
player = no_resource
},
binaries = { ['t8j6HTRpuz.MediaPlayer'] = "music" }
}
In english:
1) I changed the default_driver routing group _not_ to route ever to usb_headset
2) I created new routing group passanger2, which routes only to usb_headset
(and to null if you don't have usb)
3) I bind the new routing group to app class player in the "output" section
So now you can play to different outputs:
paplay media.role=player test1.wav
paplay media.role=player --property=zone.name<http://zone.name>=passanger2
test2.wav
First stream goes to (default) driver zone and to speakers.
Second stream goes to passanger2 zone -> to usb (if it is attached)
****************************************
br,
Jaska
________________________________________
From: IVI [[email protected]<mailto:[email protected]>] on
behalf of 虞申鹏 [[email protected]<mailto:[email protected]>]
Sent: Tuesday, December 16, 2014 5:08 AM
To: [email protected]<mailto:[email protected]>
Subject: [IVI] Audio stream routing
This is a question about audio stream routing in IVI .
We want to play different MP3 files at the same time, and output to different
sound card.
(example:MP3 file A → sound card A
MP3 file B → sound card B
It will be play at the same time )
I'm sure we can route them by murphy.
I know the file[murphy-ivi.lua] is open in file[module-murphy-ivi.c].
But i don't know how to related to pulseaudio module?
And how to customize the route rule?
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
IVI mailing list
[email protected]
https://lists.tizen.org/listinfo/ivi
