**** BEGIN LOGGING AT Thu Jun 09 02:59:57 2011 Jun 09 04:02:14 freesmartphone.org: 03morphis 07cornucopia * r7fe6a120f3c4 10/fsogsmd/src/plugins/modem_qualcomm_palm/channel.vala: fsogsmd: modem_qualcomm_palm: be more verbose in error case within channel opening Jun 09 04:47:36 freesmartphone.org: 03morphis 07cornucopia * rac401f272ba4 10/fsogsmd/src/plugins/modem_qualcomm_palm/channel.vala: fsogsmd: modem_qualcomm_palm: use plain sleep again as otherwise it does not work probably Jun 09 04:56:21 freesmartphone.org: 03morphis 07cornucopia * ra7672fadf0eb 10/fsogsmd/src/plugins/modem_qualcomm_palm/channel.vala: fsogsmd: modem_qualcomm_palm: add missing posix namespace name Jun 09 05:23:30 moin Jun 09 05:29:26 moin Jun 09 05:29:44 and night Jun 09 05:30:14 :) Jun 09 05:36:37 put on yout tin foil hats! Solar storms approaching Jun 09 05:38:35 mrmoku: look out for aurora, might be visible in Bavaria Jun 09 05:38:44 hehe Jun 09 05:38:57 no kidding Jun 09 05:39:04 I can already see it http://git.freesmartphone.org/?p=aurora.git;a=summary ;) Jun 09 05:39:13 hehe Jun 09 05:39:20 DocScrutinizer: yeah, heard that too Jun 09 05:40:08 funny part is we're down south enough to see it - more to the north night is not dark enough ;-P Jun 09 05:48:07 hmm... that looks wrong Jun 09 05:48:08 catch ( SpawnError e ) Jun 09 05:48:08 { Jun 09 05:48:08 warning( @"Can't spawn aplay: $(strerror(errno))" ); Jun 09 05:48:09 throw new FreeSmartphone.Device.AudioError.PLAYER_ERROR( "Can't play song %s: %s".printf( name, Alsa.strerror( res ) ) ); Jun 09 05:48:51 catching SpawnError and using Alsa.strerror ... Jun 09 05:49:33 umm Jun 09 05:50:32 not that the rest of it looked any sane to me Jun 09 05:51:46 I would have thought that using aplay is something you'd consider sane :) Jun 09 05:52:21 I'm getting nausea on throw new foo.bar.boo Jun 09 05:53:04 couldn't this critter throw with old rocks at least? Jun 09 05:53:49 * DocScrutinizer obviously is no OO-man Jun 09 05:54:50 the whole syntax looks bewildering Jun 09 05:55:13 warning( @" WTF?! Jun 09 05:55:51 $(strerror Jun 09 05:56:05 * DocScrutinizer starts to feel sick Jun 09 05:57:16 gues that's this vala thing Jun 09 05:57:46 or maybe a weird mix of bash, java, and c# ? Jun 09 05:58:44 I don't know java and c# Jun 09 05:58:52 but I started to actually like the vala syntax Jun 09 05:59:11 help me out, why was fso-2 written in vala again? Jun 09 05:59:28 because python sucks when it comes to speed at least Jun 09 05:59:53 well yeah, that is more the reasons why it got rewritten Jun 09 05:59:58 so that's an argument for assembler as well ;-P Jun 09 06:00:04 not why it was rewritten in vala Jun 09 06:00:45 at least assembler wouldn't cause this slightly sick nausea feeling in my guts Jun 09 06:00:47 DocScrutinizer: what would you have choosen? Jun 09 06:00:57 nah Jun 09 06:01:23 and dont' tell me assembler because I would not believe you ;) Jun 09 06:01:37 tbh? C, as it's a good label to stick on the box, no other reason Jun 09 06:01:58 that's the point Jun 09 06:02:14 vala is C in the end Jun 09 06:02:34 I honestly doubt anybody dares to touch FSO-2 for that vala bit Jun 09 06:02:35 and as mickey|office is not a fluent C programm choosing plain C was not an option for him Jun 09 06:03:14 DocScrutinizer: that's not true... Gnutoo touches it... I touch it... dos1 touches it... morphis completely dived into it... playya_ is into it Jun 09 06:03:30 you well got my point though Jun 09 06:03:40 sure Jun 09 06:03:51 for example TAsn won't touch it :P Jun 09 06:04:02 as he's a stubborn C-only man ;) Jun 09 06:04:14 and I can't sell this stuff to e.g. meego Jun 09 06:04:25 but if you look at it from the pov of who did most of the work Jun 09 06:04:32 vala was quite a logical decision Jun 09 06:04:42 hmm Jun 09 06:04:45 maybe, no clue about that Jun 09 06:04:53 not even a clue about vala Jun 09 06:05:19 but it's hard to get anybody even look at the sources, if only to demonstrate how kevents work Jun 09 06:06:50 it's always hard to make somebody look at (and understand) sources in a language he/she does not know Jun 09 06:06:56 I have NFC what warning( @"Can't spawn aplay: $(strerror(errno))" ); really is meant to do Jun 09 06:07:24 for example I'm having an even harder time to understan some python code... even though I did some very light-weight python programing already Jun 09 06:08:10 sure, when it was for me and my way, linux was written in modula Jun 09 06:08:17 DocScrutinizer: and it's not that we have a bunch of volunteers for SHR C-Code waiting for tasks to be given btw. Jun 09 06:09:18 maybe you had a few more when it was in C Jun 09 06:44:44 moin Jun 09 06:46:00 moin JaMa|Wrk Jun 09 06:48:38 * JaMa|Wrk has almost all stuff packed Jun 09 06:48:50 only pc is still connected and ap on Jun 09 06:53:43 JaMa|Wrk: from when to when will you be gone? Jun 09 07:01:46 I still dont have connection at home (and keys from roof) so maybe from tomorrow to 18 July Jun 09 07:05:56 ok Jun 09 07:27:33 * mrmoku off to a client Jun 09 08:01:15 SHR: 03Martin.Jansa 07shr-chroot * r2ddd39f8c5d9 10/ (16 files in 8 dirs): bitbake: upgrade Jun 09 08:05:41 SHR: 03Martin.Jansa 07shr-chroot * r12a95daabbab 10/ (16 files in 8 dirs): bitbake: add patch persist_data: Add back code to retry in the case of locked database errors Jun 09 08:54:17 hi I cannot bitbake fsodeviced on shr-unstable with chroot http://paste.pocoo.org/show/403306/ Jun 09 09:01:40 using fso-autorev? Jun 09 09:02:51 because there should be b7e1c25ae69d249e7f0fb3de1f8adc4ca58149e5 SRCREV.. Jun 09 09:36:30 SHR: 03Martin.Jansa 07meta-smartphone * re332258bcd9c 10/meta-shr/conf/distro/include/preferred-shr-versions.inc: preferred-shr-versions: set SRCREV_pn-gobject-introspection* Jun 09 09:43:37 No not using fso-aurorev. Sorry to answer so late suffered an RL interrup and after that I had to be sure of the answer Jun 09 10:33:00 jluis: as is it oe HEAD? Jun 09 10:34:08 jluis: you don't have this commit http://git.openembedded.org/cgit.cgi/openembedded/commit/recipes/freesmartphone/cornucopia.inc?id=5c43457a77b279a996b737efbc2f3d9a77f1e7a1 Jun 09 10:35:36 jluis: so you're missing incompatible vala and cornucopia versions and you need http://git.freesmartphone.org/?p=cornucopia.git;a=commit;h=319253c5e91067544ebefc8028ca2d764037eae8 Jun 09 10:48:09 JaMa|Wrk,I have compiled it afrer upgrading openembedded and shr-unstable and checking the commit in cornucopia.inc Jun 09 10:48:59 surelly my previous make update missed some commits :/ Jun 09 14:59:06 hi GNUtoo Jun 09 14:59:24 hi Jun 09 14:59:31 I made many phone calls today Jun 09 14:59:36 it seem better than yesterday Jun 09 14:59:50 you know alsa better than me... when does it error with device busy? Jun 09 14:59:50 still some little buffer underrun but they are handled Jun 09 14:59:53 great Jun 09 14:59:58 no idea Jun 09 15:00:02 I need more context Jun 09 15:00:06 gta02 Jun 09 15:00:12 incoming call Jun 09 15:00:16 ah? Jun 09 15:00:19 you press accept Jun 09 15:00:24 ok Jun 09 15:00:28 where do you get that? Jun 09 15:00:33 and fsodeviced gets device busy from alsa when it tries to set the mixer Jun 09 15:00:35 for gsm Jun 09 15:00:53 I don't know well the control API Jun 09 15:00:57 ok Jun 09 15:00:59 but I know the PCM API Jun 09 15:01:27 * GNUtoo is already using the n900 as daily phone now Jun 09 15:01:33 very nice :-) Jun 09 15:01:35 * GNUtoo needs to import his contacts Jun 09 15:01:55 note that I do not make intensive use of phone calls Jun 09 15:02:05 I do not call often Jun 09 15:03:03 doc may have some hints, also look at twinkle alsa backend Jun 09 15:03:40 I would have thought the control api is not blocking Jun 09 15:04:16 where is the details? Jun 09 15:04:17 *are Jun 09 15:04:23 do you have the log? Jun 09 15:04:45 hmmm Jun 09 15:04:49 could it be the PCM Jun 09 15:04:59 and not the control API? Jun 09 15:05:12 device.setAllMixerControls( allscenarios[scenario].controls ); Jun 09 15:05:12 like you have a ringtone that occupy the card Jun 09 15:05:25 is clearly control... and there I get the exception Jun 09 15:05:28 /var/log/fsoaudiod.log says what exactly Jun 09 15:05:30 device or resource busy Jun 09 15:05:36 ok Jun 09 15:05:37 fsodeviced.log Jun 09 15:05:41 but exact line? Jun 09 15:06:01 2011-06-08T17:18:03.623657Z [WARN] fsodeviced : Failed to update scenario 'gsmhandset' to get changes: Device or resource busy Jun 09 15:06:09 ok Jun 09 15:06:18 let me look Jun 09 15:06:36 var res = card.elem_write( control.value ); Jun 09 15:06:36 if ( res < 0 ) Jun 09 15:06:36 throw new SoundError.DEVICE_ERROR( "%s".printf( Alsa.strerror( res ) ) ); Jun 09 15:06:42 is the part that throws the exception Jun 09 15:06:48 #define EBUSY 16 /* Device or resource busy */ Jun 09 15:06:57 strace it Jun 09 15:07:06 ok, moment Jun 09 15:07:06 don't forget the -f Jun 09 15:07:15 I can decode ioctls Jun 09 15:07:53 ok... have to build it for gta02 Jun 09 15:07:58 ok Jun 09 15:20:42 GNUtoo: gah... under strace it works :/ Jun 09 15:21:01 ~lart timing issues Jun 09 15:21:01 * apt puts timing issues into a headlock and administers a mighty noogie, rubbing half of timing issues's hair of Jun 09 15:21:02 timing issues then Jun 09 15:21:05 :) Jun 09 15:21:16 then maybe retry Jun 09 15:21:18 that is to say Jun 09 15:21:22 catch error Jun 09 15:21:25 goto retry Jun 09 15:21:36 but only retry a certain number of time Jun 09 15:21:39 or something like that Jun 09 15:21:40 I tried that... did a loop and retried 5 times Jun 09 15:21:50 without waiting though Jun 09 15:21:50 and? Jun 09 15:21:53 and all 5 tries fail Jun 09 15:21:55 ah ok Jun 09 15:22:01 exponential backoff? Jun 09 15:22:06 like in networking Jun 09 15:22:18 ? Jun 09 15:22:55 btw. Jun 09 15:22:55 underrun!!! (at least 1317.742 ms long) Jun 09 15:23:00 n900? Jun 09 15:23:04 gta02 Jun 09 15:23:07 ok Jun 09 15:23:13 output of fsodeviced I saw under strace Jun 09 15:23:17 ok Jun 09 15:23:18 while playing the ringtone Jun 09 15:23:20 ok Jun 09 15:23:23 SHR: 03Martin.Jansa 07meta-smartphone * rf37d05ca7450 10/meta-nokia/recipes-bsp/udev/ (6 files in 2 dirs): meta-nokia: drop udev bbappend now when devtmpfs is preferred Jun 09 15:23:25 * mrmoku changes the nice -10 Jun 09 15:23:36 lol Jun 09 15:23:49 maybe change the nice of aplay instead Jun 09 15:23:51 anyway Jun 09 15:24:00 exponential backoff is for retries Jun 09 15:24:06 each time you retry Jun 09 15:24:09 you sleep longer Jun 09 15:24:16 like **2 Jun 09 15:24:16 ok Jun 09 15:24:33 I think it was in the ethernet protocol Jun 09 15:24:37 for handling collisions Jun 09 15:34:41 GNUtoo: don't think so... ethernet has random retry AFAIK. many other protocols use exponential though -- typical SMTP daemon settings for example Jun 09 15:34:59 yes it's random Jun 09 15:35:10 but there is also an exponential backoff in the randomness Jun 09 15:35:55 In Ethernet networks, the algorithm is commonly used to schedule retransmissions after collisions. Jun 09 15:35:59 http://en.wikipedia.org/wiki/Exponential_backoff Jun 09 15:36:38 basically you increase the number of slots Jun 09 15:36:45 I see Jun 09 15:36:48 and choosing the slot is random Jun 09 15:37:00 slot is in time Jun 09 15:37:35 * mrmoku won't get *that* complicated ;) Jun 09 15:38:09 anyways, I don't think that would be a good idea here. even if it helped, it would only kludge around the issue, rather than finding and fixing it... Jun 09 15:39:06 it's simple Jun 09 15:39:12 sleep += foo Jun 09 15:39:12 righto, but we want to switch to fsoaudiod anyway and that would at least give people back a working phone meanwhile Jun 09 15:39:28 Posix.usleep( 10 ^ retry_count ); Jun 09 15:39:32 is what I'm trying now Jun 09 15:42:26 mrmoku: found your "device busy" reason now? Jun 09 15:42:34 * DocScrutinizer reads backscroll Jun 09 15:43:17 DocScrutinizer: no :/ Jun 09 15:43:54 hmm Jun 09 15:44:03 switching to speaker and back makes it work it seems Jun 09 15:44:29 DocScrutinizer: is the alsa control api blocking on simul access like the pcm one? Jun 09 15:44:59 hmm... I doubt that's the problem.. Jun 09 15:45:11 mrmoku, maybe try simplier userspace tests: Jun 09 15:45:14 GNUtoo: did not help with 10 retries Jun 09 15:45:20 like many concurent alsactl -f foo restore Jun 09 15:45:44 try to see if fsoaudiod openning something already blocks it Jun 09 15:45:55 or try with lsof, proc/pid/fd Jun 09 15:46:11 mrmoku: (block) dunno, I guess you can select this by some parameter bits on open(), as usual Jun 09 15:46:14 how can you try without receiving a call? Jun 09 15:47:11 mrmoku: see hooks "manpage", there's an option to lock controls Jun 09 15:48:27 ok Jun 09 15:48:57 so I guess you can choose on a function-call level whether to lock or not Jun 09 15:49:46 for snd_pcm_open() there's BLOCK / NONBLOCK iirc Jun 09 15:49:59 expect to see same for ctrl Jun 09 15:50:34 I toldya yesterday I suspect a race ;-) Jun 09 15:51:06 check the ringtone-player code Jun 09 15:52:06 I'd not be surprised to find it using its own ctrl interface implementation and opening ctrl in BLOCK mode Jun 09 15:52:15 DocScrutinizer: ringtone player is spawning aplay Jun 09 15:52:33 that's unrelated, aplay doesn't access ctrl Jun 09 15:52:48 indeed Jun 09 15:53:03 it's about how ringtone-player is doing scenario switching Jun 09 15:53:11 that's why I fail to understand it is ringtone related Jun 09 15:53:22 it does nor Jun 09 15:53:25 not Jun 09 15:53:34 duh, what?!? Jun 09 15:53:55 hmm Jun 09 15:54:15 will check in 5min when bacto kbdk Jun 09 15:54:38 touchpad? Jun 09 15:54:45 I hate it when that happens Jun 09 15:55:47 meh, maybe just a cursor-left typo Jun 09 15:56:08 left instead of space Jun 09 16:00:13 kbd :) Jun 09 16:00:25 well n900 has a kbd too Jun 09 16:00:41 but I can't check fso code here Jun 09 16:14:55 DocScrutinizer: it does not change the controls on incoming calls for the ringtone :P Jun 09 16:22:18 gah, alsa api docs are sooo extensive :P Jun 09 16:26:00 2011-06-09T03:06:35.018474Z [DEBUG] fsodeviced : elem_write( 50:'DAI Mode':1:0 ) card=neo1973gta02 Jun 09 16:26:07 that's the control that fails Jun 09 16:27:12 * mrmoku dinner Jun 09 16:29:45 is there a trick to building 2.6.39 in chroot build env? bitbake linux-2.6.39 still tries to build 2.6.37 in shr-unstable for me Jun 09 16:30:28 jeepingben: bitbake linux-openmoko-2.6.39 Jun 09 16:30:41 thanks Jun 09 16:30:51 but it will mess with your feeds Jun 09 16:31:21 ie 2.6.37 modules will be removed from your installed image with next opkg upgrade Jun 09 16:31:50 thats ok, I'll be working on my testing FR, so it isnt a problem to start over Jun 09 16:31:57 ok Jun 09 16:33:18 captainigloo, ^^^ JaMa|Off is not Off Jun 09 16:34:06 JaMa|Off, hi Jun 09 16:34:10 hi.. Jun 09 16:34:22 could you(when you have the time) change the niceness of enlightenment Jun 09 16:34:23 mrmoku: ok, that's a decent clue Jun 09 16:34:23 not really off yet, but leaving soon (waiting only for test build) Jun 09 16:34:39 like from -10 to -2 or to 0 Jun 09 16:34:47 GNUtoo: I'll be without home workstation online since tomorrow.. Jun 09 16:34:53 -2 is ok according to DocScrutinizer Jun 09 16:35:05 mrmoku: I think the bug in wm8753 driver been exactly about setting DAI mode Jun 09 16:35:13 JaMa|Off, until when? Jun 09 16:35:17 GNUtoo: I've seen it here yesterday.. but really no time to do it now Jun 09 16:35:28 when will you have the time Jun 09 16:35:35 because I've no time either to do it right now Jun 09 16:35:36 GNUtoo: 1,5 month .. returning 17-18 July Jun 09 16:35:44 ouch Jun 09 16:35:45 ok Jun 09 16:36:00 I guess mrmoku or me will have to do it then Jun 09 16:36:58 maybe I'll get connection before leaving to US.. but it's not sure Jun 09 16:37:02 have a good offline time Jun 09 16:37:06 thanks Jun 09 16:37:12 vacations? Jun 09 16:37:48 or move to the US Jun 09 16:37:56 vacations after 24.6. but before that I have to finish flat and stupid dayjob project.. Jun 09 16:38:01 ok Jun 09 16:49:43 PaulFertser: DAI mode anything? Jun 09 16:49:51 DocScrutinizer: ahem? Jun 09 16:50:07 * PaulFertser needs to read the backlog. Jun 09 16:50:10 PaulFertser: I seem to recall there's been some bug in driver for wm8753? Jun 09 16:50:24 DocScrutinizer: not DAI related. Jun 09 16:50:28 oh Jun 09 16:50:47 DocScrutinizer: the bug was with some powersaving that resulted in necessity to set some parameter twice for gsm<->bluetooth communication. Jun 09 16:50:48 I'm pretty sure we had problems with DAI switching before Jun 09 16:51:20 like switching DAI freezes driver, or sth Jun 09 16:51:50 kills the kernel Jun 09 17:00:40 PaulFertser: I also recall that twiddle-some-ctrl thing that was related to wolfson's magic handling the powersaving based on guesswork about the audio path used Jun 09 17:01:28 tbh I always thought this magic is completely ill placed in a kernel driver Jun 09 17:02:51 in my book it's clearly a high level management "heuristics" that would usually go to userland and interface the chip via some proper API Jun 09 17:04:16 DocScrutinizer: well, if something can easily be deduced by the kernel driver, why not get it there? Jun 09 17:04:42 as this clearly fails the definition of "easily" :-) Jun 09 17:04:50 DocScrutinizer: most probably it was a bug in the driver not properly establishing some relationship between controls. Or some minor omission in API worth fixing. Jun 09 17:05:03 I have never really investigated it, unfortunately. Jun 09 17:05:50 DAI switching could kill the kernel but i'm not sure if that bug is still there. I think when i started i fixed at least one of that kind. Jun 09 17:05:56 PaulFertser: the driver has to deduce about needed function blocks based on what we tell it about value of some mux and other controls Jun 09 17:06:51 this implies the driver is at least as smart as I am ;-P Jun 09 17:06:52 DocScrutinizer: i kinda trust the ASoC folks as they have clearly seen more different devices than me and have quite some kernel hacking experience. I think their framework is mostly correct. Jun 09 17:07:25 indeed it may be mostly correct, but I question the basic concept Jun 09 17:08:11 which, for all I know, been around the mantra of "drivers have no intelligence, they export as basic a control of the hw as possible" OWTTE Jun 09 17:09:48 also violates the best practice requirement of drivers exporting a most comprehensive control to API Jun 09 17:10:14 well, alas a lot of drivers violate that rule Jun 09 17:10:47 and always it bites your ass sooner or later Jun 09 17:12:01 freesmartphone.org: 03morphis 07msmcomm * r36ccf1dae335 10/libmsmcomm/README: libmsmcomm: reformat README file Jun 09 17:12:01 freesmartphone.org: 03morphis 07msmcomm * r0b5cf09d6bee 10/libmsmcomm/msmcomm/ (messagedisassembler.vala pdsmmessagegroup.vala): libmsmcomm: activate pdsm messages group for disassembling Jun 09 17:12:01 freesmartphone.org: 03morphis 07msmcomm * r5d938164dfc8 10/libmsmcomm/ (4 files in 4 dirs): libmsmcomm: fix typo in pdsm structure definitions Jun 09 17:12:02 freesmartphone.org: 03morphis 07msmcomm * rbfaed9da4d87 10/libmsmcomm/msmcomm/ (messagetype.vala messageutil.vala pdsmmessage.vala): libmsmcomm: implement pdsm PD_EVENT message type Jun 09 17:12:02 freesmartphone.org: 03morphis 07msmcomm * r204618f1edb2 10/libmsmcomm/protocol/all_hci_messages_hp_veer.txt: libmsmcomm: add list of hci messages types used with webOS on the HP Veer device Jun 09 17:12:04 freesmartphone.org: 03morphis 07msmcomm * rd64930cdb305 10/scripts/hci-stat.py: Jun 09 17:12:04 freesmartphone.org: Add simple script to count HCI message types in binary strings list Jun 09 17:12:04 freesmartphone.org: It's usefull to dump all strings from the TelephonyInterfaceLayer binary to see if there Jun 09 17:12:04 freesmartphone.org: are new HCI messages types or if there is a difference between different versions of the Jun 09 17:12:04 freesmartphone.org: protocol. Jun 09 17:12:42 freesmartphone.org: 03morphis 07msmcomm * r87bc56e80523 10/libmsmrpc/ (31 files in 3 dirs): Jun 09 17:12:42 freesmartphone.org: libmsmrpc: initial import from the android open source project Jun 09 17:12:42 freesmartphone.org: This will be the starting point for experimentaions with the variant of the msmcomm Jun 09 17:12:42 freesmartphone.org: protocol used mainly on smartphones based completly on a system made by qualcomm. Both AP Jun 09 17:12:42 freesmartphone.org: and BP processors are made by Qualcomm in this systems so they communicates over a shared Jun 09 17:12:42 freesmartphone.org: memory interface. For the communication the oncrpc protocol is used. On top of this other Jun 09 17:12:43 freesmartphone.org: protocols like AT or msmcomm (sometimes even named QMI/HCI) can be used. Jun 09 17:12:43 freesmartphone.org: 03morphis 07msmcomm * re90e0d57bebb 10/libmsmrpc/msmrpc/msmrpc.h: libmsmrpc: add all necessary includes of header files to the common header file Jun 09 17:14:43 mrmoku, yeah, I'm scared of Vala. Jun 09 17:14:58 TAsn: welcome to the club ;-) Jun 09 17:15:11 mrmoku, though the reason mostly was: I don't have time for yet another "best ever" language. Jun 09 17:15:22 DocScrutinizer, thanks. When's the next club party? Jun 09 17:15:50 bah, it's so hot in here. Jun 09 17:16:21 facebook going another step ahead of BigBrother ;-P Jun 09 17:17:13 what now? Jun 09 17:17:17 next step: you don't even need to enter your personal data when opening an account - mere enabling of the flash webcam plugin will do that for you Jun 09 17:17:27 he's wasting his talent on facebook, he could have been the next george orwell. Jun 09 17:17:44 DocScrutinizer, lol. Jun 09 17:19:11 TAsn: wo's "he"? Zuckerberg? Jun 09 17:19:16 yeah. Jun 09 17:19:28 Suckerberg Jun 09 17:19:42 you can say a lot of things about him Jun 09 17:19:46 but one thing you can't Jun 09 17:19:49 he's not a sucker Jun 09 17:19:50 :) Jun 09 17:19:51 even Suckerborg Jun 09 17:21:38 the man made tons of money Jun 09 17:21:41 out of nothing Jun 09 17:21:49 he's a genius ;) Jun 09 17:24:18 DocScrutinizer: indeed... I tried with aplay and alsamixer... while aplay is still running alsamixer refuses to switch DAI mode Jun 09 17:24:22 it works before aplay and after Jun 09 17:24:35 does not seem to kill anything though Jun 09 17:24:37 just does not work Jun 09 17:25:02 yeah, might be another arcane bit of wolfson magic Jun 09 17:26:05 mrmoku: are you sure DAI switching is supposed to work while a stream is open? What use is in that? Jun 09 17:26:14 probably you mustn't switch DAI while it's occupied by a path as figured out by that obscure powersaving magic's notion of pathes Jun 09 17:27:07 PaulFertser: see? it's been just <1/2h when I said "will bite your arse sooner or kater" Jun 09 17:27:09 PaulFertser: on incoming call the ringtone is still playing and we want to switch to gsm Jun 09 17:27:33 kater, nice ;-D Jun 09 17:28:28 mrmoku: why not turning off the ringtone first? Jun 09 17:28:41 because it takes ages Jun 09 17:29:40 and voila: we got our asses bitten by a smartass driver "AI" Jun 09 17:29:55 PaulFertser: unfortunattely ringtone is still handled by oeventsd Jun 09 17:30:06 which is slow by definition Jun 09 17:30:16 I hate to be right always Jun 09 17:31:12 so we got this by upgrading kernel to 2.6.37 :/ Jun 09 17:31:13 DocScrutinizer: (right always) heh, i often had the same thought Jun 09 17:31:34 mrmoku: worth raising a question on alsa-devel ML i think. Jun 09 17:31:56 DocScrutinizer: and aci would fail the same way as we have to switch dai, right? Jun 09 17:32:15 PaulFertser: yeah Jun 09 17:33:32 mrmoku: right, this seems to be a bug in concept of wm8753 driver Jun 09 17:33:38 mrmoku: you can tell them about the usecase of PA constantly keeping the stream open i guess. Jun 09 17:34:04 (bug in concept) i wouldn't be too sure in that, it's a pretty straightforward driver for the ASoC framework. Jun 09 17:35:05 a driver mustn't lock some state transitions or actions in general, based on the driver devel's notion of what's a valid usecase Jun 09 17:35:32 so if it's really the driver that blocks DAI switching, then it's definitely a bug Jun 09 17:35:46 NFC if in concept or by accident Jun 09 17:36:53 well, maybe that's the driver's bugfix for the kernel-freeze_on_DAIswitching Jun 09 17:37:26 so it might be way more complicated than we assumed first Jun 09 17:38:17 [2011-06-09 18:51:16] kills the kernel Jun 09 17:39:16 the "correct" bugfix would be to tear down the PCM stream in a way that doesn't freeze kernel, on DAI mode switching Jun 09 17:39:48 should be feasible as it's all in one driver Jun 09 17:40:21 don't expect the usual "layering violation issues" blocking a clean approach Jun 09 17:40:36 maybe looking at git log for the driver scheds some light Jun 09 17:40:45 good idea Jun 09 17:41:38 might be an "old" patch though that's just rising its ugly head on new fso timing Jun 09 17:42:39 I don't think there've been plenty of patches to wm8753 driver lately, so it's easily spotted Jun 09 17:45:48 the dai issue has been properly fixed recently Jun 09 17:46:02 you can only change the dai mode if there is no pcm active Jun 09 17:46:18 so with 2.6.39 it would be fixed? Jun 09 17:46:25 yes Jun 09 17:47:43 no, it's exactly what I explained above, It's "fixed" in a way that causes a new bug Jun 09 17:48:58 i don't think so Jun 09 17:49:05 the intention of the fix been ok, the implementation is kinda suboptimal Jun 09 17:49:26 JaMa|Off: still around Jun 09 17:50:23 larsc: what about the "PA" usecase when it's constantly ready to produce some sound? Jun 09 17:50:34 it's kinda like removing the lightswitch to fix a short in the lamp mounted at ceiling Jun 09 17:51:03 i think we even discussed the patch here Jun 09 17:51:27 DocScrutinizer51: and you recommanded doing this way Jun 09 17:52:16 ouch, if that's true that it proves I'm not always constantly bright ;-) Jun 09 17:53:13 ~hail DocScrutinizer for being mortal ;) Jun 09 17:53:13 * apt bows down to DocScrutinizer for being mortal ;) and chants, "I'M NOT WORTHY!!" Jun 09 17:53:13 we can easily remove the check Jun 09 17:53:57 as mentioned above, the right fix is to tear down the PCM on DAI mode switching, not to forbid DAI mode switching while PCM is in use Jun 09 17:54:41 i guess that would cause pulse audio or whoever does playback to crash Jun 09 17:54:50 because of buffer overruns Jun 09 17:55:23 or, just maybe and if feasible, just fix the root issue and make PCM (driver/kernel) ) ignore DAI switching rather than freeze Jun 09 17:55:47 (crash) so be it Jun 09 17:55:58 it's what I'd expect to happen anyway Jun 09 17:56:29 "you asked for it, you get it" - please don't try to outsmart user of driver API Jun 09 17:58:17 look, a mere "cat /proc/kmem" can tear down my whole system. I asked for it, I got it Jun 09 17:59:04 there's nobody suggesting to forbid certain access patterns to /dev/kmem Jun 09 17:59:21 forbid inside driver* Jun 09 18:00:17 mrmoku: I said "*IF* that's true..." ;-) Jun 09 18:02:23 for sure it's a nogo to get a kernel freeze on a supposedly harmless audiocontrol switching. But the fix is to forbid/fix the freeze, not to forbid the switching Jun 09 18:05:47 hm Jun 09 18:06:09 don't have all the different state files the same dai mode anyway? Jun 09 18:06:34 mrmoku: does it fail trying to set the same mode as before? Jun 09 18:09:09 mrmoku: http://pastebin.com/VGB7jZgY Jun 09 18:09:18 should hopefully fix the issue Jun 09 18:10:42 hmm... it's when switching from pcm playback to gsm audio... let me check the scenarios Jun 09 18:11:10 root@om-gta02 /etc/freesmartphone/conf/openmoko_gta/alsa-2.6.34 # grep DAI gsmhandset Jun 09 18:11:13 50:'DAI Mode':1:0 Jun 09 18:11:15