**** BEGIN LOGGING AT Tue Jun 28 02:59:58 2011 Jun 28 04:02:50 DocScrutinizer, hay Jun 28 10:36:15 dcordes_, ping Jun 28 12:30:22 good morning everyone (at least is morning here :) ) Jun 28 12:33:50 hi Jun 28 12:35:06 DocScrutinizer: what app is it and what's the warning about? ;) Jun 28 12:46:26 DocScrutinizer, basically for cmtspeech there is a test uttility Jun 28 12:46:32 that test uttility does loopback Jun 28 12:47:00 that is to say it memcpy the downloaded buffer to the uploaded buffer Jun 28 12:47:02 it works fine Jun 28 12:47:15 so mickeyl converted it to vala Jun 28 12:47:23 and then later made a plugin out of it Jun 28 12:47:44 that's the plugin I'm using Jun 28 12:49:27 GNUtoo: I know Jun 28 12:50:30 there's a CAVEAT about that test utility somewhere about it doesn't handle timing requests from libcmtdata for upstream in a correct way, or sth like that Jun 28 12:52:00 so basically this is what delivers your cmt_read() and cmt_write() cals, though the latter needs some evaluation and improvement probably, if my remarks in last line is correct Jun 28 12:52:54 ok Jun 28 12:53:06 could we fix download of data first? Jun 28 12:53:25 (writei) Jun 28 12:53:33 when mickey conveted that to a "lib" providing cmt_write() and cmt_read() then we need the API specs for that lib Jun 28 12:54:32 download should be just fine, given the implementation of cmt_read() is free of flaws Jun 28 12:54:40 ok Jun 28 12:54:47 but I've still bad sound quality Jun 28 12:55:00 so I guess it's my alsa part Jun 28 12:55:09 should "jusr work" with the FIFO concept I sketched yesterday Jun 28 12:55:25 ok Jun 28 12:55:28 I'll re-read Jun 28 12:55:43 shouldn't it be somethink like UDP rather Jun 28 12:55:50 to drop frames if there is an issue Jun 28 12:55:55 rather than lag behind Jun 28 12:56:16 for test porposes you're free to fill the FIFO from a read() from a file holding raw audio data, rather than from cmt_read() Jun 28 12:56:35 ok Jun 28 12:57:06 you'd nee to do that on a timer-provided pace though Jun 28 12:57:11 need* Jun 28 12:57:37 playing with that timer you can simulate behaviour of cmt_read() Jun 28 12:57:44 first thing to do: I clean the code and push the improved version Jun 28 12:57:45 ok Jun 28 12:58:05 or I simply put read instead of memcpy Jun 28 12:59:30 sorry I'm a bit distracted right now, as I filled an application form, and tried to print it out prior to hitting "send" button, which of course froze konqueror, so my work of last 90min is lost :-((( Jun 28 12:59:49 ouch Jun 28 12:59:50 sorry Jun 28 13:00:22 pondering to coredump friggin konqueror and strings the coredump Jun 28 13:00:48 or better attach gdb Jun 28 13:00:57 as coredump could fail Jun 28 13:01:02 ok Jun 28 13:01:06 probably WILL fail Jun 28 13:01:16 indeed as usual Jun 28 13:01:28 fsckng computers! Jun 28 13:02:31 when there's *one* thing I hate then that's for sure web forms with text edit boxes Jun 28 13:10:45 freesmartphone.org: 03GNUtoo 07gsmvoice_alsa_cmtspeechdata+buffer_threads * rd259d6f08b8c 10cornucopia/fsoaudiod/src/plugins/gsmvoice_alsa_cmtspeechdata/cmthandler.vala: Jun 28 13:10:45 freesmartphone.org: cmthandler.vala: fix size of buffer,various other fixes, and disable readi for now Jun 28 13:10:45 freesmartphone.org: Note that pcmout.recover seem to produce better sound quality than pcmout.prepare Jun 28 13:10:45 freesmartphone.org: Signed-off-by: Denis 'GNUtoo' Carikli Jun 28 13:11:08 no fear it's in a branch Jun 28 13:12:32 http://git.freesmartphone.org/?p=cornucopia.git;a=blob;f=fsoaudiod/src/plugins/gsmvoice_alsa_cmtspeechdata/cmthandler.vala;h=f2803b01f66d8b6d2e67eba33ee1b8e5f743ed0b;hb=d259d6f08b8c8a971c9f4db4fb792102f2695844 Jun 28 13:12:38 here's the code Jun 28 13:12:45 *current code Jun 28 13:13:07 it's better than before Jun 28 13:13:13 but still not acceptable/perfect Jun 28 13:13:45 feel free to review later(since you're very busy now) Jun 28 13:23:09 basically I've some very small crackeling Jun 28 13:33:55 maybe I should skip the first frames Jun 28 14:02:38 \o/ the "print" call returned finally, with a proper requester to select printer (of course I immediately cancelled that one ;-P) - just had to wait an hour or so Jun 28 14:17:15 freesmartphone.org: 03morphis 07aurora * rc5590e6c1c9c 10/aurora-components/ (Makefile.am configure.ac): aurora-components: cleanup up build environment Jun 28 14:17:16 freesmartphone.org: 03morphis 07aurora * rd8569e81433f 10/aurora-components/plugins/kernel/ (4 files): aurora-components: we don't want moc files under version control Jun 28 14:17:17 freesmartphone.org: 03morphis 07aurora * rd7edeb8b05af 10/aurora-components/plugins/kernel/ (10 files): Jun 28 14:17:17 freesmartphone.org: aurora-components: import theme image provider from meego-ux-components Jun 28 14:17:17 freesmartphone.org: Taken from git://meego.gitorious.org/meego-ux/meego-ux-components, rev Jun 28 14:17:17 freesmartphone.org: ab609e153b676a3cf4e1bff3ee0fa19771d5cad1 Jun 28 14:17:17 freesmartphone.org: 03morphis 07aurora * r5c28717d52d7 10/aurora-components/plugins/gestures/ (4 files): aurora-components: remove some more moc files from version control Jun 28 14:17:18 freesmartphone.org: 03morphis 07aurora * r5e78fbabbdaf 10/aurora-components/.gitignore: aurora-components: add our own .gitignore file Jun 28 15:13:06 heyho Jun 28 15:16:13 GNUtoo: you know which kind the HTC leo is using for modem communication? Jun 28 15:19:35 hi morphis,at least with shr-chroot that error i don't get it :) Jun 28 15:19:45 angelox: yeah! Jun 28 15:20:34 morphis: thank you by saying that! Jun 28 15:23:14 :) Jun 28 15:24:27 freesmartphone.org: 03GNUtoo 07gsmvoice_alsa_cmtspeechdata+buffer_threads * rab655519e3b9 10cornucopia/fsoaudiod/src/plugins/gsmvoice_alsa_cmtspeechdata/cmthandler.vala: Jun 28 15:24:27 freesmartphone.org: fsoaudiod: gsmvoice_alsa_cmtspeechdata: fix issues during call release,improve audio quality Jun 28 15:24:27 freesmartphone.org: Without this fix fsoaudiod can segfault or block during call release Jun 28 15:24:27 freesmartphone.org: The audio quality fix is about not playing frames before they are ready: Jun 28 15:24:27 freesmartphone.org: Otherwise the playback threads plays back before the modem memcpy data to the Jun 28 15:24:28 freesmartphone.org: transefert buffer. Jun 28 15:24:28 freesmartphone.org: Signed-off-by: Denis 'GNUtoo' Carikli Jun 28 15:24:37 again it's pushed in a branch Jun 28 15:25:01 morphis, bb on laptop Jun 28 15:25:08 sorry I was on laptop without xchat Jun 28 15:25:31 hi morphis Jun 28 15:27:27 morphis, it uses the singleline plugin Jun 28 15:27:34 morphis, htcleo configs are upstream Jun 28 15:30:06 GNUtoo|laptop: ah ok, so no binary rpc calls Jun 28 15:30:37 GNUtoo|laptop: btw. you got a power cable for the geeksphone? Jun 28 15:30:55 morphis, I always got a cable, the problem is the battery Jun 28 15:30:58 I just bought it Jun 28 15:31:03 with a discount for developers Jun 28 15:32:43 ok Jun 28 15:32:49 but it did not arrive yet? Jun 28 15:34:48 GNUtoo|laptop: hi, is sound quality good now with that last commit? Jun 28 15:35:08 morphis, it was ordered today Jun 28 15:35:14 mrmoku, try it Jun 28 15:35:16 if you want Jun 28 15:35:19 GNUtoo|laptop: ah ok Jun 28 15:35:20 it's not so bad Jun 28 15:35:26 but it's not perfect Jun 28 15:35:35 mrmoku, last commit also means the one in master Jun 28 15:35:40 my branch is not ready yet Jun 28 15:38:23 GNUtoo|laptop: ok Jun 28 15:38:27 bbiab Jun 28 15:38:42 ok Jun 28 16:06:32 morphis: what are zhone2 and tefosa on Aurora git? Jun 28 16:06:53 zhone2 is zhone written in vala Jun 28 16:07:00 and tefosa is some playground from mickey Jun 28 16:07:29 ah ok,thank you! Jun 28 16:07:44 no problem Jun 28 16:08:34 mrmoku: for perfect quality we probably need some smart handling of xrun cases Jun 28 16:09:08 as well as ome buffer fill management, i.e. start playback when buffer filled 50%, not earlier Jun 28 16:09:49 buffer==FIFO Jun 28 16:10:37 DocScrutinizer: yeah, but that should be a second step if it is _usable_ without Jun 28 16:10:39 then do some smart framedrpping, framedupping to match speed of ALSA playback to the rate of inbound data Jun 28 16:11:09 mrmoku: yep Jun 28 16:11:18 GNUtoo|laptop: umts still does not work for you? Jun 28 16:11:25 aiui it's _usable_ Jun 28 16:11:46 * mrmoku will try that now Jun 28 16:12:11 make sure you got proper logging of the xruns etc Jun 28 16:12:24 otherwise we'll never learn what's going on Jun 28 16:13:52 yup Jun 28 16:14:31 [123231.234412] cmtspeech: FIFO XRUN: alsa asks for 160 frames, FIFO readptr 320, writeprt:320, available:0 frames. feeding silence to alsa instead Jun 28 16:15:57 or Jun 28 16:17:10 freesmartphone.org: 03morphis 07aurora * ra49f7e549cae 10/aurora-daemon/aurora/aurora.in: aurora-daemon: we now use the image provider from the qml plugin Jun 28 16:17:10 [123231.234412] cmtspeech: FIFO XRUN: alsa asks for 160 frames, FIFO readptr 320, writeprt:400, available:60 frames. upsampling 60 to 160 by duplicating 160/60 frames Jun 28 16:18:46 bbl Jun 28 16:26:49 freesmartphone.org: 03morphis 07aurora * ra79021a336f6 10/aurora-applications/ (19 files in 2 dirs): aurora-applications: separate also the applications into their own component Jun 28 16:26:50 freesmartphone.org: 03morphis 07aurora * rcb9722a24d72 10/aurora-daemon/ (aurora/config.py.in configure.ac): aurora-daemon: add missing config.py.in and switch for application directory Jun 28 16:42:30 freesmartphone.org: 03morphis 07aurora * r75cde404c348 10/aurora-daemon/configure.ac: aurora-daemon: install python files into the correct directory Jun 28 16:42:31 freesmartphone.org: 03morphis 07aurora * rc5f5584c6668 10/aurora-daemon/aurora/config.py.in: aurora-daemon: fix python config file Jun 28 16:42:31 freesmartphone.org: 03morphis 07aurora * r83a45cc972ed 10/aurora-daemon/aurora/aurora.in: aurora-daemon: statically load the phone application for now Jun 28 16:43:00 mrmoku, no, mickey|daddy gave me some hints Jun 28 16:43:41 DocScrutinizer,I've started to add buffer-fill thing, it's in the previous commit, but it's not smart enough Jun 28 16:44:22 mrmoku, it fails with error 255 Jun 28 16:44:33 which seem to be something with AUT Jun 28 16:44:35 let me find it Jun 28 16:47:45 GPDS_CAUSE_AUT_FAILURE Jun 28 16:47:49 it seem to be that Jun 28 16:48:01 I asked sre and he told me that it seemed to be that too Jun 28 16:48:09 I wasn't sure at first Jun 28 16:49:21 mrmoku, there are bits like the kind of auth Jun 28 16:49:24 like ms chap Jun 28 16:49:27 or similar Jun 28 16:49:30 in PPP Jun 28 16:49:36 I think mickeyl talked about that Jun 28 16:50:47 Jun 21 22:20:37 hmm, do you know whether you have CHAP or PAP auth? Jun 28 17:35:41 ping mrmoku Jun 28 17:40:07 GNUtoo|laptop: pong Jun 28 17:42:06 GNUtoo|laptop: my build finished... will upgrade and see if it works for me Jun 28 17:58:25 ping dcordes_ Jun 28 18:13:22 mrmoku, ok Jun 28 18:19:19 mrmoku, which branch did you buitl? Jun 28 18:19:22 try the master first Jun 28 18:19:28 and then try the new branch Jun 28 18:19:44 the new branch doesn't have microphone->modem activated Jun 28 18:19:50 it works but I disactivated it Jun 28 18:20:05 ahh, ok Jun 28 18:20:06 to concentrate on modem->alsa Jun 28 18:20:09 I built the new one Jun 28 18:20:10 first Jun 28 18:20:11 ok Jun 28 18:20:12 try it Jun 28 18:20:20 but only call your operator number Jun 28 18:20:25 do not call someone with it Jun 28 18:20:25 upgrading did not work due to no usb networking Jun 28 18:20:30 ok Jun 28 18:20:33 yeah, will only call myself :) Jun 28 18:20:33 ifdown usb0 Jun 28 18:20:35 ifup usb0 Jun 28 18:20:39 did not help Jun 28 18:20:41 call the operator Jun 28 18:20:45 switching to g_ether did not help Jun 28 18:20:48 free operator number Jun 28 18:20:55 no need to spend on this Jun 28 18:21:01 I have two partners sims I can use to call myself for free Jun 28 18:21:02 and for recording when I'll add it Jun 28 18:21:07 ah ok Jun 28 18:21:08 nice Jun 28 18:21:10 wow Jun 28 18:21:11 indeed :) Jun 28 18:22:31 be sure to have my last commit in Jun 28 18:22:41 it fix a crash on hangup Jun 28 18:22:49 or it crashes(segfault) Jun 28 18:22:52 or it blocks Jun 28 18:22:55 but in any case Jun 28 18:23:01 you have to restart the modem Jun 28 18:23:10 ab655519e3b997638c7860549a966b65b6504f72 Jun 28 18:23:12 with the fix it works fine Jun 28 18:23:13 fsoaudiod: gsmvoice_alsa_cmtspeechdata: fix issues during call release,improve audio quality Jun 28 18:23:13 let me look Jun 28 18:23:19 yes that one Jun 28 18:23:22 it's the last one Jun 28 18:59:53 I'm debugging the frame pointers Jun 28 18:59:58 *buffer pointers Jun 28 19:00:04 it always starts at 0 Jun 28 19:00:07 and finish at 320 Jun 28 19:00:54 mrmoku, updatePtr has ptr beeing 0 Jun 28 19:00:59 and then at the end it's 320 Jun 28 19:01:05 and it's the same each time Jun 28 19:01:07 strange Jun 28 19:02:10 mrmoku, do you have an idea, I used out Jun 28 19:02:16 * GNUtoo|laptop will look at .c Jun 28 19:03:14 hmmm Jun 28 19:03:26 the .c doesn't look very good: Jun 28 19:03:35 glong _ptr = 0L; Jun 28 19:03:47 _ptr = _ptr + num; Jun 28 19:04:01 *ptr = _ptr; Jun 28 19:04:41 mrmoku, are you there? Jun 28 19:04:45 if not I go to #vala Jun 28 19:05:02 yup Jun 28 19:05:03 here Jun 28 19:05:19 which .c is that? Jun 28 19:05:25 http://www.pastie.org/private/6ews4xkmk3h2fqkj14dpg Jun 28 19:05:27 first .vala Jun 28 19:05:29 and then .c Jun 28 19:05:31 ahh, cmthandler Jun 28 19:05:34 yes Jun 28 19:05:52 glong _ptr = 0L; Jun 28 19:05:55 why that line? Jun 28 19:07:13 looks like ptr is out only Jun 28 19:07:30 what do you mean? Jun 28 19:07:41 I tought out would be like & Jun 28 19:07:52 for instance: Jun 28 19:07:56 foo(out bar) Jun 28 19:08:03 is like foo(&bar) Jun 28 19:08:11 updatePtr(out writeiReadptr, frames * 2); Jun 28 19:08:16 yes Jun 28 19:08:26 what's the problem with that? Jun 28 19:08:32 looks like it does not pass in the value of writeiReadptr Jun 28 19:08:42 yes it passes a pointer Jun 28 19:08:44 just set it backwards Jun 28 19:08:47 so I can modify the pointer Jun 28 19:08:52 what do you mean? Jun 28 19:09:02 I surelly missed something in the vala language Jun 28 19:10:10 GNUtoo|laptop, the code looks a bit cryptic.. wouldn't be easier to do ptr%960 ? Jun 28 19:10:31 pespin, I'll explain Jun 28 19:10:34 there are 2 pointers Jun 28 19:10:46 let forget about C pointers Jun 28 19:10:48 I've a buffer Jun 28 19:10:57 and I've a long that points to the number of frames Jun 28 19:11:11 s/frames/bytes Jun 28 19:11:19 if I'm at 320 bytes Jun 28 19:11:28 the long would be 320 Jun 28 19:11:39 like long pointer = 320; Jun 28 19:11:43 yep Jun 28 19:11:44 then the second level Jun 28 19:11:49 I add a C pointer to it Jun 28 19:11:55 to increment it Jun 28 19:11:57 GNUtoo|laptop: http://live.gnome.org/Vala/Tutorial#Parameter_Directions Jun 28 19:12:04 guess what you want is ref instead of out Jun 28 19:12:09 like updatePtr(out pointer, increment) Jun 28 19:12:28 mrmoku, honestly I read only part of that tutorial Jun 28 19:12:33 I don't know vala enough Jun 28 19:12:38 * mrmoku neither Jun 28 19:13:12 ah ok Jun 28 19:13:17 thanks a lot Jun 28 19:13:25 well let's hope that's it :) Jun 28 19:14:06 ok, but I don't see the relation between what you are saying and what I said :) Jun 28 19:14:17 mrmoku, btw, how was italy? are you still there? Jun 28 19:14:54 phone ringing Jun 28 19:15:02 pespin: no, back :) Jun 28 19:15:09 was fine Jun 28 19:15:21 even made it twice to the playa :) Jun 28 19:15:28 mrmoku, nice, quite hot I guess hehe Jun 28 19:15:47 the days with sun have been hot indeed Jun 28 19:15:56 but fortunatelly there was some rain too ;) Jun 28 19:16:16 great :) Jun 28 19:16:38 the worst thing there was the disconnection :P Jun 28 19:17:23 heh 3g? Jun 28 19:17:26 * mrmoku still has to find a solution for that... paying 0,50 € / 10kB roaming is ridicolous Jun 28 19:17:48 pespin: yeah, getting some prepaid italian sim would be the plan Jun 28 19:18:01 did that once some year ago Jun 28 19:18:18 but as I'm in italy only about twice a year Jun 28 19:18:30 the sim got deactivated after some time of not recharging it :/ Jun 28 19:19:17 lol Jun 28 19:25:39 http://www.pastie.org/private/v0b7tjlosnepxfummjkxw Jun 28 19:26:19 I'll convert to ref other stuff too Jun 28 19:57:36 GNUtoo|laptop, what I meant is that in case the method is finished you could just do for example... private void updatePtr(out long ptr, Alsa.PcmSignedFrames frames){ ptr += frames; ptr %= 960; } Jun 28 19:57:46 * pespin dinner Jun 28 20:01:58 mrmoku, should I push my debugging? Jun 28 20:02:03 what are you working on right now? Jun 28 20:02:17 because I am now messing with the buffers Jun 28 20:05:04 pespin: looks pretty correct, except for the hardcoded bufferlength Jun 28 20:06:52 though I'd not do this in a separate function Jun 28 20:09:04 c++ actually is nice for stuff like that, just override the + and - operators for type ringbufferpointer Jun 28 20:11:25 GNUtoo|laptop: yup push please Jun 28 20:11:36 mrmoku, I'll fix the buffer managements Jun 28 20:11:42 work on something else in the mean time Jun 28 20:14:49 aha alsa goes faster than the modem: Jun 28 20:14:55 I'll push Jun 28 20:17:04 GNUtoo|laptop: ok, will take a look at that umts problem Jun 28 20:18:14 well, the whole thing obviously doesn't work yet Jun 28 20:19:28 while I got no clue about vala, the c code suggests "out" means it's not a parameter to pass values in to the called function Jun 28 20:19:28 freesmartphone.org: 03GNUtoo 07gsmvoice_alsa_cmtspeechdata+buffer_threads * r9b6f1b01d323 10cornucopia/fsoaudiod/src/plugins/gsmvoice_alsa_cmtspeechdata/cmthandler.vala: Jun 28 20:19:29 freesmartphone.org: fsoaudiod: gsmvoice_alsa_cmtspeechdata plugin : fix fix buffer position handling ,add buffer position loggin to stderr, and fix buffer pointers Jun 28 20:19:29 freesmartphone.org: Signed-off-by: Denis 'GNUtoo' Carikli Jun 28 20:19:41 ok Jun 28 20:19:47 I was told out was like & Jun 28 20:19:53 so I blindly did that Jun 28 20:19:57 *did what I did Jun 28 20:20:18 basically here's what it does: Jun 28 20:20:29 first modem start to write and update writeptr Jun 28 20:20:33 from 0 to 320 Jun 28 20:20:37 with 160 frames Jun 28 20:20:46 then playback thread read it Jun 28 20:20:58 and update the read pointer from 0 to 320 Jun 28 20:21:04 then reads again Jun 28 20:21:16 and update read pointer from 320 to 640 Jun 28 20:21:42 then during the check writeptr(320) - readptr(640) becomes negative Jun 28 20:21:44 -320 Jun 28 20:22:00 then it reads again, -640 Jun 28 20:22:14 wow, scary Jun 28 20:22:36 so what should I do Jun 28 20:22:44 alsa plays back faster than the modem Jun 28 20:23:13 I do a fifo Jun 28 20:23:18 like for instance Jun 28 20:23:21 definitely you can't say that, as your code as of last pastebin is not working at all Jun 28 20:23:41 the new code is in git Jun 28 20:23:45 I just pushed it Jun 28 20:23:56 anyway Jun 28 20:24:06 I was thinking of a variable that holds the number of buffers Jun 28 20:24:20 and to check that before playing Jun 28 20:24:28 or better Jun 28 20:24:37 we already have writeptr and readptr Jun 28 20:24:55 which never must run one over the other Jun 28 20:25:02 I'll require that readptr < writeptr Jun 28 20:25:25 else what to do between: Jun 28 20:25:27 *sleep Jun 28 20:25:54 *continue the loop at next iteration(may be very cpu angry) Jun 28 20:26:33 for instance a while true;do dmesg -c;done uses quite some cpu Jun 28 20:26:44 in fact it raises the CPU at 100% Jun 28 20:26:57 you need to service your data sink i.e. alsa, so if there's not enough data in fifo, i.e. when writeptr - readptr < datachunksize (160), you need to feed some filler material to alsa Jun 28 20:27:12 you never must got to sleep in there Jun 28 20:27:32 ah ok silence Jun 28 20:27:40 how to feed silence already? Jun 28 20:27:47 there is silence in the drivers Jun 28 20:28:01 so there must be a standard way to do it Jun 28 20:28:07 I think there's an alsa macro for that, but you also can null the buffer Jun 28 20:28:19 yes but the macro is better Jun 28 20:28:27 because I know from the kenrel alsa system Jun 28 20:28:32 that there is not only 0x0 Jun 28 20:28:34 as silence Jun 28 20:28:38 they have silences tables Jun 28 20:28:41 yes Jun 28 20:28:46 depends on datatype Jun 28 20:28:48 for instance one for S16_LE Jun 28 20:28:52 one for S32_LE Jun 28 20:28:53 etc... Jun 28 20:29:48 basically you didn't handle XRUN at all Jun 28 20:30:03 ah? Jun 28 20:30:13 please reread my explanation as of yesterday Jun 28 20:30:16 yes I know It's not ready Jun 28 20:30:22 I'm just working on it Jun 28 20:30:25 ok Jun 28 20:30:45 the time where I was absent Jun 28 20:30:47 I'll look Jun 28 20:30:58 *I'll look better Jun 28 20:31:00 if fifo doesn't have enough data, you have a logical xrun (as opposed to a hard xrun on e.g. alsa that we want to avoid) Jun 28 20:31:08 ah ok Jun 28 20:31:19 then I fill silence Jun 28 20:31:31 yes Jun 28 20:31:52 I hope you're not too much angry against me but it's a work in progress, I cannot do everything at once Jun 28 20:32:08 first approach is to fill in one chunk of silence and NOT advance readptr Jun 28 20:32:15 ok Jun 28 20:32:16 right Jun 28 20:32:43 it's normal not to advance the pointer here Jun 28 20:32:49 next time you either got more data in fifo, or your do same thing again Jun 28 20:32:50 because you are not playing the buffer Jun 28 20:33:26 btw datachunksize is 320 Jun 28 20:33:35 160 frames Jun 28 20:33:40 but 320 bytes Jun 28 20:35:11 on write-to-fifo side you check for distance of your writeptr ahead to readptr, and if there's not enough free space in fifo, you discard the chunk and do not advance writepointer. Next time maybe readpointer has advanced so you got enough free space in fifo for next chunk, or you do same thing again: discard Jun 28 20:35:42 GNUtoo|laptop: the umts problem is easy to solve... opkg install kernel-module-pn-pep; modprobe pn-pep :-) Jun 28 20:35:54 mrmoku, ok thanks Jun 28 20:35:57 I'll try tomorrow Jun 28 20:36:07 this way neither readpointer can run over writepointer, nor can writeptr run over readptr Jun 28 20:38:04 if your result for distance xptr to yptr ahead is negative, (i.e. yptr-xptr<0) this means you have to add sizeof(fifo) on the result Jun 28 20:38:30 err, <=0 Jun 28 20:40:14 I'd actually suggest to keep the pointers in a way so they never point to same location either - add one frame safety size to FIFO if this is simpler for you to handle Jun 28 20:40:35 fifo[3*320 + 1] Jun 28 20:40:40 ok Jun 28 20:41:07 never use hardcoded values, always use sizeof() Jun 28 20:41:21 how? Jun 28 20:41:37 like sizeof (char) * foo * bar Jun 28 20:42:05 I hardcoded because it was a buffer Jun 28 20:42:17 but usually in C you should not hardcode Jun 28 20:42:27 r=xptr-yptr; if r<=0 then r+=sizeof(fifo) Jun 28 20:42:35 ahh ok Jun 28 20:42:41 that doesn't work in vala I think Jun 28 20:42:55 ahh let me think Jun 28 20:42:59 there is a .len Jun 28 20:43:02 I'll try that Jun 28 20:44:11 or you do frame fifo[FIFOSIZE]; and use FIFOSIZE whereever you need it Jun 28 20:44:14 .length Jun 28 20:45:21 #define FIFOSIZE 1 + ( 3 * SEGMENTSIZE) Jun 28 20:45:39 #define SEGMENTSIZE 160 Jun 28 20:45:58 r=xptr-yptr; if r<=0 then r+=FIFOSIZE Jun 28 20:53:08