**** BEGIN LOGGING AT Tue Jul 26 02:59:56 2011 Jul 26 05:48:57 SHR: 03Martin.Jansa 07shr-chroot * rc2a0ba6f8242 10/ (25 files in 9 dirs): bitbake upgrade Jul 26 05:53:08 moin JaMa :-) Jul 26 05:54:17 SHR: 03Martin.Jansa 07meta-smartphone * r5d1fe7a7144e 10/meta-zaurus/conf/machine/include/ (tune-xscale.inc zaurus.inc): meta-zaurus: drop tune-xscale and update zaurus.inc for new tune files in oe-core Jul 26 05:54:21 SHR: 03Martin.Jansa 07meta-smartphone * r90e54b8a13fe 10/meta-openmoko/conf/machine/include/tune-arm920t.inc: meta-openmoko: drop tune-arm920t, because we need it from oe-core now Jul 26 05:55:18 moin Jul 26 10:05:15 DocScrutinizer: I don't see anything in the UCM description preventing several non-conflicting use cases being active in parallel Jul 26 10:07:42 I think the concepts are fundamentally sound: applications can request the use case they are interested in; there is a distinct (though somewhat dependent) input/output device selection; and applications get a volume control independent of the device Jul 26 10:08:44 only thing I take issue with is that applications apparently have to select the input/output devices explicitly -- which IMHO should be rather done by a system-wide configuration manager, as most applications don't even care which one is active Jul 26 10:11:14 well, there is one more issue: if I read it right, the volume control abstraction offers a common control not only across devices, but also use cases -- which seems wrong to me. an application could in theory request two different use cases at the same time, and should get distinct volume controls for them Jul 26 10:11:38 (for applications using only one use case it doesn't matter anyways...) Jul 26 10:13:50 hm... on the other hand, as most applications don't care about the use case, it makes sense to always present an abstract "output volume" control... Jul 26 10:14:36 well, perhaps not most, but some at least Jul 26 10:15:46 but for applications oblivious of the use case management, we need aliasing with some external configuration file anyways, so we could just as well alias the "output volume" control too Jul 26 10:16:59 it's not clear though from the description whether the UCM functionality can be used at all for applications not having explicit support for it -- if that's not the case, that would indeed be a total showstopper for the whole concept Jul 26 10:20:38 actually, scratch that part about distinct volume controls for applications using multiple use cases: as they would need a separate ALSA device for each active use case anyways, it's not a problem if the same abstract volume control is used for each Jul 26 11:05:45 DocScrutinizer, hi are USB,SSB,AXI,SPI wifi card suitable for embedded devices (if they are hard mac of course) Jul 26 11:33:01 mrmoku, hi Jul 26 12:40:22 antrik: ( DocScrutinizer: I don't see anything in the UCM description preventing several non-conflicting use cases being active in parallel) well, do you see anything in the scenario concept description mentioning that property explicitly? I mean IF they had even thought about it, then they had used a better implementation and concept Jul 26 12:41:02 GNUtoo|laptop: I don't know how to answer this question Jul 26 12:41:44 do you have more details why you don't know how to answer? Jul 26 12:41:53 you don't know the response? Jul 26 12:41:54 or Jul 26 12:42:02 you don't know how to explain it to me? Jul 26 13:17:04 I don't even seem to understand the question, or it is not one but 4 very general sense questions Jul 26 13:19:19 antrik: there's nothing mentioning any time that I can not plug two powerplugs same time to one power wall outlet Jul 26 13:20:03 antrik: I don't think you can, nevertheless, otherwise they would have mentioned the special property of that wall outlet Jul 26 13:39:04 sorry I was disconnected (I'm at a wifi cafee) Jul 26 13:52:21 mrmoku, hi Jul 26 13:52:22 ping Jul 26 14:10:19 mickeyl, hi Jul 26 14:18:44 hi GNUtoo|laptop Jul 26 14:19:34 what should I work on for the n900 Jul 26 14:19:36 ? Jul 26 14:20:14 GNUtoo|laptop: could you try to fill in the usecase for n900 to the fsoaudiod wiki page? Jul 26 14:20:26 hmmm Jul 26 14:20:33 I can add part of it Jul 26 14:20:40 but I don't know well the alsa part Jul 26 14:20:53 (all the switches etc...) Jul 26 14:21:08 well I don't think it has to be that detailed Jul 26 14:21:58 ok Jul 26 14:22:39 thx Jul 26 14:22:57 GNUtoo|laptop: so you could do the bluetoothd thing? Jul 26 14:24:20 angelox|laptop, done Jul 26 14:24:35 angelox|laptop, do you use fso-autorev.inc? Jul 26 14:24:52 bluetoothd is launched automatically for om-gta02 Jul 26 14:24:56 but not for n900 Jul 26 14:25:03 n900's bluetooth is broken anyway Jul 26 14:25:13 I'm waiting for meego devs to repair it Jul 26 14:25:21 it's broken in the kernel Jul 26 14:25:35 it's because i'd like to know how did you do it,using that process.vala(iirc that's the name) or some process async function Jul 26 14:25:35 mrmoku, done Jul 26 14:25:48 I'll look Jul 26 14:26:33 9b59374affb63da927ff7f73abe8c80921099e1b Jul 26 14:26:36 look at that commit Jul 26 14:26:41 in cornucopia Jul 26 14:26:59 GLib.Process.spawn_async Jul 26 14:27:05 and Jul 26 14:27:06 Posix.kill Jul 26 14:29:50 ah ok,understood,thank you Jul 26 14:31:08 the thing was to use the option for not spawning in the background Jul 26 14:31:12 else it would change the pid Jul 26 14:31:18 because of the fork Jul 26 14:31:26 or rather clone in linux Jul 26 14:32:31 i see... Jul 26 15:32:36 mrmoku, what should I work on now? Jul 26 15:32:51 now that I completed the use cases of the audio Jul 26 15:33:54 * JaMa votes for oe-core :) Jul 26 15:35:47 JaMa|Off, I cannot my oe-cores hdds are in the flat, and I'm at the wifi cafee Jul 26 15:36:01 s/cannot/can't : Jul 26 15:36:47 maybe I should work on voicecalls Jul 26 15:36:49 for the n900 Jul 26 15:36:51 but.... Jul 26 15:36:57 I've no idea on where's the bug Jul 26 15:38:56 mrmoku, did you keep the debugging? Jul 26 15:40:54 GNUtoo|laptop: what debugging? Jul 26 15:41:16 the debugging necessary to understand what's going on Jul 26 15:41:18 for instance Jul 26 15:41:26 the positions Jul 26 15:41:28 etc... Jul 26 15:42:51 I see some printf Jul 26 15:42:55 that should work I guess Jul 26 15:43:01 GNUtoo|laptop: yup the printfs are still there Jul 26 15:43:05 ok nice Jul 26 15:43:34 I must wait until the compilation of shr-image finishes tough Jul 26 15:43:47 *shr-lite-imag Jul 26 15:44:56 btw it seem that sim cards with pin are not asked the PIN graphically anymore Jul 26 15:45:05 for htcdream and n900 at least Jul 26 15:53:52 GarthPS, hi you have SFR, right? Jul 26 15:54:05 do you know what to do to get your voice played back Jul 26 15:54:09 GNUtoo|laptop: Hi! yes indeed Jul 26 15:54:23 GNUtoo|laptop: hmm? Jul 26 16:02:45 GarthPS, should I go to SFR and ask? Jul 26 16:02:52 it seem that there is a number Jul 26 16:02:55 the 7377 Jul 26 16:02:59 but it's not free Jul 26 16:03:09 in wind in italy it's free when you're in italy Jul 26 16:03:13 but I'm not in italy Jul 26 16:03:38 GNUtoo|laptop: I don't get what you awnt to do.. Jul 26 16:03:54 it's simple: Jul 26 16:03:57 I've an n900 Jul 26 16:04:11 we must extract and play the audio from the modem Jul 26 16:04:20 that is not perfect but acceptable for a developper Jul 26 16:04:26 however Jul 26 16:04:50 sending the microphone data to the modem works very bad Jul 26 16:04:53 so I want to test Jul 26 16:05:05 to test that I need a number that plays my voice back Jul 26 16:05:12 like for personalizing the voicemail Jul 26 16:05:17 or something like that Jul 26 16:06:40 GNUtoo|laptop: ah ok understood Jul 26 16:07:39 GNUtoo|laptop: so you ask me if i know a number when you are at SFR in France which play you back your voice , that is waht you want ? Jul 26 16:07:51 yes but a free number Jul 26 16:12:24 btw mrmoku how do I make 3g works Jul 26 16:12:28 I do that: Jul 26 16:12:31 modprobe pn-pep Jul 26 16:12:42 then the equivalent of AT+CFUN with the pin Jul 26 16:12:45 and then it comes up Jul 26 16:12:47 I register Jul 26 16:12:50 it registers Jul 26 16:12:58 but then I set the parametes and activate Jul 26 16:13:14 that add the gprs0 interface Jul 26 16:13:18 but it doesn't come up Jul 26 16:13:22 and I've no IP Jul 26 16:13:24 any hints Jul 26 16:13:25 ? Jul 26 16:17:20 I'll go Jul 26 16:17:27 to SFR... Jul 26 16:21:13 GNUtoo|laptop: Ok. for now I know the "123" which call your voicemail, then you can record your voicemail message and hear it before to valid it. but other thatn that I don't know Jul 26 17:24:54 I'm failing to see the use of that usecase wikipage http://wiki.freesmartphone.org/index.php/Implementations/fsoaudiod/RoutingUsecases Jul 26 17:35:20 >>Most devices has a very different way to do audio routing. This page will collect most of them so we can create a general approach to handle all of them in a common way.<< I thought we already decided on ACI and a general platform agnostic fsoaudiod would be the common way to handle this. Where the hardware abstraction happens in either specific .asoundrc files, or specific implementations of (wrappers around) amixer executable, Jul 26 17:35:21 or both Jul 26 17:37:03 >>That is implemented in an fsoaudiod plugin named gsmvoice_alsa_cmtspeechdata<< makes me shudder Jul 26 18:24:14 I received a mail with info about an OS which is going to be developed by mozilla. I'll forward it to SHR ml. Jul 26 18:24:36 mickeyl, it seems they might be interested in FSO -> https://wiki.mozilla.org/B2G Jul 26 18:25:26 the web APIs they are looking for might be similar to those provided by fso. Jul 26 18:25:48 it might be posible to use dbus in javascript? Jul 26 19:00:37 dcordes_: ping Jul 26 19:18:48 haha, FF OS. Jul 26 19:19:29 http://en.wikipedia.org/wiki/Google_Chrome_OS metoo Jul 26 21:41:18 SHR: 03Martin.Jansa 07meta-smartphone * re751af5ba16e 10/meta-fso/recipes-freesmartphone/freesmartphone/ (5 files): meta-fso: sync with oe.dev Jul 26 22:00:33 SHR: 03Martin.Jansa 07meta-smartphone * rab466c6e9576 10/meta-shr/recipes-shr/images/shr-image.inc: shr-image: move core-image import to keep POKY_BASE_INSTALL in IMAGE_INSTALL Jul 26 22:00:36 SHR: 03Martin.Jansa 07meta-smartphone * rcd880e03ea51 10/meta-shr/conf/distro/shr.conf: shr: drop DISTRO_SSH_DAEMON as here we're using IMAGE_FEATURES for that Jul 26 22:26:05 SHR: 03Martin.Jansa 07meta-smartphone * r3b07fac475d4 10/meta-shr/conf/distro/shr.conf: SHR: use initscripts-shr as initscripts provider, maybe convert it later to initscripts_1.0.bbappend Jul 26 22:43:14 DocScrutinizer: well, I don't know whether they actually implement the possibility to activate several use cases in parallel -- but at least from what I see in the description, there doesn't seem to be anything *preventing* this Jul 26 22:44:35 like nothing is preventing "scenarios" to be partial Jul 26 22:44:52 anyway the concept is worth absolutely nuttin Jul 26 22:45:33 and for the state changes that influence the API responses there seems to be no concept of concurrent usecases at all. Jul 26 22:46:04 Sorry I don't see anything positive coming from it, beyond control aliases/renames Jul 26 22:46:51 definitely it's not even competing (even less winning) against ACI Jul 26 22:48:53 let me put it this way: fsoaudiod could use alsaucm lib calls instead of system("amixer"), but it's highly debatable if that's any better than simple call to amixer Jul 26 22:51:09 esp since amixer is an arbitrary executable that gets fed with a script holding a path definition, and this can get replaced by sth hw platform specific any time, and I write a script for that in 10min. If fsoaudiod is using alsausmlib calls, then we're again busted with the pre brainfsck that needs a special handling Jul 26 22:52:00 DocScrutinizer: unfortunately, Mozilla nowadays seems to be all about "me too"... pretty much all recent changes in Firefox are just following Chromium (some of them good, some rather questionable...) Jul 26 22:56:10 DocScrutinizer: I don't see any point in fsoaudiod using ucm calls. rather the opposite: apps could use ucm calls to trigger state changes in fsoaudiod Jul 26 22:56:41 WTF?! Jul 26 22:56:45 admittedly that probably doesn't work with plain UCM... ACI is probably still necessary Jul 26 22:57:01 but that's just guesswork, as I don't know the details Jul 26 22:57:33 we definitely want avoid by all means to need patches to apps so they have to bother about "usecases" or "scenarios" or whatever Jul 26 22:58:08 that's the *whole* point about ACI Jul 26 22:59:02 an app opens a audio device like "hifi" or whatever, and ACI takes care about the rest Jul 26 23:00:20 and if your app is so fsckng braindamaged it only knows to open "alsa:default" the you start it via >> ALSA_ACI_DEV=hifi brainfsckdapp << Jul 26 23:01:18 NO PATCHES to make app call for a scenario or usecase or whatever! Jul 26 23:02:04 you *may* do this, if you want and need it. But you don't *need* to for normal apps that work on your desktop Jul 26 23:04:05 and ACI hooklib takes care to link the hifi device as defined in .asoundrc et al, to fsoaudiod that knows about allocation of every single control, about priorities of different requests so "hifi" vcan't snatch away speaker output from "alarm" device, etc Jul 26 23:04:14 nothing of all that is in alsaucm Jul 26 23:05:42 alsaucm is really nothing more than a abstract replacement for amixer Jul 26 23:05:51 even alsactl probably Jul 26 23:06:40 at leased judging by the webpages describing it's properties Jul 26 23:06:46 least* Jul 26 23:12:04 antrik: it's very encouraging kysela and co are aware of the problem and tried to do sth about it, but it seems ACI is way more advanced and universal and mature, by system design Jul 26 23:13:30 the concept is completely done, and needs only to get implemented (well, modulo the 5% boring stuff like exact syntax of the priority config in fsoaudiod) Jul 26 23:15:24 I admittedly haven't written a nice 18 pages whitepaper (yet?) about the concept and how it breaks down to detail. But I talked about it here just so often I think there is a decent clue how it all works, with mrmoku and some others. And if there's *any* question, just ask, I'm here several times a day Jul 26 23:45:58 DocScrutinizer: the difference is that the UCM guys actually implemented their design :-P Jul 26 23:47:14 * DocScrutinizer too Jul 26 23:47:27 like one year ago Jul 26 23:47:33 or was it 2 Jul 26 23:49:14 the true difference is the "ucm guys" have a name like kysela (or whatever), and are pushing their crap upstream Jul 26 23:51:19 while my stuff gets rejected by kysela et al, no matter if it's a better file plugin that does the *right thing* instead of acting stupid and claiming this was intentional, or anything else. We even had a hard time pushing the patch to control hook library Jul 26 23:52:54 SHR: 03Martin.Jansa 07shr-chroot * r90e3bd0769b4 10/ (27 files in 8 dirs): system upgrade Jul 26 23:52:56 try aplay -D "file:"xxx.raw" longsong.wav Jul 26 23:53:11 you'll notice file plugin is kinda weird Jul 26 23:54:11 though it has a proper slave based on a real audiocard hw with clock, it simply discards the clock and accepts samples as fast as aplay can deliver Jul 26 23:55:03 result: the above aplay command is basically a filecopy that runs for fractions of a second, no matter how long the longsong.wav Jul 26 23:55:39 commet kysela: "that's intentional - we are not interested in any alternative implementation or patch" Jul 26 23:55:54 WTF?! Jul 26 23:57:01 antrik: and now you come and tell me kysela stuff has the advantage kysela first talks about kysela stuff, rather than ACI :-S Jul 26 23:57:22 embarrasing Jul 26 23:57:33 offending even Jul 26 23:57:39 SHR: 03Martin.Jansa 07shr-chroot * r44c50dc3fe23 10/var/cache/ldconfig/aux-cache: system upgrade Jul 26 23:59:00 probably kysela seen the OM scenario botch and thought that's too embarrasing for ALSA guys so they have to come up with sth own, and possibly better Jul 26 23:59:40 just they didn't notice scenario actiually IS a botch - Harald admitted that Jul 27 00:00:43 I don't know who kysela is; but the Linux cabal is based on merit -- if he is in such a position, he definitely must have done something right. throwing up your hands and bitching about people is not helpful. if you are convinced your design is better, talk to the right people, until they understand the advantages. (hint: the right people are upstream, not downstream) Jul 27 00:00:43 iirc his words been "messehack, you know? We needed to present the thing, so we had to come up with *something*" Jul 27 00:01:19 hehe Jul 27 00:01:50 antrik: I've already done that, and if you missed it that's not my fault. It's not *me* who started "bitching" Jul 27 00:02:44 and I give no rat's ass about ALSA "upstream", for reasons already mentioned Jul 27 00:03:39 we're going to implement ACI quietly and on reasonable pace and frame, and if "upstream" is interested, they can copycat once more Jul 27 00:04:57 I'm not interested in ALSA development, I'm helping on FSO/SHR development and design Jul 27 00:04:57 why quietly? that's stupid. if you think it's better, you should talk about it at every suitable occasion Jul 27 00:05:10 pfff why? Jul 27 00:05:14 (and I mean talking to actual Linux developers, not just one downstream community) Jul 27 00:05:38 do I get paid for that? :-P Jul 27 00:06:05 am I a teeny who needs to boost his self-asteem? Jul 27 00:06:12 well, then stop bitching about Linux going with the "wrong" solution Jul 27 00:06:48 antrik: YOU started bitching about UCM being better than ACI. Please watch your rationale Jul 27 00:07:56 and obviously you like to give "ALSa upstream" a credibility bonus that's not justified. So prepare for me firing back Jul 27 00:08:05 no, I never said that. I just reacted to your criticism of UCM, which seems partly unfounded to me Jul 27 00:09:34 the missing foundation being that I'm not willing to assume things as given just because they aren't explicitly excluded form the feature set? Sound argument, indeed Jul 27 00:11:31 go buld a PoC using alsaucm for concurrent "usecases" and I'm willing to look at it and maybe re-evaluate alsaucm and its value for FSO. Until then I'm quitting this debate now. I'm not feeling like arguing with you about it Jul 27 00:15:02 btw ""you like to give "ALSa upstream" a credibility bonus"" == ""your criticism of UCM, which seems partly unfounded to me"". It's not my problem when you estimate my word less founded than a left out word of the author of http://www.slimlogic.co.uk/2009/02/alsa-use-case-manager/ Jul 27 00:16:18 anyways, my point is that you spend hours here arguing how Linux is doing it all wrong and other solutions are better, but whenever I suggest you actually talk to Linux developers about it, all you say is "not interested". quite frankly, I consider this attitude rather silly Jul 27 00:16:56 I consider YOR attitude to bitch at me about it even way more silly Jul 27 00:17:13 you started the debate, I'm ending it now Jul 27 00:17:46 fair enough Jul 27 00:37:54 mrmoku: see, you are *not* a Linux developer ;-P Jul 27 00:39:47 mrmoku: hell, why do we develop SHR? Rather whe should have started talking to winP7 developers to explain them what they could do better Jul 27 00:48:11 lol Jul 27 00:52:33 good night all Jul 27 00:59:44 [2011-07-27 01:46:31] try aplay -D "file:"xxx.raw" longsong.wav Jul 27 00:59:53 s/aplay/arecord/ Jul 27 00:59:54 DocScrutinizer meant: [2011-07-27 01:46:31] try arecord -D "file:"xxx.raw" longsong.wav Jul 27 01:00:36 breaks a nice concept to use file plugin with VoIP phne (twinkle) to playback announcement Jul 27 01:01:38 the app will take as many segments from buffer as fast as it can get, and discard all of then as they are all "buffer overruns" regarding the datarate on RTP Jul 27 01:05:14 ergo ALSA not capable of helping to build a VoIP telephone answering machine Jul 27 01:05:32 due to borked file plugin design Jul 27 02:45:05 i can haz bugs? Jul 27 02:45:10 fuckers Jul 27 02:46:00 mr DocScrutinizer can i call you from my open moko, need to check the buzz fix with bluethooth headset Jul 27 02:46:17 loelle Jul 27 02:49:48 no **** ENDING LOGGING AT Wed Jul 27 02:59:57 2011