**** BEGIN LOGGING AT Wed Jun 29 02:59:56 2011 Jun 29 05:28:09 moin Jun 29 08:29:13 freesmartphone.org: 03morphis 07aurora * rd8b07f09d782 10/aurora-components/ (10 files in 2 dirs): aurora-components: don't use the caching version of the image provider Jun 29 09:43:27 freesmartphone.org: 03morphis 07aurora * r401356451965 10/aurora-components/plugins/kernel/ (Makefile.am localtime.cpp localtime.h plugin.cpp): Jun 29 09:43:28 freesmartphone.org: aurora-components: import localtime component from meego-ux-components Jun 29 09:43:28 freesmartphone.org: Taken from git://meego.gitorious.org/meego-ux/meego-ux-components, revision Jun 29 09:43:28 freesmartphone.org: 68bb32f7565778e3bf5331029e0200239de90045 Jun 29 09:43:28 freesmartphone.org: 03morphis 07aurora * r1eaa81de3ed1 10/aurora-components/components/StatusBar.qml: aurora-components: statusbar: use kernel instead of util plugin Jun 29 09:54:58 freesmartphone.org: 03morphis 07aurora * ra5411d1c7c66 10/aurora-components/components/Window.qml: aurora-components: clean up windows component from unneeded stuff Jun 29 09:54:58 freesmartphone.org: 03morphis 07aurora * r23674fb68f53 10/aurora-applications/app-phone/main.qml: aurora-applications: app-phone: integrate pin request dialog Jun 29 10:10:14 moin Jun 29 10:11:04 mahlzeit :) Jun 29 10:11:12 mrmoku: lindi supplied a nice examle in vala for a ringbuffer/fifo yesterday Jun 29 10:11:29 I wouldn't trust it, was written by reading vala docs for 10 minutes :P Jun 29 10:11:36 mrmoku: I edited it a bit, but it's not yet finished Jun 29 10:12:30 well, I read no vala docs at all, just picked examples from your and gnutoo's code Jun 29 10:13:09 anyway I'll pastebin it here, as I feel I won't fix the read routine anytime the next few hurs Jun 29 10:13:13 hours Jun 29 10:13:46 morsche Jun 29 10:14:44 morsche Jun 29 10:14:46 http://paste.debian.net/121371/ Jun 29 10:15:54 lindi-: it should handle the writing of arbitrary length chunks to fifo ok, if you're interested, the read() part would look quite similar Jun 29 10:16:45 it's not yet finished as I pondered to adapt it to our special requirements and implement a kind of uo/downsampling directly in there Jun 29 10:17:10 memcpy sounds very non-vala :) Jun 29 10:17:47 I couldn't care less :-) Jun 29 10:18:29 I bet it has more errors that chars ;-P Jun 29 10:18:50 the concept should give an idea however Jun 29 10:20:12 I felt really sorry with gnutoo when I noticed he's joggling with four pointers and stuff, and constantly converting/typecasting int/long/alsa-frame/pointer/whatnot Jun 29 10:29:37 (non-vala) this is a realtime process that needs to be performant, not beautful or vala-conformant Jun 29 10:30:30 whe I said I'd probably rather code it in assembler than in vala, I wasn't completely kidding, just a bit Jun 29 10:31:41 I dunno, I always thought SHR is a result oriented project, not an educational one Jun 29 10:48:38 mrmoku, mickey|office || mickey|daddy DocScrutinizer || DocScrutinizer51 , so what do we do for the cmtspeech plugin? Jun 29 10:48:57 do I stop working on it and give the work to someone else? Jun 29 10:50:35 freesmartphone.org: 03morphis 07aurora * r4c05727e4d54 10/aurora-applications/app-phone/main.qml: aurora-applications: app-phone: cleanup some stuff Jun 29 10:50:35 freesmartphone.org: 03morphis 07aurora * r29a6e44ad01c 10/aurora-applications/app-phone/ (CallPage.qml DialerPage.qml main.qml): aurora-applications: more work on phone application Jun 29 10:50:53 GNUtoo: i took a look at the code and the cmtspeech docs this morning Jun 29 10:51:00 GNUtoo: why, i thought you were making progress? Jun 29 10:51:45 mickey|office, I don't know vala enough Jun 29 10:52:13 GNUtoo: we're doing some basic thing wrong I think Jun 29 10:52:41 yes like ring buffer handling Jun 29 10:52:47 more basic :) Jun 29 10:52:55 like? Jun 29 10:53:01 pointer handling? Jun 29 10:53:08 sending to the modem should not happen in the data handler Jun 29 10:53:32 readi/sending to the modem is disabled right now Jun 29 10:53:34 I know that Jun 29 10:53:39 doc told me about it Jun 29 10:53:57 ok Jun 29 10:54:27 sending to modem needs a timer to schedule the pace of sending chunks Jun 29 10:54:35 yup Jun 29 10:54:44 adjusted by the timer events the modem gives Jun 29 10:54:50 the modem doesn't directly provide any clock or trigger Jun 29 10:55:28 exactly, it just sends some adjustment message I yet have to decode and understand (actually to spot the definition of it) Jun 29 10:55:59 test_cmtspeech_msgs.c might help Jun 29 10:56:15 the second test is for timing_config_ntf Jun 29 10:56:28 cmtspeech_msg_decode_timing_config_ntf(cmd, &msec, &usec); Jun 29 11:03:22 mrmoku, DocScrutinizer first we must implement a correct writei, right? Jun 29 11:03:29 mine is not correct at all Jun 29 11:03:56 and the source code is a soup with some C, some vala in non-object form etc... Jun 29 11:11:50 freesmartphone.org: 03morphis 07aurora * r039cb6dc42b0 10/aurora-systemmanager/systemmanager/controller.vala: aurora-systemmanager: respect power supply status before suspending Jun 29 11:12:33 GNUtoo: isn't pcm.writei() provided by mickey|daddy 's vala bindings? Jun 29 11:12:50 not exactly Jun 29 11:12:58 mickey|daddy, did something like that: Jun 29 11:13:31 cmtspeech.vala->vala alsa library wrapper -> alsa vala bindings Jun 29 11:14:07 err how comes cmtspeech in here? Jun 29 11:14:26 are we talking about also or about cmtspeechdata now? Jun 29 11:14:38 s/also/alsa/ Jun 29 11:14:38 DocScrutinizer meant: are we talking about alsa or about cmtspeechdata now? Jun 29 11:14:55 DocScrutinizer, sorry the .vala for the cmtspeechdata Jun 29 11:15:04 basically alsa Jun 29 11:15:10 but the alsa part is in: Jun 29 11:15:31 freesmartphone.org: 03morphis 07cornucopia * r52cc7e53fd1c 10/fsoaudiod/src/plugins/ (manager/plugin.vala streamcontrol_alsa/plugin.vala): fsoaudiod: some initial work on the alsa streamcontrol plugin Jun 29 11:15:37 cmthandler.vala Jun 29 11:15:43 so sorry for the imprecision Jun 29 11:16:05 I'm thoroughly puzzled Jun 29 11:16:28 that file: Jun 29 11:16:51 http://git.freesmartphone.org/?p=cornucopia.git;a=blob;f=fsoaudiod/src/plugins/gsmvoice_alsa_cmtspeechdata/cmthandler.vala;h=3ae3f0ae1054931601b5ed1ea53893128474245f;hb=ada6904e875ae8884e6b4c1c758d912b7df0eb92 Jun 29 11:20:44 ok, that's the most recent handler? Jun 29 11:21:18 I think so Jun 29 11:22:15 yes it is Jun 29 11:23:56 :nod: Jun 29 11:24:24 shall we have a look into it and try to "fix things"? Jun 29 11:25:08 mrmoku, feel free to continue my work Jun 29 11:25:14 I'm tired, it's too hot here Jun 29 11:25:27 ok Jun 29 11:25:29 will do that Jun 29 11:25:42 though it's hot here too :) Jun 29 11:25:57 ok Jun 29 11:26:04 like 30 degrees? Jun 29 11:26:25 so I've to wait until the slow climatizer does its effect Jun 29 11:26:26 would have to go downstairs to check Jun 29 11:26:34 but it feels like 30 yeah Jun 29 11:26:37 ok Jun 29 11:27:24 ~weather EDDN Jun 29 11:27:27 Nuernberg, Germany; (EDDN) 49-30N 011-03E 318M; last updated: 2011.06.29 1120 UTC; Dew Point: 55 F (13 C); Pressure (altimeter): 29.97 in. Hg (1015 hPa); Relative Humidity: 37%; Temperature: 84 F (29 C); Visibility: greater than 7 mile(s); Wind: from the W (280 degrees) at 6 MPH (5 KT) (direction variable) Jun 29 12:11:59 freesmartphone.org: 03morphis 07aurora * raacf9c4868ae 10/aurora-theme/data/theme/ (icons/Makefile.am images/Makefile.am widgets/Makefile.am): aurora-theme: install in the new common place for aurora themes Jun 29 13:05:52 quit Jun 29 13:24:48 mickey|office: have a minute? Jun 29 13:31:21 or any other vala guru for that :) Jun 29 13:32:59 DocScrutinizer: btw. there is a ring buffer implemention included in cmtspeech Jun 29 13:34:26 morphis: hey, maybe you :) do you know how to handle unions in vapis? Jun 29 13:36:19 mrmoku: you mean unions defined in c code? Jun 29 13:37:31 yup Jun 29 13:37:43 morphis: actually a struct with a union of structs inside Jun 29 13:37:44 look at this: http://www.mail-archive.com/vala-list@gnome.org/msg00311.html Jun 29 13:37:57 yeah, already found that Jun 29 13:38:14 and? Jun 29 13:38:33 hmm Jun 29 13:38:46 actually re-looking at it it might indeed help me Jun 29 13:38:54 at first look I thought not so Jun 29 13:38:56 thx :-) Jun 29 13:41:27 it should :) Jun 29 13:41:48 hmm... the structs inside the union are unnamed... Jun 29 13:42:37 can I have structs in the vapi without [CCode... ? Jun 29 13:44:00 * mrmoku will just try Jun 29 13:46:09 mrmoku: if there's a FIFO in cmtspeech then I miss the point of sending paced data upstream Jun 29 13:47:04 mrmoku: NB I didn't look into the cmtspeech-test_converted_to_a_lib thing Jun 29 13:47:43 I'd guess we need a proper API description for that, otherwise it's mere handwaving how to interface it Jun 29 13:47:51 DocScrutinizer: I'm talking about sal_ring.h Jun 29 13:48:05 cmtspeech_nokiamodem.c: ring_buffer_t evbuf; /**< driver-io: queued received events */ Jun 29 13:48:08 only used there Jun 29 13:48:12 not for the data Jun 29 13:48:17 but we could bind and use it Jun 29 13:48:17 meh Jun 29 13:48:22 sure Jun 29 13:49:30 if it is suited for datatype Alsa.PcmSignedFrames Jun 29 13:49:51 or a sane typecast thereof Jun 29 13:50:14 otoh is that vala? o.O Jun 29 13:50:30 sure not :P Jun 29 13:50:40 but we have a vapi to bind libcmtspeech stuff anyway Jun 29 13:50:44 and could add it Jun 29 13:51:03 I fail to see the benefit in this Jun 29 13:52:02 seems like it's more work to create the bindings and do all the needed typcast and whatnot, than to simply redo the whole FIFO implementation generic Jun 29 13:52:59 the purpose of includes etc is to save you work, no? Jun 29 13:53:16 :-) Jun 29 13:53:58 if you want to do this right, then create a generic vala include to deliver FIFO Jun 29 13:54:30 yeah, you're probably right Jun 29 13:54:48 creating vala bindings for a fifo implementation defined in cmtspeech sounds utterly non-re-usable to me Jun 29 13:58:15 quick'n'dirty approach: c&p the draft as of lindy with my "annotations", fix it, finish the read(), and use it locally in the handler. If you find you get bored next weekend, consider to shell it out into a proper include or .h or lib or whatever the name for vala Jun 29 14:00:19 that's at least my take on "first make it work, then make it better/nice" approach Jun 29 14:18:49 DocScrutinizer: yup, going to do that Jun 29 14:34:52 DocScrutinizer: 1970-01-01T03:30:20.489772Z [DEBUG] CmtHandler : modem UL timing update: msec = 19 usec = 393 Jun 29 14:34:58 morphis: did work :-) Jun 29 14:39:06 DocScrutinizer: BYTES-PER-FRAME == sizeof(Alsa.PcmSignedFrames) ? Jun 29 14:44:13 yup Jun 29 14:44:46 hmm... read looks fishy Jun 29 14:44:52 mrmoku: (timing update) now if only I knew the semantics of that ;-) Jun 29 14:45:27 fishy? fishifishifishifishy? Jun 29 14:45:43 what look sfishy? Jun 29 14:45:59 DocScrutinizer: the caller must release the buffer in sync with network timing. Jun 29 14:46:05 yep Jun 29 14:46:18 int new_ring_tail = (ring_tail + num_of_frames) % ring_size; Jun 29 14:46:24 ring_tail = (ring_tail + 1) % ring_size; Jun 29 14:46:34 new_ring_tail not being used Jun 29 14:46:48 err, is that in read? Jun 29 14:46:58 yup Jun 29 14:47:04 read is unfinished nonsense Jun 29 14:47:13 first line added then stopped Jun 29 14:47:22 ahh, ok :() Jun 29 14:47:25 that explains Jun 29 14:47:25 has to look similar to write() Jun 29 14:47:39 with memcpy Jun 29 14:47:44 yo Jun 29 14:47:47 good Jun 29 14:47:59 and handling of wraparound Jun 29 14:48:20 then I pomdered to alsa_silence the buffer on xruns, then I got away about it Jun 29 14:49:36 while musing about a int on function parameters that ranges from -chunksize to +chunksize and tells after which number of frames to drop/duplicate one frame, to match speed Jun 29 14:50:44 actually (chunksize - abs(int) ) tells the number of frames after which to insert/drop a frame Jun 29 14:50:52 but that' Jun 29 14:50:58 s for next weekend ;-) Jun 29 14:51:52 as I'm yet unclear if that maybe needs another semantic for the int Jun 29 14:52:17 like frames per 1000 to add/drop Jun 29 14:52:49 so -1 would mean you make 999 frames out of 1000 from source Jun 29 14:53:21 you need static counter obviously for that, as a chunk is 160 frames only Jun 29 14:54:15 and it gets tricky with memcpy as soon as you drop every third frame ;-P Jun 29 14:54:38 so you see where I stalled :-D Jun 29 14:55:04 mrmoku, how is it progressing? Jun 29 14:56:10 mrmoku: (timing update, caller must release...) this is a nasty part which needs some care I guess Jun 29 14:56:45 mrmoku: yeah! Jun 29 14:57:31 GNUtoo: I'm adding lindis/Docs RingBuffer right now Jun 29 14:57:53 mrmoku: probably the modem has exactly one chunksize buffer, and we need to take care to deliver data in correct pace not to mess up OTA packets schedule. So it needs some further investigation what exactly are the semantics of that timing messages Jun 29 14:57:58 GNUtoo: and I extended the cmtspeech vapi to get to the messages data Jun 29 14:58:13 DocScrutinizer: agree Jun 29 14:58:47 * DocScrutinizer reponders this alsa sound paper of that nokia dude Jun 29 15:00:33 lol Jun 29 15:00:57 often people tell that something is impossible and it turns out not to be true Jun 29 15:01:16 GNUtoo: 1970-01-01T03:30:20.489772Z [DEBUG] CmtHandler : modem UL timing update: msec = 19 usec = 393 Jun 29 15:01:30 now we have some numbers... just don't know how to handle them :P Jun 29 15:01:41 ok Jun 29 15:01:52 maybe I've an idea Jun 29 15:01:55 http://linuxplumbersconf.org/2009/slides/Jyri-Sarha-audio_miniconf_slides.pdf Jun 29 15:02:00 yes that Jun 29 15:02:10 they told alsa was impossible to implement if I remember well Jun 29 15:02:58 "Latency functions of ALSA do not work well with DMA doing block transfers" Jun 29 15:03:54 Synchronize up link audio buering with Cellular Modem Jun 29 15:03:56 Cellular Modem sends up-link timing adjustment messages Jun 29 15:03:57 Align up-link buering according to messages Jun 29 15:03:59 Change UL timing with 5 ms granularity Jun 29 15:07:11 page 10 :) Jun 29 15:07:40 ok Jun 29 15:08:06 ping me as soon as there is something to test Jun 29 15:08:49 or to look at(like a push in the branch) Jun 29 15:14:54 3g works for me with pn-pep Jun 29 15:14:57 thanks a lot Jun 29 15:15:01 I'd *think* those timing messaages tell how long to delay to next buffer to push upstream Jun 29 15:15:07 yes Jun 29 15:15:13 me too Jun 29 15:15:17 but meybe they tell how much your timer is off Jun 29 15:15:23 like for how long to write silence Jun 29 15:15:57 why do we have to play_silence on playback? Jun 29 15:16:01 or they tell the period you should use for your cyclic timer Jun 29 15:16:42 mrmoku: to avoid buffer underruns on ALSA which would require a complete recover procedure and is a nasty thing Jun 29 15:17:15 at very least ALSa would playback crap and noise if you don't Jun 29 15:18:49 the hardware is set up to constantly convert digital data to analog voltages, at a certain sample rate. It's not a nice thing to stop this - better feed the hardware with whatever, ideally silence Jun 29 15:19:10 ok Jun 29 15:19:53 (not entirely correct - you should duplicate last sample's value on a whole filler frame to avoid a slight click on cutting off waveform, but meh) Jun 29 15:20:49 you then also would need to implement some sort of highpass filter, so waveform eventually returns to zero nevertheless Jun 29 15:21:12 way too tricky for a first shot Jun 29 15:21:42 oh yes :P Jun 29 15:23:51 mrmoku: don't miss to initialize fifo buffer with silence as well, can't hurt :-) Jun 29 15:24:45 it *should* never playback random stuff from fifo, but meh Jun 29 15:26:03 or you may want (for eval test) initialize fifo with nasty 0xFF00FF00 to get a characteristic beep whenever that happens Jun 29 15:26:39 so you can tell from mere listening it's doing the wrong thing :-) Jun 29 15:28:22 mrmoku: you're aware you want to send silence to cmt as well, on fifo xrun Jun 29 15:28:39 exactly same situation, just more critical Jun 29 15:29:03 DocScrutinizer: yeah that side I was aware about Jun 29 15:29:33 well, it's abolutely same as on ALSA pcm.writei() side :-) Jun 29 15:30:11 if there's no proper audio data available in fifo, then send silence instead Jun 29 15:31:19 this way you can simply stop the mic process filling the ul_fifo and you got a properly working muted mic Jun 29 15:32:19 dl_fifo fill is prone to dropouts anyway, as the data stream from modem will stop when there are OTA induced glitches Jun 29 15:44:16 hi morphis Jun 29 15:44:23 GNUtoo: heyho Jun 29 15:44:56 I wonder if I could integrate qsd routing + call activator in fsoaudiod Jun 29 15:45:12 you can Jun 29 15:45:34 about the call activator we have to talk, but qsd routing is possible Jun 29 15:45:37 and should be done Jun 29 15:45:51 if you don't do it I will do it when I have the HP Veer Jun 29 15:46:49 we need a router_qsd plugin for this Jun 29 15:49:54 ok Jun 29 15:50:00 call activator is easy Jun 29 15:50:07 it's just routing with a different ioctl Jun 29 15:50:15 still sound Jun 29 15:50:30 basically the AUDIO_START ioctl Jun 29 15:50:44 morphis, but didn't the veer use alsa? Jun 29 15:50:56 morphis, the beginning of the plugin is here: Jun 29 15:51:07 GNUtoo: I don't use Jun 29 15:51:16 it's looking as they are using both Jun 29 15:51:24 https://gitorious.org/htc-msm-2-6-32/uttilities/blobs/master/fso-voicecall/fso-voicecall.vala Jun 29 15:51:32 ah ok Jun 29 15:52:11 GNUtoo: thats the activator? Jun 29 15:52:15 morphis, yes Jun 29 15:52:31 it's very similar to the n900 cmt plugin Jun 29 15:52:44 ok Jun 29 15:53:08 very similar not because it uses cmt, it doesn't Jun 29 15:53:18 but in the listen for a call and do something thing Jun 29 15:54:07 ok Jun 29 15:54:07 with that calls + mic work Jun 29 15:54:15 mic during calls only Jun 29 15:54:32 ok, but I doubt that we should add the dependency on fsogsmd in fsoaudiod Jun 29 15:54:35 ok Jun 29 15:54:54 * angelox tries to fix another error Jun 29 15:54:55 with that: http://www.shr-project.org/trac/wiki/Android%20Porting%20Guide#sound we get some kind of alsa Jun 29 15:55:14 Hi alL,btw! Jun 29 15:55:39 GNUtoo: yeah, I already saw that Jun 29 15:55:46 GNUtoo: it's a nice workaround Jun 29 15:55:48 angelox: hey Jun 29 15:56:16 GNUtoo: btw. the bcm4329 is it supposed to support the 4319 too? Jun 29 15:56:23 no idea Jun 29 15:56:28 I must look Jun 29 15:56:28 GNUtoo: the 4319 is named within the driver Jun 29 15:56:37 I think there is a 4319 sdio driver Jun 29 15:56:40 I looked at the one palm is using Jun 29 15:56:42 but I don't remember which one Jun 29 15:56:44 ok Jun 29 15:56:45 ok Jun 29 15:56:52 they are using a pretty old version Jun 29 15:56:54 4.x Jun 29 15:56:59 android has 5.x Jun 29 15:57:02 ok Jun 29 15:57:08 and as the driver reports to be GPL Jun 29 15:57:13 I requested the source from palm Jun 29 15:58:35 ok Jun 29 15:59:05 morphis, basically the n900 plugin depends on fsogsmd Jun 29 15:59:12 why is that an issue Jun 29 15:59:12 ? Jun 29 15:59:57 it does? Jun 29 16:00:08 in which way? Jun 29 16:01:05 like that: http://git.freesmartphone.org/?p=cornucopia.git;a=blob;f=fsoaudiod/src/plugins/gsmvoice_alsa_cmtspeechdata/plugin.vala;h=095ecaeb3994513ed6babdb6039f5abbbcd660f0;hb=HEAD Jun 29 16:01:24 it just listen for dbus signals Jun 29 16:01:26 from fsogsmd Jun 29 16:01:53 hm ok Jun 29 16:02:06 let's talk about more interesting stuff :) Jun 29 16:02:18 indeed Jun 29 16:02:32 how can I implement routing? Jun 29 16:02:41 will the current API change? Jun 29 16:02:49 or is it only in fsodeviced that it will change Jun 29 16:02:50 ? Jun 29 16:03:48 also I will have to make a wifi plugin for the dream Jun 29 16:05:38 GNUtoo: you mean the dbus API of fsoaudiod? Jun 29 16:05:59 or this http://git.freesmartphone.org/?p=cornucopia.git;a=blob;f=fsoaudiod/src/lib/router.vala;h=9cf68e9d4be58a5d9c698b8e96c5367e813e2032;hb=HEAD ? Jun 29 16:06:04 I mean the API I have to implement within my plugin Jun 29 16:06:21 I didn't look at it yet Jun 29 16:06:30 but I know mrmoku started to work on something Jun 29 16:06:50 ah ok Jun 29 16:07:00 you mean the msm audio interface? Jun 29 16:07:09 I'll explain Jun 29 16:07:12 mrmoku, has an n900 Jun 29 16:07:17 yes, please do that Jun 29 16:07:22 doc told us that the curent scenario management is bad Jun 29 16:07:42 scenario is an fsodeviced scenario Jun 29 16:07:53 but it's not flexible enough Jun 29 16:08:01 for instance if you want to raise the volume Jun 29 16:08:08 you must save the scenario Jun 29 16:08:17 so I didn't look at the detail Jun 29 16:08:24 and don't have more details about it Jun 29 16:08:33 but anyway it will change the API Jun 29 16:08:54 ok Jun 29 16:08:56 and I'm lost between that and fsoaudiod Jun 29 16:08:59 we have fsoaudiod Jun 29 16:09:05 ok Jun 29 16:09:12 which is a approach to throw the scenario stuff away Jun 29 16:09:14 then why was he working on that Jun 29 16:09:16 ? Jun 29 16:09:22 mrmoku, ^^^ Jun 29 16:09:32 stop Jun 29 16:09:38 ok Jun 29 16:09:43 if we have to do the routing with adjusting the alsa controls Jun 29 16:09:55 the current way in fsoaudiod is still scenario handling Jun 29 16:09:56 yes ajust controls individually Jun 29 16:10:14 that was the idea, replace the scenarios by individual controls ajustements Jun 29 16:10:24 for the n900 fsoaudiod just put in an abstraction layer for the user Jun 29 16:10:27 ok Jun 29 16:10:40 then there is another router implementation for fsoaudiod needed Jun 29 16:11:13 but thats not the same way you want to go for the msm router, right? Jun 29 16:11:19 no Jun 29 16:11:27 there is no scenarios Jun 29 16:11:40 I'll start at importing the current plugin Jun 29 16:11:46 and then add routing on top of it Jun 29 16:11:52 I call it qsd8k? Jun 29 16:12:03 or qdsp6 Jun 29 16:12:07 rather qdsp6 Jun 29 16:12:51 would it be suitable for all msm devices? Jun 29 16:12:54 no Jun 29 16:12:58 only for qdsp6 Jun 29 16:13:09 or snapdragoon with that particular interface Jun 29 16:13:20 for instance it's not suitable for the dream Jun 29 16:13:26 the dream is msm7k Jun 29 16:13:29 and has qdsp5 Jun 29 16:14:55 what's wrong with alsa mixer API/driver for that hardware? why can't it get implemented? Jun 29 16:15:32 the hardware is qualcomm SOC, and it implement a different interface than alsa Jun 29 16:15:38 so there are 2 solutions Jun 29 16:15:44 or make a mixer in userspace Jun 29 16:15:51 like alsa mixer hooks Jun 29 16:16:00 or adapt fsoaudiod Jun 29 16:16:09 GNUtoo: then name it router_qdsp6 Jun 29 16:16:23 we can separate things we implement a router_qdspx Jun 29 16:16:44 there is also the option to implement an alsa driver in the kernel, but I would become crazy if I do it Jun 29 16:16:52 GNUtoo: so router_qdsp6 is suitable for nexus one, hp veer, ... Jun 29 16:17:00 I'd first look into feasibility of a genuine proper alsa adaption, rather than mess with adapting FSO/whatever to a botch from dunnowhere Jun 29 16:17:54 to make sound during calls work you have to issue some ioctls Jun 29 16:18:01 I can't really see why any particular hardware couldn't get a proper alsa mixer driver with alsa mixer API Jun 29 16:18:01 is that a problem for an alsa plugin? Jun 29 16:18:06 it can Jun 29 16:18:19 it's just that I don't want to write an alsa driver from scratch Jun 29 16:18:41 well, we need some special cruft for N900 for calls as well, as you know Jun 29 16:18:49 yes Jun 29 16:19:09 so I should try to revive my alsa driver for the nexus? Jun 29 16:19:24 and may become crazy and stop computers totally? Jun 29 16:19:35 :) Jun 29 16:19:36 for the rest I'd strongly recommend to go for a clean ALSA implementatin rather than to try cope with whatever botch we inherited from android or whatever Jun 29 16:19:52 yes but what do you advise between : Jun 29 16:19:57 *an alsa kernel driver Jun 29 16:20:02 * and alsa userspace driver Jun 29 16:20:06 I'm even a fan of implementing cmtspeechdata as a regular ALSA soundcard Jun 29 16:20:09 s/and/an/ Jun 29 16:20:09 GNUtoo meant: * an alsa userspace driver Jun 29 16:20:22 yes I know Jun 29 16:20:32 of course a kernel driver Jun 29 16:20:41 so I may become crazy Jun 29 16:20:49 hm Jun 29 16:20:56 I've already some problems such as nervousness Jun 29 16:21:02 is it that hard to write the driver? Jun 29 16:21:12 it shouldn't Jun 29 16:21:13 for the dream it was hard to debug Jun 29 16:21:35 all alsa drivers are alike, just have a different lower half to talk to the hardware Jun 29 16:21:55 note that I never succeeded at fixing dream's issue Jun 29 16:22:04 and I'm not the only one Jun 29 16:22:11 palm didn't either in their pixie Jun 29 16:22:23 I fixed some issues Jun 29 16:22:25 but not all Jun 29 16:22:51 some I fixed were not fixed in the other drivers(pixie,geeksphone etc...) Jun 29 16:23:01 ok Jun 29 16:23:37 yeah nowadays all fools use PA, so they don't see the reason to implement a soundcard in ALSA when they can write a PA plugin to access the hw directly Jun 29 16:24:05 that's what Nokia did for cmtspeech Jun 29 16:24:08 yes part of the workarround was in alsa lib, part was in pulseaudio with fixed buffer Jun 29 16:24:13 for the pixie Jun 29 16:24:23 probably also what had been done on android for those devices Jun 29 16:24:36 no pulse on android but another system Jun 29 16:24:40 some devices used alsa Jun 29 16:24:46 they worked arround on higher levels Jun 29 16:25:03 like using fixed buffer size of 4800 or something like that Jun 29 16:25:05 * DocScrutinizer away Jun 29 16:27:53 the whole audio situation sounds very odd Jun 29 16:28:18