| Wizzup | arno11: I get about 24h of battery life without any OC patches btw | 13:40 |
|---|---|---|
| Wizzup | with modem on etc | 13:40 |
| Wizzup | I think when ts actually idles it will save a lot more too | 13:40 |
| Wizzup | arno11: so for now, we can maybe have an init script that loads nokia-modem after ofono or something? | 14:02 |
| arno11 | Wizzup: (for the battery life) cool. yes we can even do better with TS stuff | 14:28 |
| arno11 | nokia modem must be loaded after all other modules | 14:29 |
| arno11 | to avoid random bugs and errors | 14:30 |
| Wizzup | well, I think we can have the init script run after ofono | 14:31 |
| Wizzup | that should be fine | 14:31 |
| arno11 | ok cool | 14:31 |
| arno11 | Wizzup: do you have troubles with audio ringstone ? | 14:34 |
| arno11 | or playing music ? | 14:35 |
| Wizzup | I haven't checked, but I will | 14:35 |
| Wizzup | I doubt that the same asound state works | 14:35 |
| Wizzup | this is why we need UCM | 14:35 |
| Wizzup | but I haven't checked it yet | 14:35 |
| Wizzup | back in a ibt | 14:35 |
| arno11 | because default 48000hz cause troubles | 14:35 |
| arno11 | using always same asound works fine | 14:36 |
| arno11 | but i recommand to use default 44100hz in daemon.conf | 14:37 |
| arno11 | Wizzup: sicelo: i successfully removed the 15 sec incoming call bug. It is not 100% functional ATM because i need to add a new "disconnected" state to hangup incoming calls properly. | 16:16 |
| arno11 | Anyway cmtspeech was using wrong ofono properties. | 16:17 |
| uvos | so what do we need mafw for exactly | 16:51 |
| uvos | ie what dose it bring to the table the usual desktop linux media frameworks dont? | 16:51 |
| freemangordon | like which one? | 16:58 |
| uvos | well all of them, so what would you gain when switching from for instance qtmultimedia with mp-ris to mafw? | 17:01 |
| uvos | for instance | 17:01 |
| freemangordon | integration with mce, for example | 17:01 |
| freemangordon | daemon | 17:02 |
| freemangordon | lighter footprint | 17:02 |
| freemangordon | iirc, libplayback integration | 17:03 |
| uvos | 1. what integraton? pause on blank? we need to add mp-ris support anyhow so that the desktop applications behave, same gos for libplayback | 17:03 |
| uvos | 2. not really a benefit | 17:03 |
| uvos | 3. citation needed it just uses gstreamer as a backend no? | 17:04 |
| freemangordon | libplayback is not what its name implies | 17:04 |
| freemangordon | https://github.com/maemo-leste/libplayback | 17:05 |
| uvos | libplayback is a client API that allows an application to declare its playback state | 17:05 |
| freemangordon | mhm | 17:05 |
| uvos | sounds exactly like mpris | 17:05 |
| uvos | and mpris is universally supported on desktop applications | 17:05 |
| uvos | realy 100% | 17:05 |
| freemangordon | feel free to install KDE then | 17:05 |
| uvos | how is mpris kde? | 17:05 |
| freemangordon | for example | 17:05 |
| uvos | its not even initated by them | 17:05 |
| freemangordon | and you'll have DE on your mobile | 17:06 |
| freemangordon | this conversation is really useless | 17:06 |
| freemangordon | because someone does not like/does not know some API does not make that API bad | 17:06 |
| uvos | im not saying its bad | 17:07 |
| freemangordon | anyway, libplayback is integrated with th eother parts of leste | 17:07 |
| freemangordon | if we are to keep what we know works good on mobile, I don;t see why shall we reinvent the wheel | 17:07 |
| uvos | but your expending signifcant effort draging a api into the present, that duplicates a widly used available api that we need to implement anyhow because its widely used | 17:07 |
| uvos | so i question this | 17:08 |
| freemangordon | I( understand that | 17:08 |
| freemangordon | but I am not convinced taking desktop applications and puting them on mobile is a good idea | 17:08 |
| freemangordon | not to say none of them are integrated with OS/DE in the way maemo components are | 17:09 |
| uvos | even if you ignore any "desktop" application (i highly object to this), the problem is also that our colleagues @plamo and probubly also phosh are developing mobile focused applications that do use thes apis | 17:10 |
| freemangordon | I know you have little idea what I am talking about having almost none experience with fremantle as user, unfortunately I have no idea how to explain such UX | 17:10 |
| uvos | the "ux" has nothing to do with the api used to accive the effect | 17:10 |
| freemangordon | it has lots of | 17:10 |
| uvos | imo the "ux" will be mutch worse if the apis used are only implemented by a tiny subset of the avialble applications | 17:11 |
| freemangordon | I don;t need 10 media players | 17:11 |
| freemangordon | nor 10 phone apps | 17:11 |
| freemangordon | I need one that works well | 17:11 |
| freemangordon | BTW, OMP is a QT FOSS rewrite of the stock Nokia MP, that was written in GTK | 17:12 |
| freemangordon | so MAFW must be good enough to allow that | 17:12 |
| freemangordon | also, there is MP destop widget, which is built upon the fact that MAFW gives daemopn | 17:13 |
| uvos | well on fremantle they where more or less forced to go trough contortions to use nokias apis for anything to work | 17:13 |
| freemangordon | no | 17:13 |
| freemangordon | there was QtMultimedia back then | 17:13 |
| uvos | sure but it dosent itegrate with os at all | 17:13 |
| freemangordon | qyoutube uses it, for example | 17:13 |
| uvos | because the os bits are only implemented on the nokia api side.. | 17:14 |
| freemangordon | what bits exactly? | 17:14 |
| freemangordon | also, how is the situation any better now? | 17:14 |
| uvos | well i would expect stuff to duck/pause for notifactions, maybe song title on the lockscreen, def things like universal media widges on h-h | 17:15 |
| freemangordon | right | 17:15 |
| uvos | ie the stuff mpris is used for on desktop | 17:15 |
| uvos | and plamo etc | 17:15 |
| buZz | i would like 'x unread sms' 'x missed calls' on lockscreen | 17:15 |
| freemangordon | buZz: umm, we have that | 17:16 |
| uvos | no we dont | 17:16 |
| buZz | oh? havent ever seen any | 17:16 |
| freemangordon | yes, we do | 17:16 |
| uvos | no sphone is not called "rtcom" | 17:16 |
| uvos | so it dosent work | 17:16 |
| freemangordon | well, that does not mean we *do not* have it | 17:16 |
| buZz | ah yeah its the 'sphone wont get features we want' argument? | 17:16 |
| freemangordon | right, it does not work | 17:16 |
| uvos | since its hardcoded to only show when its from "rtcom" | 17:16 |
| uvos | buZz: its not really sphones fault | 17:16 |
| buZz | but? | 17:17 |
| uvos | see above | 17:17 |
| freemangordon | no, it is hardcoded to read the DB with sql queries | 17:17 |
| freemangordon | anyway | 17:17 |
| buZz | that doesnt tell me why it cant read the information from the db | 17:17 |
| buZz | is the information in the db? | 17:17 |
| freemangordon | no | 17:17 |
| buZz | can we put it in? :) | 17:17 |
| freemangordon | because nobody puts it there | 17:17 |
| freemangordon | \sure | 17:18 |
| freemangordon | *sure | 17:18 |
| buZz | but why arent we, then? | 17:18 |
| freemangordon | because Wizzup seems to be overloaded lately | 17:18 |
| buZz | is the rtcom-db-not-filled also the cause for unable to add numbers from 'recent' in contacts? | 17:18 |
| freemangordon | yes | 17:18 |
| buZz | ah, sounds important then :) | 17:18 |
| freemangordon | well... | 17:18 |
| freemangordon | we had that discussion couple of times already | 17:19 |
| freemangordon | no need to repeat once again | 17:19 |
| freemangordon | we know what/where has to be done | 17:19 |
| freemangordon | it is just that nobody did it already | 17:20 |
| buZz | alright :) | 17:21 |
| freemangordon | uvos: so, in your QtMultimedia example, who will lower the volume in case of notification or stop playback in case of a phone call? | 17:22 |
| freemangordon | shall we teach QtMultimedia on that? | 17:23 |
| uvos | freemangordon: so we would just have someone (maybe mce, maybe some pa plugin) stop or lower all mpris clients when required | 18:21 |
| uvos | centrally | 18:21 |
| uvos | then everybody should follow, incl random media players and browsers etc | 18:21 |
| uvos | to enforce just lowering of the volume (as opposed to stoping playback) we should also affect the pa streams | 18:22 |
| uvos | so that works for games and so on too | 18:22 |
| uvos | you can alos have pa stop accepting writes on the soccet (on d4 we currently do this when in call mode) | 18:23 |
| uvos | how this affects applications is a bit uneven and i dont know if dothing this is a good plan long term | 18:23 |
| uvos | some applications use non-blocking writes and pause themselves when they cant write to pa | 18:23 |
| uvos | otheres use blocking writes and hang untill pa unblocks the stream | 18:24 |
| uvos | the latter is a bit undesirable ofc | 18:24 |
| freemangordon | ok, but IIUC that would require way more effort that just porting 50 LOC from gst 0.1 to gst 1.0 | 18:39 |
| freemangordon | and yet, we are tied to and API, not mafw, but MPRIS | 18:40 |
| freemangordon | which we have no idea how it works on mobile and what downsides it has | 18:40 |
| freemangordon | s/and API/another API/ | 18:40 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!