Automotive Business Group Teleconference on RSI

<scribe> Meeting: RSI

<PatrickB> Hi all

<PatrickB> I can only make it for about 30min today. sorry in advance

Cross platform audio feature

<rstreif> Me too, I have another meeting at 1:30p

https://github.com/wzr1337/viwiServer/tree/feature/AudioPlayback

PatrickB: I took some time this week to figure out how to have a cross platform media player
... I took lame decoder and a module, the "stupid player"
... it lacks seeking within the song and @@
... I implemented an offset counter so I could at least inform clients of the current offset
... starting, stopping, resuming and alerting clients of offset
... 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

Paul: I got the server up and running, no problem

PatrickB: I have a mock audio server and this second one based on lame. they'll be available next to each other

PatrickL: next steps, you'll continue with your media library plans, I will install and test on Windows

Paul: the reason I asked Joel to join is because he has experience wiring up various media players with a server like this

Joel: in the case of this server, I implemented something in C that does all this, starting from an open source project
... it can bring in a media library

Paul: Gunnar, anything from LBS side?

Gunnar: I hope Rudi can report as I have too much background noise

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

PatrickB: you also have to define the object structure, right?

Rudi: correct, it could be JSON or other. using JSON from Genivi's model

Gunnar: basically you describe in a hierarchical fashion and it is separate from the protocol
... what we can show today is what is described in the pdf

https://gunnarx.github.io/pyfrancagen

Gunnar: it is documenting the C++ from Franca
... the APIs we define are relatively deep and complex
... we wanted to present these LBS APIs as detailed as possible
... this might be a challenge for WAMP
... due to complex data types, etc

Paul: what is an example of something not easily translatable?

Gunnar: types can be defined in terms of other types. we can serialize into simpler strings and integers
... we're learning by doing this in practice
... a next step would be to figure out what would be relevant subset for this (RSI) API
... the Franca model is based on everything available from the underlying navigation system
... are things like the number of satellites in communication with and level of location precision of interest?

Joel: I would imagine the server we are talking about is for a user interface?

Paul: RSI was conceived in the world of IVI

PatrickB: that was where its origins are but not necessarily limited

Joel: the primary use case is the user interface or..?

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

Paul: our LBS needs are native navigation, POI, routing, etc

Gunnar: that makes sense

Joel: I'm not seeing POI in Genivi's LBS

see clarification, POI is available

Paul: we should go over Qing An and Philippe Colliot's use cases
... I'll take an action to look over the use cases and propose ones to focus on. others are welcome to do the same
... Joel can spend time the next week looking into RSI more

<PatrickB> 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 ;)

Paul: get/set destination is a very common need

Gunnar: that is in the navigation service interface

[PatrickB, I'll take up that question]

Paul: has anyone commercially implemented Genivi's interface
... I've seen some demos from Philippe, how complete are they?

<PatrickB> 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?

Paul: are there other products that already use this interface we can look at

Gunnar: I would not expect those to be available in open source

<PatrickB> I am out... cya all!!

Gunnar: these navigation system runtimes are licensed
... demonstrations we have given have been based on NavIT
... that would be useful for playing around
... it is a subset of APIs for web
... we could create proof of concept based on subsets

Paul: sticking with these two (media and LBS) make sense

Joel: which do you think first?

Paul: media first as it is simpler and then we can settle on what can be used

Joel: media is just an implementation exercise
... are there any sample client interfaces sitting on top of this yet?

Paul: we could run ours

Joel: I can create a slide deck for next week

Ted reads Patrick's questions

PatrickL: I'll talk to Patrick about a client, also fine with OpenCar based demo

Ted: before you joined we heard a bit about PatrickB's choice of lame to support Windows developers

Joel: you can run VLC on Windows as well but with some limitations

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

Joel: Cameo I believe is based on VLC
... it is heavy weight but does support a decent number of codecs

Paul: did Sanjeev have any more commits?

PatrickL: I haven't seen anything from him in the last few days

Joel: would having a yacto meta layer be helpful for flushing this out?

Ted looks up https://en.wikipedia.org/wiki/Yocto_Project

Rudi: or you could read my book on it...

Paul: or watch his youtube videos (training classes)

Joel: is there a test suite yet?
... for the service definitions

PatrickL: we do not have a public test suite

Paul: it would be great to have one of those start to form
... we opened up a few things
... we should also look at what Urata has produced, see if it might be helpful here

Joel: anything other than protocol and service definitions, like threading model (single or multiple)?

PatrickL: being able to answer multiple clients would be a good idea, you want multi-threading for being more responsive in general

Joel: is there an anticipated memory footprint to stay within?

PatrickL: no

Joel: what is the lowest common denominator hardware it would run on?

PatrickL: I'm running on an rpi

Paul: it seems we have made progress and have next steps