19:55:48 RRSAgent has joined #auto 19:55:48 logging to http://www.w3.org/2017/04/19-auto-irc 19:55:50 RRSAgent, make logs public 19:55:50 Zakim has joined #auto 19:55:52 Zakim, this will be 19:55:53 I don't understand 'this will be', trackbot 19:55:53 Meeting: Automotive Working Group Teleconference 19:55:53 Date: 19 April 2017 19:55:56 Meeting: RSI 20:03:19 PatrickB has joined #auto 20:03:27 Hi all 20:03:36 Agenda: http://www.w3.org/mid/F0782AEA-1934-45C7-AAE6-5E61DDB2F787@inrix.com 20:03:44 I can only make it for about 30min today. sorry in advance 20:04:06 Agenda+ Cross platform audio feature 20:04:09 zakim, next agendum 20:04:09 agendum 1. "Cross platform audio feature" taken up [from ted] 20:04:14 Me too, I have another meeting at 1:30p 20:04:34 -> https://github.com/wzr1337/viwiServer/tree/feature/AudioPlayback 20:05:22 PatrickB: I took some time this week to figure out how to have a cross platform media player 20:05:45 … I took lame decoder and a module, the "stupid player" 20:05:59 … it lacks seeking within the song and @@ 20:06:19 … I implemented an offset counter so I could at least inform clients of the current offset 20:06:30 … starting, stopping, resuming and alerting clients of offset 20:07:24 … I cannot seek to a certain position and how to interact with a media library. i have a single song in a designated location (path and filename) for now 20:08:07 Present+ Paul, Joel, Rudi, Ted, PatrickB, PatrickL, Gunnar 20:08:17 Paul: I got the server up and running, no problem 20:08:51 PatrickB: I have a mock audio server and this second one based on lame. they'll be available next to each other 20:10:09 PatrickL: next steps, you'll continue with your media library plans, I will install and test on Windows 20:10:29 Paul: the reason I asked Joel to join is because he has experience wiring up various media players with a server like this 20:10:55 Joel: in the case of this server, I implemented something in C that does all this, starting from an open source project 20:11:56 … it can bring in a media library 20:12:32 Paul: Gunnar, anything from LBS side? 20:12:57 Gunnar: I hope Rudi can report as I have too much background noise 20:13:52 Rudi: we have signals available through WAMP and should be able to connect to simulated CAN signals as well, should be ready in a couple days 20:14:08 PatrickB: you also have to define the object structure, right? 20:14:56 Rudi: correct, it could be JSON or other. using JSON from Genivi's model 20:16:01 Gunnar: basically you describe in a hierarchical fashion and it is separate from the protocol 20:16:27 … what we can show today is what is described in the pdf 20:16:53 https://gunnarx.github.io/pyfrancagen 20:17:49 Gunnar: it is documenting the C++ from Franca 20:18:13 … the APIs we define are relatively deep and complex 20:18:36 … we wanted to present these LBS APIs as detailed as possible 20:18:47 … this might be a challenge for WAMP 20:18:59 … due to complex data types, etc 20:19:18 Paul: what is an example of something not easily translatable? 20:19:58 Gunnar: types can be defined in terms of other types. we can serialize into simpler strings and integers 20:20:21 … we're learning by doing this in practice 20:20:58 … a next step would be to figure out what would be relevant subset for this (RSI) API 20:21:54 … the Franca model is based on everything available from the underlying navigation system 20:22:19 … are things like the number of satellites in communication with and level of location precision of interest? 20:22:45 Joel: I would imagine the server we are talking about is for a user interface? 20:23:59 Paul: RSI was conceived in the world of IVI 20:24:26 PatrickB: that was where its origins are but not necessarily limited 20:24:52 Joel: the primary use case is the user interface or..? 20:27:14 Ted: it is more about creating an ecosystem for exposing vehicle signals, location, media to 3rd party app developers that will run on the head unit, pulling in bits of data needed 20:28:02 Paul: our LBS needs are native navigation, POI, routing, etc 20:28:08 Gunnar: that makes sense 20:28:25 Joel: I'm not seeing POI in Genivi's LBS 20:29:07 Paul: we should go over Qing An and Philippe Colliot's use cases 20:29:39 … I'll take an action to look over the use cases and propose ones to focus on. others are welcome to do the same 20:30:13 … Joel can spend time the next week looking into RSI more 20:30:41 As I have to leave in a few minutes.. Can you please discuss, how INRIX could suppport on Media implementations? I heard you had a C implementation... can this be used from within NodeJS? I somehow have the feeling that my approach will end up in a lot of work for a single person.. /me ;) 20:30:51 Paul: get/set destination is a very common need 20:31:02 Gunnar: that is in the navigation service interface 20:31:31 [PatrickB, I'll take up that question] 20:32:08 Paul: has anyone commercially implemented Genivi's interface 20:32:19 … I've seen some demos from Philippe, how complete are they? 20:32:37 So guys.. I will continue on Media stuff till next week... maybe we can also talk about a simple HTLm5 client .. maybe Patrick and I can build something for demo purposes in May? @PatrickL: Can we? 20:32:46 … are there other products that already use this interface we can look at 20:33:01 Gunnar: I would not expect those to be available in open source 20:33:38 I am out... cya all!! 20:33:39 … these navigation system runtimes are licensed 20:34:22 … demonstrations we have given have been based on NavIT 20:34:30 … that would be useful for playing around 20:34:37 … it is a subset of APIs for web 20:34:50 … we could create proof of concept based on subsets 20:35:21 Paul: sticking with these two (media and LBS) make sense 20:35:46 Joel: which do you think first? 20:36:03 Paul: media first as it is simpler and then we can settle on what can be used 20:36:15 Joel: media is just an implementation exercise 20:36:43 … are there any sample client interfaces sitting on top of this yet? 20:36:48 Paul: we could run ours 20:36:57 Joel: I can create a slide deck for next week 20:38:07 Ted reads Patrick's questions 20:39:30 PatrickL: I'll talk to Patrick about a client, also fine with OpenCar based demo 20:39:49 Ted @@on VLC, PatrickB's choice of lame 20:40:50 Joel: you can run VLC on Windows as well but with some limitations 20:41:50 Ted: I'm not sure what was the sticking point earlier with VLC but as the lame solution has limitations as well having a more capable VLC option for some developers would likely be welcome 20:41:59 Joel: Cameo I believe is based on VLC 20:42:26 … it is heavy weight but does support a decent number of codecs 20:42:37 I have made the request to generate http://www.w3.org/2017/04/19-auto-minutes.html ted 20:43:15 Paul: did Sanjeev have any more commits? 20:43:28 PatrickL: I haven't seen anything from him in the last few days 20:45:36 Joel: would having a yacto meta layer be helpful for flushing this out? 20:47:02 Ted looks up https://en.wikipedia.org/wiki/Yocto_Project 20:47:10 Rudi: or you could read my book on it... 20:48:14 Paul: or watch his youtube videos (training classes) 20:48:47 Joel: is there a test suite yet? 20:49:12 … for the service definitions 20:49:27 PatrickL: we do not have a public test suite 20:49:44 Paul: it would be great to have one of those start to form 20:50:13 … we opened up a few things 20:50:45 … we should also look at what Urata has produced, see if it might be helpful here 20:51:15 Joel: anything other than protocol and service definitions, like threading model (single or multiple)? 20:51:47 PatrickL: being able to answer multiple clients would be a good idea, you want multi-threading for being more responsive in general 20:52:19 Joel: is there an anticipated memory footprint to stay within? 20:52:25 PatrickL: no 20:52:44 Joel: what is the lowest common denominator hardware it would run on? 20:53:06 PatrickL: I'm running on an rpi 20:54:20 Paul: it seems we have made progress and have next steps 20:54:29 I have made the request to generate http://www.w3.org/2017/04/19-auto-minutes.html ted 22:27:00 kaz has joined #auto 22:53:51 kaz has joined #auto