**** BEGIN LOGGING AT Wed Jun 08 02:59:56 2011 Jun 08 04:49:47 freesmartphone.org: 03morphis 07cornucopia * rb649265e3508 10/fsogsmd/src/plugins/modem_qualcomm_palm/channel.vala: Jun 08 04:49:47 freesmartphone.org: fsogsmd: modem_qualcomm_palm: remove timeout for RESET_RADIO_IND urc messsage Jun 08 04:49:47 freesmartphone.org: It turns out that the timeout is not reliable on the device. Jun 08 05:15:50 moin Jun 08 05:21:45 moin Jun 08 05:26:05 lxsameer: duh... I misspelled you :/ Jun 08 05:42:12 moin Jun 08 05:50:21 apt: moin Jun 08 05:50:22 it has been said that moin is North German for everything you would say for salutatory, or http://moinmoin.wikiwikiweb.de/MoinMoinWiki Jun 08 05:52:50 SHR: 03Martin.Jansa 07shr-chroot * r54cc92b7a5bb 10/ (14 files in 6 dirs): bitbake: upgrade Jun 08 05:56:11 'Guten Morgen' is terribly long to spell... Jun 08 05:59:30 Also (note: may be offensive...): http://www.netfunny.com/rhf/jokes/91q3/xlatio.html Jun 08 06:00:39 Oh, apt's MoinMoinWiki link does not work any more. Jun 08 08:55:05 damn, I real fail to understand why this damn thing started to give device busy errors on incoming calls :/ Jun 08 09:09:49 pespin: yo Jun 08 09:10:03 pespin: are you really, really sure incoming calls work for you now? Jun 08 09:12:44 pespin: Give me your phone number, I'll give you a call :-) Jun 08 09:13:49 mrmoku, it worked the other day Jun 08 09:14:29 I'm going to have my hair cut now, I'll retry aftwerards Jun 08 09:15:24 bbl :) Jun 08 09:15:44 have fun :P Jun 08 11:55:21 DocScrutinizer: awake'n'around? Jun 08 11:56:52 not yet, but shoot Jun 08 11:56:57 :) Jun 08 11:57:05 I see now the misunderstanding we have Jun 08 11:57:24 what you propose is to have virtual devices representing a certain alsa route Jun 08 11:57:38 fsoaudiod concept is a bit different Jun 08 11:57:46 it's not flat Jun 08 11:57:50 on top you have modes Jun 08 11:57:58 right now there is a normal mode and a phone mode Jun 08 11:58:11 which would represent the general pcm routing and the gsm routing Jun 08 11:58:14 modes have to base on real devices Jun 08 11:58:29 and in a mode you can toggle in/output devices Jun 08 11:59:19 so the layering is: real cards / pathes / abstract devices (I mentioned mp3_stereoout_av or sth) Jun 08 11:59:46 where abstract devices are your modes Jun 08 11:59:57 almost Jun 08 12:00:12 there can be multiple abstract devices for a single mode Jun 08 12:00:19 which differ in priority Jun 08 12:00:31 exactly Jun 08 12:00:54 all buildable in ALSA rsp .amix Jun 08 12:01:21 see how ALSA device defs work Jun 08 12:01:35 those are always stacks Jun 08 12:01:43 /usr/share/alsa/cards= Jun 08 12:01:45 ? Jun 08 12:01:47 going from phy to abstract Jun 08 12:02:47 see standard def of sth like surround7.1 Jun 08 12:03:29 it merges several phy devs, plus routing plugins, softvol, split things, whatnot Jun 08 12:04:53 seems you're still thinking of fsoaduod switching "modes" behind ALSAs back, that's a wronk concept Jun 08 12:05:16 no, on mode switching fsoaudiod would apply an amix Jun 08 12:05:52 mode switching means there's some alsa audiodevice been opened or closed Jun 08 12:06:06 there are no other triggers for mode switching Jun 08 12:06:27 hmm Jun 08 12:07:35 where's that source for mode swizching on your desktop buntkuh? Aim of AIC is: maximum compatibility to a standard system Jun 08 12:07:41 that won't work for palms where morphis has no alsa devices Jun 08 12:07:59 err, why ? Jun 08 12:08:13 no alsa device no mode switch then? Jun 08 12:08:39 no alsa audio device -> no alsa audio app working Jun 08 12:09:10 right, but what I want to say is that there must be a way to switch modes without alsa device access Jun 08 12:09:13 I thought SHR is based on ALSA as audio framework Jun 08 12:09:29 what for? Jun 08 12:09:31 where we have alsa yes Jun 08 12:10:02 in fsoaudiod there are two routing plugins Jun 08 12:10:12 .amix changes ALSA controls Jun 08 12:10:21 one for alsa and one for palmpre Jun 08 12:10:28 so where's the use to implement this for a system not using ALSA Jun 08 12:10:30 ? Jun 08 12:10:35 yup, amix is done in the alsa router pluging Jun 08 12:10:37 -g Jun 08 12:10:47 but modes are a concept of the manager one level up Jun 08 12:11:39 sorry, I'm not awake enough to explain to you what been the result of my almost 2 yeras thinking about it Jun 08 12:11:54 maybe later Jun 08 12:12:03 ok, get some coffee then and let's talk later :) Jun 08 12:12:24 will continue to think meanwhile.... Jun 08 12:12:44 meanwhile you might want to provide an example usecase where your "mode switching" is needed Jun 08 12:12:59 so I get your concerns a bit better Jun 08 12:13:12 time for 12648430 ☕ Jun 08 12:13:14 indeed Jun 08 12:16:23 heh, nice one :P Jun 08 12:24:42 mrmoku: audio is a resource. So must get handled in a fsoraw way (that's what alsahook fsoaudio flavour is meant to do), no mode switching which is a system wide thing and brings hell of concurrency and apps not getting the idea of mode has changed Jun 08 12:25:35 you're not saying "we need mode switching for GPS" - so why would we need modeswitching for audio? Jun 08 12:26:09 * DocScrutinizer sips his coffee and lights up a cig Jun 08 12:30:22 * mrmoku distracted by a client wanting him to do some stuff :/ Jun 08 12:30:41 * DocScrutinizer waits for definition of a "mode" and why we need that Jun 08 12:30:52 np Jun 08 12:31:14 I would like to have morphis too for that discussion... as it's his baby Jun 08 12:33:55 in my book a "mode" is an abstract virtual audio device (NOT a soundcard!!), like your_ears_only that outputs to all soundcards that are appropriate for e.g. conducting a phonecall, some of them (like speakers) being muted by default, so it needs user interaction to unmute them Jun 08 12:34:27 this unmuting frequently and usually is done by standard ALSA means Jun 08 12:35:36 [2011-06-08 14:12:19] meanwhile you might want to provide an example usecase where your "mode switching" is needed Jun 08 12:38:55 alternatively your app (here: dialer) may want to open a clearly defined single path audio device - like headset, handset, speakerphone, which all are alsa virtual devices - do have more close and strict and seamless control over the way audio works for that particular app Jun 08 12:40:06 this obviously needs patches or sourcecode dealing with this, from GUI inside app all the way down to cloing one audiodev and opening another when user is switching to speakerphone in dialer Jun 08 12:41:10 still headset is an abstract audiodev that may route to AV-plug and BT concurrently Jun 08 12:42:27 while it would NOT route to FMTX, in contrast to e.g. media-stereo-out Jun 08 13:11:38 SHR: 03Martin.Jansa 07shr-chroot * r905a0e2b1a02 10/ (21 files in 8 dirs): bitbake: upgrade Jun 08 13:13:20 SHR: 03Martin.Jansa 07shr-chroot * rb4713aeb5243 10/ (13 files in 5 dirs): bitbake: upgrade Jun 08 13:34:20 hi, Jun 08 13:34:27 why illume is niced at -10? Jun 08 13:34:44 could we remove that (that would give us a better sound) Jun 08 13:51:18 GNUtoo: -10 is rogue madness anyway Jun 08 13:51:26 nice -3 might be sane Jun 08 13:51:35 nice sound -10 Jun 08 13:52:07 maybe -15 at max Jun 08 13:52:58 generally you should be stingy with lowering niceness Jun 08 13:53:20 less niceness doesn't mean more cpu cycles Jun 08 13:53:41 it just means all tasks with higher niceness ahve to step back Jun 08 13:53:54 like sounds Jun 08 13:54:00 result on most of my devices: Jun 08 13:54:11 scrolling with efl apps result in buffer underruns Jun 08 13:54:21 yeah, so exaggerated statement: illume:-1, sound:-2 Jun 08 13:54:31 or illume0 Jun 08 13:54:34 sound normal Jun 08 13:54:43 that worked fine Jun 08 13:54:48 sound should be less nice than GUI Jun 08 13:55:06 normal is 0 Jun 08 13:55:07 i.e. have higher prio Jun 08 13:55:38 yes but that's complicated to do Jun 08 13:55:42 niceness == 0 - priority Jun 08 13:55:54 we need to setup a group for sound etc... to renice only sound Jun 08 13:55:56 no way Jun 08 13:56:02 that's simple as milk Jun 08 13:56:24 so how do you renice sound(not a sound app but all sound apps) Jun 08 13:56:48 the only way I know is documented in the realtime audio setups Jun 08 13:56:51 you don't renice sound apps, you renice the sound daemons Jun 08 13:57:01 the apps have to deal with it Jun 08 13:58:06 generally an app might want to increase prio of just the streaming thread Jun 08 13:58:44 see, every app is a "sound app" as all hev things like notifications, ts-clicks and whatnot Jun 08 13:58:53 have* Jun 08 13:58:56 lol Jun 08 13:59:33 by sound daemon you mean fsoaudiod? Jun 08 14:00:26 if your mp3-player doesn't manage to handle fair scheduling that may cause 200ms of latency til next timeslice, you got something wrong in your player's streaming handling Jun 08 14:00:52 renicing only enlightenment works btw Jun 08 14:01:29 you should fill audio spooling buffer with several seconds worth of audio, and let "kernel" aka sound daemons deal with proper playback Jun 08 14:01:57 indeed Jun 08 14:02:12 but I was not talking about cmt_speech Jun 08 14:02:20 if you renice those root bits of audio engine less than illume, then you're screwed Jun 08 14:02:22 I was talking abuot in general Jun 08 14:02:32 for instance mplayer has buffer underruns too Jun 08 14:02:35 * DocScrutinizer too Jun 08 14:02:38 because of this -10 niceness Jun 08 14:02:48 so whaz? Jun 08 14:03:05 toldya -10 for a gui is insane Jun 08 14:03:09 so I think we have to renice enlightenment Jun 08 14:03:36 no you have to change the already existent nice -10 enlightenment Jun 08 14:03:43 yes it seemed so, so we'll have to renice it to 0 or something like that Jun 08 14:03:57 what does JaMa|Wrk think about that? Jun 08 14:04:03 I suggest -2 Jun 08 14:04:34 it's maybe not bad to give it a small prio, but for sure not 10 Jun 08 14:04:36 ok Jun 08 14:04:57 (-)10 is where system tasks start Jun 08 14:05:10 *real* system tasks Jun 08 14:05:20 lol Jun 08 14:06:17 Can anyone explain the idea behind niceness, instead of priority. I mean, I know how it works. But why don't we just have a command 'prio' Jun 08 14:06:35 The ordering of niceness seems very inverted, to me Jun 08 14:07:00 Apps that we want to run nice and smooth, have a low niceness [what?] Jun 08 14:07:18 yes Jun 08 14:07:20 like -10 Jun 08 14:07:25 on my desktop threads like events/0 and udevd have -5 Jun 08 14:07:26 Probably some historical issue, but I never found out… Jun 08 14:07:44 maybe http://en.wikipedia.org/wiki/Niceness has some clues? Jun 08 14:08:07 jocom: the word 'prio' already is used by some value that is changing dynamically Jun 08 14:08:50 ah no, it tell about where the name comes from Jun 08 14:08:53 but not the values Jun 08 14:08:57 the prio is increasing over time, also by some other parameters, and task with highest prio gets next timeslice Jun 08 14:09:00 *where do the - comes from Jun 08 14:09:28 Aha, I now understand Jun 08 14:09:40 You tell a process how nice it should be to others :) Jun 08 14:09:50 yes Jun 08 14:10:13 this is a 'statical' value, while prio changes all the time Jun 08 14:10:20 lol understood the where the - comes from Jun 08 14:10:24 thanks Jun 08 14:10:27 Thanks! Dunno why I overlooked that paragraph on wiki before. Anyway, enjoy your discussion, it was nice :) Jun 08 14:10:27 yw Jun 08 14:10:49 lol Jun 08 14:22:42 ping mrmoku Jun 08 14:30:03 btw I doubt the wikipedia is correct on distributing CPU cycles by percentage between tasks of different niceness Jun 08 14:30:23 then fix it Jun 08 14:30:38 where's mrmoku Jun 08 14:30:39 ? Jun 08 14:30:48 this might be a net result from the way scheduling works when not preemptive Jun 08 14:33:11 for all I know when two tasks are waiting, the one with lower niceness should get next timeslice always. Maybe I'm wrong, as the scheduler will increase prio(sic!) of the lower-nicemess task over time, until it also gets a timeslice even while higher-prio task is waiting for a slice as well Jun 08 14:33:47 nicemess - nice :-) Jun 08 14:35:08 tasks run at realtime scheduling (those with niceness 99 in top) will always get cpu asap Jun 08 14:35:44 ok Jun 08 14:35:58 what about CFS? Jun 08 14:37:52 GNUtoo: I'm fine with -2 niceness Jun 08 14:38:41 it's in ./e-wm/enlightenment_start.oe Jun 08 14:38:47 for really long Jun 08 14:38:58 actually current scheduler on my PC seems to support 4 flavours of scheduling: normal, stack, round-robbin, FIFO Jun 08 14:39:08 last 2 are for realtime Jun 08 14:40:04 that's very much depending on the flavour of scheduler you're running on that particular system Jun 08 14:40:34 there's not just *the one* linux scheduler, you know :-) Jun 08 14:43:05 and quite usually you're not even aware of the particular flavour of the schedular your system is using Jun 08 14:43:49 bfc waht's configured for SHR's kernel right now Jun 08 14:43:53 nfc even Jun 08 14:44:55 JaMa|Wrk, ok Jun 08 14:44:55 when it comes to things like scheduling policy for an audio process, you better know what's your scheduler though Jun 08 14:45:03 JaMa|Wrk, could you change it? Jun 08 14:45:25 I'll try to handle theses buffer underruns in fsoaudiod too Jun 08 14:46:09 I don't see how fsoaudiod is involved - unless this daemon also does direct playback of audio Jun 08 14:46:13 no, sorry, too busy at work and life now :/ Jun 08 14:47:16 if it's actually doing audio playback, then it should renice the thread handling the buffers Jun 08 14:47:31 not renice the whole daemon though Jun 08 14:49:09 usual approach: start the program fsoaudiod with -10 or whatever, and then after spawning the audiothread, the fsoaudiod main() drops niceness to 0 for the rest of threads Jun 08 14:50:06 given the *granted* fact fsoaudiod *always* runs with root perm, it also may start at niceness 0 and then rebice the audiothread to the better prio Jun 08 14:50:57 GNUtoo: you're talking about cmtspeech? Jun 08 14:52:01 DocScrutinizer, fort that : Jun 08 14:52:05 I'll try to handle theses buffer underruns in fsoaudiod too Jun 08 14:52:06 yes Jun 08 14:52:10 *for Jun 08 14:52:16 :nod: Jun 08 14:52:49 make cmtspeech a standalone program that's called by fsoaudiod Jun 08 14:53:12 buffer underrun are not even handled by it Jun 08 14:53:16 the clean way to deal with that Jun 08 14:53:22 that is to say we do writei Jun 08 14:53:23 and that's all Jun 08 14:53:31 ok, but mickeyl won't be ok with that Jun 08 14:53:38 why not? Jun 08 14:53:53 he likes integration, before it was a standalone program Jun 08 14:53:57 and it got integrated Jun 08 14:53:59 :-/ Jun 08 14:54:16 you see where that gets you at Jun 08 14:54:27 hmmm Jun 08 14:54:32 the problem is that: Jun 08 14:54:39 *enlightenment is currently at -10 Jun 08 14:54:57 *we don't handle buffer underruns, that should be handled Jun 08 14:55:02 enlightenment is really irrelevant for this stuff Jun 08 14:55:06 I've to work on it, right now if possible Jun 08 14:55:33 enlightenment creates buffer underruns for everything, from mplayer to fsoaudiod cmtspeech alsa backend Jun 08 14:55:47 thare can and will be arbitrary processes on your machine running at -10 or whatever Jun 08 14:55:49 I guess buffer underruns are not good for audio quality Jun 08 14:56:25 let's try to make something good instead of perfect Jun 08 14:56:43 for now the priority is to handle theses buffer underruns Jun 08 14:57:08 you need to clean up your audio setup and audio apps, not your $RANDOM app on system running at renice -10 Jun 08 14:58:37 when you got code showing problems under a certain environment, you fix the code, never the environment Jun 08 15:01:39 I prefer to fix both Jun 08 15:02:31 and cmtspeech is a autonomous function that's not related to fso in any way whatsoever, so it *has* to become a autonomous program according to my design rules - of course fsoaudiod is free to call this program and closely monitor it, so it doesn't show up as a separate task in ps, rather becomes a thread under fsoaudiod. That's just enough of integration to make everybody happy I'd say Jun 08 15:02:56 ahh good idea Jun 08 15:03:21 GNUtoo: you can not, by definition, fix an environment, as it's what the user is creating by using the system Jun 08 15:03:36 for now the priority is to handle theses buffer underruns Jun 08 15:03:40 I mean fix in the code Jun 08 15:03:42 *meant Jun 08 15:04:00 I'm setting up the sshfs environment for working on it right now Jun 08 15:05:16 you could fix the renice kerenl function to forbid -10 for everything not on your whitelist, but that's a really kinky approach Jun 08 15:06:20 there are 2 problems not one Jun 08 15:06:21 other than that, your app has to live in an environment where other devels might want to run their app at -10 as well - thaz's what I meant with "you can not fix the environment" Jun 08 15:06:31 1) all apps do buffer underruns Jun 08 15:06:45 fix 1) in alsa Jun 08 15:06:47 2) my alsa backend doesn't handle buffer underruns Jun 08 15:07:00 fixes 2) as well Jun 08 15:07:01 1) not possible to fix in alsa Jun 08 15:07:11 2) I'm working on it right now Jun 08 15:07:23 but I cannot talk at the same time Jun 08 15:08:53 there's akernel land soundcard driver of alsa, which needs realtime scheduling so there are no timing issues there. The rest is a question of your apps and their proper usage of buffering Jun 08 15:11:29 plus if a particular app is doing audio, and you face occasional buffer underruns as another task of same niceness eats up too much of cpu power, you either need a faster CPU, or lower niceness for this particular app - given your app already is using buffer size of maximum reasonable size Jun 08 15:11:55 that's the whole idea behind audio buffering Jun 08 15:12:35 allow your task to sleep for some time, while kernel deals with streaming out the buffer to the soundcard Jun 08 15:15:34 linux isn't a veritable RT system, so your app SHOULD NOT assume it's running (getting CPU cycles) at any given rate faster than maybe 1/s Jun 08 15:15:37 ~2119 Jun 08 15:15:38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Jun 08 15:16:05 ok Jun 08 15:16:49 for cmtspeech you clearly would need realtime scheduling, which most probably your scheduler can support on SHR Jun 08 15:17:59 otoh you for sure don't want to run fsoaudiod en todo at RT scheduling Jun 08 15:19:15 so here you are: make cmtspeech a standalone process that can get RT scheduling and is run under whatever supervision at your discretion, probably spawned by fsoaudiod Jun 08 15:20:44 most clean way to implement this: makre cmtspeech a *program* and start that program from fsoaudiod Jun 08 15:25:29 mrmoku, incoming NOT working, outgoing working Jun 08 15:25:41 probably SUID cmtspeech and take care about changing/rising scheduling prio (and policy, to RT) inside cmtspeech itself Jun 08 15:25:50 I thought both worked, but could be due to being late hehe Jun 08 15:26:57 as for cmtspeed the scheduling is a part of the process requirements, not an issue dealt with by distro maintainers Jun 08 15:28:12 mrmoku, I don't know if this is realated, but I have this in fsoaudiod.log: [ERROR] RouterLibAlsa <>: Could not switch to new mode FREE_SMARTPHONE_AUDIO_MODE_NORMAL; switching back to old mode FREE_SMARTP Jun 08 15:28:13 HONE_AUDIO_MODE_NORMAL ... Jun 08 15:31:23 *cough* Jun 08 15:32:03 * DocScrutinizer wonders what's FREE_SMARTPHONE_AUDIO_MODE_NORMAL and why we need to switch it Jun 08 15:32:09 * DocScrutinizer giggles Jun 08 15:32:49 isn't MODE just another word for scenario? Jun 08 15:33:15 didn't we agree on sceanrios being an obsolete broken-by-design concept? Jun 08 15:34:08 I bet there's also a FREE_SMARTPHONE_AUDIO_MODE_GSM-HANDSET Jun 08 15:35:16 calling scenarios MODEs now doen't really fix the issues with the whole scenario concept Jun 08 15:35:40 there's no ALSA outside ALSA Jun 08 15:35:57 there's for sure no super-ALSA Jun 08 15:36:26 even if you might like to name it fsosuper-ALSA Jun 08 15:37:14 ACI is about ALSA controlling fsoaudiod, not other way round Jun 08 15:40:40 rationale: each generic audio app knows about ALSA (though some know better, others less) - NO generic app knows about fso Jun 08 15:42:11 ALSA knows about its own (real and virtual) devices, and also about controls, and with ACI also knows about fsoaduiod (as well as arbitrary other supplemetary support stuff) Jun 08 15:42:32 what exactly is it fsoaudiod is supposed to know about best? Jun 08 15:42:58 exactly: about arbiting Jun 08 15:43:34 nothing else, just about arbiting audio resources in a slightly smarter way than ALSA standalone could do Jun 08 15:46:24 it gets to know from ALSA and ACI extensions about existing ALSA resources and about how to assign them and reolve conflicts Jun 08 15:58:07 gah Jun 08 15:58:09 ~lart php Jun 08 15:58:10 * apt whips out a shotgun, trudges over to php, and goes postal Jun 08 15:58:24 GNUtoo: pong Jun 08 15:58:50 pespin: no it's not related... I even tried with fsoaudiod removed Jun 08 15:58:51 mrmoku, hi Jun 08 15:59:17 I even tried the default asound.conf Jun 08 15:59:24 I'm out of ideas Jun 08 16:00:26 mrmoku, volume sliders and scenarios don't work for me on n900, I tough you fixed that? Jun 08 16:00:45 fresh image from some hours ago Jun 08 16:03:26 GNUtoo: no, did not fix the scenarios Jun 08 16:03:33 ah Jun 08 16:05:38 DocScrutinizer: there is just _two_ modes Jun 08 16:05:44 normal and phone Jun 08 16:05:58 ~seen morphis Jun 08 16:06:11 morphis <~morphis@hfw-ext-wlan.rz.hs-bremen.de> was last seen on IRC in channel #openmoko-cdevel, 1d 4h 55s ago, saying: 'mrmoku: why we can't use the already available scenario files for the om-gta02?'. Jun 08 16:06:23 hehe Jun 08 16:08:10 DocScrutinizer: how does the amix way work to *disable* a route? For example you turn on the speaker in addition to the headset... and then want to turn off the speaker? Jun 08 16:10:30 usually you just slide down the volume again, as you did by sliding up before Jun 08 16:11:42 if you're talking about concurrent compatible pathes - my spec said "on closing a path fsoaudiod shall revert all controls to the state they had before it got established" Jun 08 16:12:34 for the controls used by both paths there's no problem as the control been on same value before path got established Jun 08 16:12:51 so no change on tearing down this particular path Jun 08 16:13:31 do all paths have their individual volume control? Jun 08 16:13:56 tearing down N-1th path down is a *bit* tricky, as you'd need to inherit your own stacked-up value to the path coming after you Jun 08 16:14:00 IIRC my experiments on gta02 yesterday the were partly shared Jun 08 16:14:33 yeah, remember state of the changed controls when applying an amix Jun 08 16:14:54 mrmoku: that depends on definition of the path. For softvolume they are free to reuse existing ones, or create own ones Jun 08 16:15:38 hmm... you mean we should (could) create softvols for all output paths and use those? Jun 08 16:16:04 yes Jun 08 16:16:19 could, no idea baout the should part Jun 08 16:16:22 depends Jun 08 16:17:16 that all will not workout for morphis on palm where he has to use 'kernel scripts' to do the routing :/ Jun 08 16:17:38 usually one path has multiple (soft)vols, like "akme mp3player", "music", and "speaker volume" Jun 08 16:18:18 hmm... regarding the device busy problem... maybe that could be kernel related? Jun 08 16:18:38 (kernel scripts) where's the dif between a kernel script and a .amix file? Jun 08 16:18:48 moment Jun 08 16:20:22 DocScrutinizer: http://git.freesmartphone.org/?p=cornucopia.git;a=blob;f=fsoaudiod/src/plugins/router_palmpre/plugin.vala;h=d7e590119f0b9a2ca25877447c081a979d2edc90;hb=b649265e3508fdedda90c9b1e01f550900c75afc#l94 Jun 08 16:20:41 * mrmoku being called for dinner Jun 08 16:20:43 bbl Jun 08 16:23:44 mrmoku: hmm, I'm not really inclined to read the whole source. I wonder if I should bang together a draft about ACI, hooklib, fsoaudiod and the way it works internally... Jun 08 16:29:59 hi there, is wifi working on palm pre? if yes, can you point me somewhere how to enable it? Jun 08 16:41:19 I've some strange issue, I cannot make fsoaudiod stop, I have music,a blender movie demo I touch the screen....but it seem to be mostly rock solid Jun 08 16:41:27 not sure if it will stay at next boot Jun 08 16:41:58 in vala the errors are also negative Jun 08 16:42:09 you have to do -Posix.EPIPE Jun 08 16:42:11 like in C Jun 08 16:42:15 that was my error Jun 08 16:53:49 hmmm Jun 08 16:53:50 http://www.pastie.org/2038507 Jun 08 16:54:12 maybe I should release the buffer anyway when there is an error Jun 08 16:54:20 *EPIPE buffer underrun error Jun 08 16:57:16 GNUtoo: hi there Jun 08 16:57:22 'hi Jun 08 16:57:47 GNUtoo: how long does it take for a patch to find a way into main stream of fso ? Jun 08 16:58:02 not so long if someone looks at it Jun 08 16:58:12 I didn't have the time to look at it, sorry Jun 08 16:59:02 GNUtoo: ;) Jun 08 16:59:41 lxsameer: got mail meanwhile? Jun 08 17:00:12 mrmoku: yeah but it seems that my account already activated Jun 08 17:00:20 mrmoku: but i don't have the password Jun 08 17:03:58 lxsameer: it's not the one I gave you? Jun 08 17:04:10 mrmoku: no Jun 08 17:05:09 lxsameer: retry please Jun 08 17:05:18 mrmoku: sure Jun 08 17:05:32 I have set it again now Jun 08 17:05:52 mrmoku what was the pass Jun 08 17:06:11 mrmoku, I think most of the buffer underruns were due to debug statements Jun 08 17:06:15 not all tough Jun 08 17:06:19 I handle the rest it seems Jun 08 17:06:30 GNUtoo: great thing :) Jun 08 17:06:42 mrmoku: Notice: An email has been sent to lxsameer@gnu.org with a token to verify your new email address Jun 08 17:07:57 gah, damn trac :/ Jun 08 17:08:22 under ultra high load tough it doesn't work Jun 08 17:08:27 like 100% CPU usage Jun 08 17:08:33 10 mplayer instances Jun 08 17:08:35 or more Jun 08 17:08:39 running videos Jun 08 17:08:42 :P Jun 08 17:09:00 maybe I don't handle it the best way possible Jun 08 17:09:10 so what should we do? Jun 08 17:09:17 we remove the DEBUG stuff in the config ? Jun 08 17:09:30 I guess we keep them in the code,right? Jun 08 17:10:46 yup Jun 08 17:11:17 DocScrutinizer: IIRC palm has alsa... just not for routing Jun 08 17:11:40 so we could probably find a common thing Jun 08 17:31:48 mrmoku: not for routing means ALSA doesn't provide a mixer API on palm? Jun 08 17:31:49 wow....seem rock solid with snd_pcm_recover now Jun 08 17:31:54 will try with the debug again Jun 08 17:32:16 there is 4 mplayer running at the same time Jun 08 17:32:20 with screen Jun 08 17:32:23 and it still work Jun 08 17:32:50 and it's not music, it's an encoded blender trailer Jun 08 17:34:01 at 250 Mhz btw Jun 08 17:34:32 I'll push then Jun 08 17:38:38 genno URL to finally get some code review? Not interested? Jun 08 17:39:13 genno? Jun 08 17:39:13 gen... Jun 08 17:39:26 meh Jun 08 17:39:26 I think I got that covered Jun 08 17:39:28 GNUtoo: Jun 08 17:39:31 with the whitespace plugin Jun 08 17:39:54 can I push Jun 08 17:40:01 or do I really need a review? Jun 08 17:40:03 GNUtoo: no URL to finally get some code review? Not interested? Jun 08 17:40:13 dunno Jun 08 17:40:20 Just an offer Jun 08 17:40:23 the problem is that the code is on my laptop Jun 08 17:40:31 trough ssh Jun 08 17:40:41 I've to format patch scp etc... Jun 08 17:41:18 as I probably could've pointed you to the snd_pcm_recover and other bits Jun 08 17:41:19 or maybe you could review it after Jun 08 17:41:28 I knew snd_pcm_recover Jun 08 17:41:37 only that I was too lazy to use it yet Jun 08 17:42:13 laziness not a good foundation paradigm for developing proper new stuff Jun 08 17:42:28 I meant that I wanted something working first Jun 08 17:42:31 and to fix after Jun 08 17:42:44 * DocScrutinizer shakes head Jun 08 17:42:47