00:00:42 | saratoga | if i highpass the signal and then upsample it so that its no longer critically sampled, I get something that looks like digital data |
00:01:12 | saratoga | modulated at pretty much 19khz |
00:03:10 | pamaury | which cutoff frequency do you use ? |
00:05:27 | | Quit nxs (Ping timeout: 245 seconds) |
00:07:05 | saratoga | i just did it by eye |
00:07:10 | saratoga | probably about 15khz |
00:07:46 | saratoga | also, if that data is correct, either the chip or the radio station has an absolute frequency error of only 0.9956 |
00:08:47 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
00:09:09 | pamaury | saratoga: is that good ? |
00:09:15 | saratoga | yeah its good |
00:09:31 | saratoga | probably just means the clock is slightly faster then 38k |
00:09:50 | saratoga | do you know matlab? |
00:10:14 | pamaury | no, I only know maple but I'm not sure it's quite as useful for this ^^ |
00:10:52 | pamaury | and I used audacity to try a few things |
00:11:16 | | Join Wardo [0] (~Mirandaha@bpb01-1-88-162-4-186.fbx.proxad.net) |
00:11:33 | pamaury | So I would need to implement a high-pass filter in software, right ? How do you do that ? |
00:13:01 | saratoga | oh wow i got it |
00:13:08 | pamaury | do the discretization of an ideal high pass filter ? |
00:13:14 | pamaury | \o/ |
00:13:15 | saratoga | we have some in rockbox already |
00:13:24 | saratoga | hold on, i'll put up a figure |
00:15:03 | saratoga | http://mit.edu/mgg6/www/bpsk.png |
00:15:15 | saratoga | red is the clock, blue is the signal |
00:15:27 | saratoga | you can see that it flips between in phase (1) and out of phase (0) |
00:16:20 | pamaury | amazing :) |
00:16:25 | | Quit Wardo (Quit: Blarglarg) |
00:17:08 | saratoga | hmm should probably check that those bits are at the right rate and not just random :) |
00:19:03 | pamaury | so they sample at 38kHz a 19kHz carrier, that's really the minimum you can do |
00:19:11 | | Join TheSphinX^ [0] (~briehl@p5B321CC0.dip.t-dialin.net) |
00:19:26 | saratoga | yeah |
00:19:36 | | Quit TheSphin- (Read error: Operation timed out) |
00:19:47 | saratoga | its actually a 38100 Hz sampling rate |
00:20:15 | saratoga | well i get that a phase change happens every 64 samples, whereas the real rate should be 32 i think |
00:20:21 | saratoga | so maybe i'm missing something? |
00:20:54 | saratoga | 38000Hz/1187.5bits/s = 32 samples per bit right? |
00:21:37 | pamaury | yeah, sounds correct |
00:22:07 | saratoga | oh wait that must have been two consecutive 1s |
00:22:37 | saratoga | i found a transition that happens after about 32 samples |
00:23:49 | pamaury | is there a free version of matlab ? |
00:24:49 | funman | GNU Octave ? |
00:26:40 | pamaury | ok, I think I'll stop here for today |
00:26:50 | pamaury | saratoga: many thanks for your help |
00:27:26 | * | gevaerts expects saratoga to tell us what radion station pamaury is listening to any moment now :) |
00:29:54 | saratoga | well i can demodulate it and all, but i have no idea what the bistream means |
00:32:32 | pamaury | well differential encoder + NRZ + error correcting codes |
00:33:07 | pamaury | hey, the RDS spec actually has a nice diagram of how it works with pictures of the signals |
00:35:11 | saratoga | ok i can spit out 1s and 0s |
00:35:20 | saratoga | but the SNR sucks, so i'm probably not scaling something right |
00:36:04 | saratoga | http://mit.edu/mgg6/www/bpsk2.png |
00:36:31 | saratoga | every 32 samples, if the black trace is positive its a 1, negative a 0 |
00:37:21 | | Quit melmothX (Remote host closed the connection) |
00:45:49 | saratoga | pamaury: do you want some data? |
00:48:43 | pamaury | yes :) |
00:48:52 | | Quit Raptors (Ping timeout: 244 seconds) |
00:49:17 | saratoga | pamaury: http://mit.edu/mgg6/www/rds.dat |
00:49:27 | saratoga | no promises there aren't bit errors though as i think my code sucks :) |
00:49:50 | saratoga | actually i have no idea if any of that is correct |
00:49:54 | pamaury | rds is made to handle errors |
00:51:03 | saratoga | actually, that data is probably wrong |
00:51:08 | pamaury | anyway, the real time version of this will be much more tricky, I expect |
00:51:18 | pamaury | why ? |
00:51:25 | saratoga | i'm just assuming that its exactly 32 samples per bit |
00:51:31 | saratoga | but theres probably some drift overtime |
00:51:36 | pamaury | hum, indeed |
00:51:41 | saratoga | so the first bytes are probably ok but i bet i drift over time |
00:51:42 | * | kugel also coded a (q)psk in matlab a while ago |
00:52:04 | saratoga | yours is probably a lot more useful |
00:52:18 | saratoga | i'm just mixing the carrier and signal, and checking to see if its one or zero |
00:53:34 | kugel | I did the same :p |
00:53:52 | bertrik | what does the rds spec say? |
00:54:29 | bertrik | I suppose it has a very description of the modulated signal and some hints on how to decode it |
00:56:56 | pamaury | bertrik: yes, "do it in hardware" ;) |
00:58:22 | | Join Raptors [0] (~whoneedsa@216-58-33-195.cpe.distributel.net) |
00:58:33 | saratoga | i think the problem with what i'm doing is that i just compute the carrier once for the whole signal, and then try to use it for a lot of points in time |
00:58:53 | saratoga | probably this has to be done piece-wise, with the carrier estimated locally for each bit of incoming data |
00:59:41 | saratoga | looking at my data, it seems like at some points i have good SNR because the two clocks are well synced, and at other points they drift apart and my SNR degrades |
01:00 |
01:00:09 | saratoga | apparently phase is important to phase shift modulation |
01:00:32 | bertrik | ☺ |
01:00:35 | kugel | no shit! |
01:01:15 | saratoga | lookning at the diagrams online, i guess thats why they bandpass out the incoming signal and mix it, that way you're always phase locked |
01:04:17 | pamaury | you mean that they extract the carrier from the multiplexed signal ? |
01:04:32 | saratoga | yeah |
01:05:30 | | Quit enriched (Remote host closed the connection) |
01:05:38 | pamaury | hum, indeed that more or less what the official rds diagram suggests. In this case we cannot do that, we don't have the carrier. Stupid chip |
01:05:51 | kugel | don't you usually have a pll at the receiver that locks into the phase of the inbound signal? |
01:06:21 | kugel | (of the carrier part, that is) |
01:06:33 | saratoga | we can get the carrier from the signal |
01:06:34 | bertrik | the carrier should be exactly 3x the stereo pilot, with a specific phase IIRC |
01:07:05 | | Join enriched [0] (~quassel@101.98.163.139) |
01:07:22 | saratoga | if you FFT the raw data, the strongest peak is the carrier |
01:08:21 | saratoga | there are two phases which represent the data, but they have the same frequency, and so we can just ignore that there is data by band pass filtering around the 19khz frequency |
01:08:23 | | Quit Raptors (Ping timeout: 260 seconds) |
01:10:55 | saratoga | actually, does that work? |
01:13:13 | saratoga | i wonder what happens if you get a bunch of zeros or ones in a row |
01:14:40 | gevaerts | There's probably a system to avoid that |
01:15:10 | | Join Raptors [0] (~whoneedsa@216-58-33-195.cpe.distributel.net) |
01:15:13 | saratoga | it uses NRZ |
01:15:17 | pamaury | saratoga: NRZ makes sure you have too many zeroes or one in a row, if it's the same thing as usb |
01:15:23 | pamaury | *don't have |
01:15:42 | saratoga | i thought NRZ was the one where you can have an unlimited number in a row? |
01:16:11 | saratoga | oh i guess not |
01:16:35 | pamaury | but can you really get the carrier from the data ? the rds data has very limited bandwidth. and you want to do that in real time anyway. Pfff, that's so easy to do correctly in hardware |
01:16:56 | pamaury | I don't understand why the chip was designed this way |
01:17:40 | bertrik | each 16 bit word is encoded as a 26 bit symbol, for error detection/correction and I think for making sure that there are not too many 0's and 1's in a row as well |
01:18:44 | | Quit bluebrother (Disconnected by services) |
01:18:49 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
01:19:09 | pamaury | saratoga: what's the problem with too many 0 and 1 anyway ? |
01:19:36 | gevaerts | miscounting them |
01:20:57 | | Quit fs-bluebot (Ping timeout: 245 seconds) |
01:22:13 | | Join fs-bluebot [0] (~fs-bluebo@g224239189.adsl.alicedsl.de) |
01:32:38 | | Quit ender` (Quit: The three most dangerous things in the world are a programmer with a soldering iron, a hardware type with a program patch and a user with an idea.) |
01:33:44 | | Quit bertrik (Remote host closed the connection) |
01:49:39 | saratoga | IIUC, the way this would work is that you'd have to bandpass filter the signal to recover the carrier, then compare the instantaneous signal to the carrier to see if its in or out of phase, but if theres a lot of one type or the other, the carrier will drift |
01:50:23 | saratoga | maybe theres a solution to that though? |
01:53:45 | *** | Saving seen data "./dancer.seen" |
01:58:08 | pamaury | saratoga: bandpass filter the rds signal ? |
02:00 |
02:06:35 | | Join Katu1 [0] (~katu@c-71-236-211-59.hsd1.or.comcast.net) |
02:22:54 | pamaury | saratoga: the rds says: the subcarrier must be locked either in phase or in quadrature to the third harmonic of the pilot. What does locked in quadrature mean ? |
02:39:06 | | Join orange_ [0] (43ddde44@gateway/web/freenode/ip.67.221.222.68) |
02:39:13 | orange_ | hello |
02:40:08 | orange_ | Does anyone have an ipod classic that run off a cf card? |
02:45:40 | orange_ | Is anyone using RockBox on an ipod classic with a compact flash card? |
02:47:07 | [Saint] | Such comments are unlikely to garner a response. The "right" way is "I am using <X> and experiencing problem <Y>". |
02:57:14 | saratoga | pamaury: quadrature means 90 degrees |
02:57:28 | saratoga | so phase locked but with a 90 degree shift i guess |
02:57:58 | | Part orange_ |
03:00 |
03:00:22 | saratoga | the comments in the linux driver say that the 19k and 57k carriers aren't always locked |
03:01:14 | | Join nateloaf [0] (~nwild@S0106bcaec5c3e90e.wp.shawcable.net) |
03:03:56 | pamaury | welcome to the real world :) |
03:38:23 | | Quit Rower (Quit: Hmmm...) |
03:46:08 | TheSeven | rasher: if nobody else offers something, I might have CPU cycles to spare for rockbox builds |
03:46:26 | TheSeven | I'm currently not even running the normal build system though (didn't get around to setting it up) |
03:46:48 | TheSeven | oh, and no static IP over here. but 10mbit/s of upstream bandwidth at least |
03:47:38 | rasher | TheSeven: I'm fine with hosting the downloads as I've been so far, so bandwidth isn't much of an issue |
03:48:44 | TheSeven | any special requirements? I assume I need to have the rockbox toolchain and android SDK installed? NDK as well? |
03:50:09 | [Saint] | SDK/NDK, and for some reason I can't get compilation going right without having both openjdk6 *and* 7. |
03:50:49 | rasher | hm, I recall having to uninstall one of them |
03:51:15 | rasher | TheSeven: but yeah, mingw32 and openjdk - the sdk/ndk can just stay local to my user |
03:51:48 | [Saint] | the SDK, size wise. |
03:52:00 | * | [Saint] missed multiple words. |
03:52:12 | [Saint] | the SDK is bloody ridiculous now, size wise. |
03:52:29 | TheSeven | depends on which targets you install |
03:52:42 | [Saint] | No, no...just, by default. |
03:53:01 | TheSeven | i think the bulk of it is an AVD /system image for every installed android version |
03:53:14 | [Saint] | It extracts to ~300MB+ without installing any additional files. |
03:53:35 | [Saint] | NDK is near 1GB |
03:53:46 | *** | Saving seen data "./dancer.seen" |
03:53:49 | TheSeven | oh, sure... sdk can be several gigs as well |
03:54:07 | [Saint] | for our purposes it stays around ~500MB |
03:55:05 | TheSeven | rasher: if you don't get better offers by tomorrow, contact me so that I set it up. the server would be an ubuntu server amd64 box with an ivy bridge i3 cpu and 8 gigs of RAM |
03:55:51 | TheSeven | oh, and tell me how much disk space you need so that i can set up lvm accordingly |
03:56:09 | [Saint] | TheSeven: dyndns to provide a fixed route? |
03:56:18 | rasher | [Saint]: not really necessary |
03:56:18 | [Saint] | re: no fixed IP. |
03:56:31 | [Saint] | No, but, trivial. |
03:56:40 | TheSeven | yes, it has a dyndns hostname |
03:56:57 | [Saint] | there we go, you do have "a fixed IP" :) |
03:57:28 | TheSeven | and it's running a little apache anyway, that we could reuse if wanted |
03:58:11 | TheSeven | actual ip behind that host name changes every 24h along with a few seconds of downtime |
04:00 |
04:30:04 | | Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) |
04:30:04 | | Quit amiconn (Disconnected by services) |
04:30:04 | | Quit pixelma (Disconnected by services) |
04:30:04 | | Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) |
04:30:06 | | Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) |
04:30:06 | | Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) |
04:34:08 | | Quit pamaury (Ping timeout: 244 seconds) |
04:36:23 | | Join TheSphinX_ [0] (~briehl@p579CCF1C.dip.t-dialin.net) |
04:39:42 | | Quit TheSphinX^ (Ping timeout: 245 seconds) |
05:00 |
05:01:32 | | Join PurlingNayuki [0] (~7923e1bb@www.haxx.se) |
05:02:04 | PurlingNayuki | I've got banned from the forum without doing anyting... |
05:03:50 | saratoga | whats your username? |
05:04:06 | PurlingNayuki | That's yzflcyq |
05:05:11 | PurlingNayuki | I'd like to read a discussion in themes and open the forum only to got a banned message |
05:06:01 | saratoga | are you still banned? |
05:06:34 | saratoga | oh i see, you're on a host thats mostly spammers |
05:06:59 | PurlingNayuki | Why's that happen.. |
05:07:30 | saratoga | 163data.com.cn is one of the largest spam hosts in the world, so i blocked it a while ago |
05:07:39 | saratoga | are you still banned? |
05:08:02 | PurlingNayuki | I've tried and yes, stil banned |
05:08:46 | | Quit [Saint] (Remote host closed the connection) |
05:09:39 | PurlingNayuki | I don't think I can change my host...I'm now in mainland China and using ChinaTelecom as my ISP, behind the GFW |
05:10:13 | saratoga | i've removed that ban, i didn't realize normal users were on it too |
05:10:29 | saratoga | not sure if you can post yet, might have to wait until morning in europe when one of the admins reads the logs |
05:10:55 | PurlingNayuki | That's OK. |
05:11:06 | PurlingNayuki | Thanks and I can just wait. |
05:11:20 | saratoga | perhaps one of the admins can check if anyone else of the several thousand people banned by that rule had any non-spam posts |
05:11:53 | saratoga | or just revert all of those bans |
05:12:35 | PurlingNayuki | You know, when using ADSL users got different IP every time |
05:12:49 | | Quit PurlingNayuki (Quit: CGI:IRC) |
05:12:56 | | Join PurlingNayuki [0] (~7923e1bb@www.haxx.se) |
05:14:13 | PurlingNayuki | I own a site about Rockbox, chiefly for Chinese-speak users |
05:15:58 | PurlingNayuki | I can use the forum now and many thanks to you |
05:16:35 | saratoga | oh cool |
05:16:54 | saratoga | i guess it removed all the bans when i disabled the rule |
05:17:02 | saratoga | sorry again |
05:17:41 | PurlingNayuki | I searched for a keyword of '163data.com.cn' and realize that it's the Reverse DNS for all the chinatelecom ISP users |
05:18:17 | PurlingNayuki | so I do advise you to check others. |
05:18:45 | PurlingNayuki | There may be users banned but not knowing how to get obtain helps |
05:32:56 | | Join TheSphinX^ [0] (~briehl@p5B3225B3.dip.t-dialin.net) |
05:34:27 | | Quit TheSphinX_ (Ping timeout: 248 seconds) |
05:40:39 | | Quit TheSeven (Disconnected by services) |
05:40:47 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
05:50:27 | | Quit tchan (Quit: WeeChat 0.3.9.2) |
05:53:50 | *** | Saving seen data "./dancer.seen" |
05:59:19 | | Join [Saint] [0] (~saint@rockbox/user/saint) |
06:00 |
06:00:27 | | Join TheSphinX_ [0] (~briehl@p579CC6E2.dip.t-dialin.net) |
06:01:56 | | Join dfkt_ [0] (dfkt@unaffiliated/dfkt) |
06:02:59 | | Quit dfkt (Ping timeout: 260 seconds) |
06:03:11 | | Quit TheSphinX^ (Ping timeout: 264 seconds) |
06:11:12 | | Quit PurlingNayuki (Quit: CGI:IRC (EOF)) |
06:12:37 | | Quit XavierGr (Ping timeout: 252 seconds) |
06:15:34 | | Quit TheSphinX_ (Read error: Operation timed out) |
06:22:58 | | Join TheSphinX^ [0] (~briehl@p579CC22E.dip.t-dialin.net) |
07:00 |
07:05:58 | | Quit Raptors (Ping timeout: 260 seconds) |
07:10:30 | | Join TheSphinX_ [0] (~briehl@p5B3229CB.dip.t-dialin.net) |
07:12:24 | | Join Raptors [0] (~whoneedsa@216-58-33-195.cpe.distributel.net) |
07:13:29 | | Quit TheSphinX^ (Ping timeout: 252 seconds) |
07:29:31 | | Join TheSphinX^ [0] (~briehl@p5B322616.dip.t-dialin.net) |
07:32:13 | | Quit TheSphinX_ (Ping timeout: 260 seconds) |
07:37:47 | | Quit SuperBrainAK (Quit: pbly going to sleep /_\) |
07:44:10 | | Quit jhMikeS (Ping timeout: 256 seconds) |
07:53:29 | | Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) |
07:53:51 | *** | Saving seen data "./dancer.seen" |
08:00 |
08:15:07 | | Join eckoit [0] (~ryan@50.65.10.24) |
08:45:51 | | Quit eckoit (Quit: eckoit) |
08:50:28 | | Join kevku [0] (~kevku@2001:470:dcc6:0:69:69:69:69) |
08:54:58 | | Join n1s [0] (~n1s@nl118-168-30.student.uu.se) |
08:54:58 | | Quit n1s (Changing host) |
08:54:58 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
08:56:39 | | Join [Saint_] [0] (~saint@rockbox/user/saint) |
08:57:37 | | Quit [Saint] (Ping timeout: 245 seconds) |
09:00 |
09:04:53 | | Quit nosa-j (Ping timeout: 264 seconds) |
09:10:23 | | Join nosa-j [0] (~m00k@184.76.254.130) |
09:11:04 | | Nick [Saint_] is now known as [Saint] (~saint@rockbox/user/saint) |
09:27:30 | | Quit n1s (Read error: Connection timed out) |
09:51:29 | | Join melmothX [0] (~melmoth@unaffiliated/melmothx) |
09:53:54 | *** | Saving seen data "./dancer.seen" |
10:00 |
10:06:51 | | Quit zchs (Remote host closed the connection) |
10:08:12 | | Join pretty_function [0] (~sigBART@123.252.212.253) |
10:21:00 | | Join wodz [0] (~wodz@89-76-32-53.dynamic.chello.pl) |
10:21:06 | wodz | kugel: ping |
10:21:43 | kugel | wodz: ping |
10:23:00 | wodz | kugel: with your proposition of directly using fopen() and friends in plugins on hosted platform there is problem with paths |
10:23:36 | kugel | oh, right |
10:24:29 | kugel | now that you say it, normal open() etc are also wrapped |
10:24:43 | kugel | then discard that part of my comment |
10:26:40 | wodz | Now the final thing - do you have an idea how I could avoid separate header name (I mean that if someone uses stdio.h in plugin it would just work) |
10:27:07 | wodz | currently you would need #include "lib/stdio_compat.h" explicitly added. |
10:28:23 | wodz | kugel: ^ |
10:28:29 | kugel | stdio probably conflicts with the core one, right? |
10:28:41 | wodz | not really |
10:28:51 | wodz | it conflicts with host's |
10:29:33 | kugel | in what way? |
10:29:35 | wodz | hmm, maybe include lib/stdio_compat.h from core stdio.h in case of plugins |
10:30:22 | wodz | hmm, wait I didn't try it after _ wrapping maybe it doesn't conflict this way |
10:30:59 | wodz | anyway apps/plugins/lib is not in path |
10:32:54 | kugel | indeed it isnt |
10:33:49 | wodz | coming back to hosted platform - what do you think is better: 1) wrapping just fopen() (as we do for open() in hosted env) 2) proceed as I proposed on g# which means consistency between hosted and native but probably slower |
10:34:11 | kugel | I think an extra header file is okay (so porting effort is down from changing every call site just one line), but the underscores shouldnt be needed? |
10:35:07 | wodz | If I wrap fopen() to fix path problems we could drop underscores and NOT compile wrapper for hosted targets |
10:35:22 | kugel | with 1) we woud only wrap fopen() and the other function would be taken from the host? |
10:35:47 | wodz | yes this should work AFAIK |
10:35:54 | kugel | sounds better to me, yes |
10:36:00 | wodz | ok, will try |
10:38:11 | kugel | fwiw, I thought if it might be useful in the core too (but with buffering) |
10:38:31 | kugel | but it's harder to implement and probably not worth it |
10:40:03 | wodz | I don't think we need this in core. |
10:40:20 | wodz | Not that much external code is ported to the core |
10:40:39 | kugel | but the buffering could boost performance in some areas |
10:41:34 | wodz | but this wrappers do not provide buffering at all! |
10:41:45 | kugel | that's why I said "(but with buffering)" |
10:41:51 | wodz | ah ok |
10:42:04 | wodz | we relay on buffering on fs level |
10:43:32 | wodz | is enough to precede the path with ROCKBOX_DIR in case of hosted? |
10:43:38 | wodz | *is it |
10:45:01 | kugel | no |
10:45:48 | kugel | firmware/common/rbpaths.c has it for open() |
10:45:56 | * | wodz reading |
10:47:11 | wodz | hell, that is more complicated |
10:47:58 | kugel | could export these the functions to plugins |
10:49:28 | kugel | if you call handle_special_dir() from the fopen() warpper it should just work |
10:52:00 | wodz | handle_special_dir() is static |
10:54:49 | kugel | that can be changed |
10:56:59 | wodz | looking at it I am no more sure it is worth the hassle |
10:57:22 | wodz | the current code on gerrit is quite simple after all |
10:57:34 | kugel | what hassle? |
10:57:53 | kugel | if you export this function then you need 15 lines of fopen(), and that's about it |
11:00 |
11:00:12 | wodz | export like unstatic it and add to plugin api? |
11:00:19 | kugel | yea |
11:04:00 | wodz | well since we do not care much for plugins on hosted platforms is it really worth expanding plugin api? There is no other use for this function I can think of |
11:04:52 | kugel | it is, IMO |
11:05:39 | kugel | the api is full of function that were added for a single plugin (and our policy is that adding a function is not a deal) |
11:07:00 | wodz | thats one of this polices which are not written down :-) |
11:07:22 | kugel | most of our policies are implicit unfortunately |
11:08:05 | wodz | Anyway I see your point but I am not convinced thats the way to do. |
11:09:24 | wodz | we could export this function only for hosted platforms |
11:09:40 | wodz | that would make more sense |
11:10:12 | kugel | yes, sorry I didn't say that but I was thinking that since the beginning |
11:10:21 | kugel | since it doesnt exist yet for non-hosted :) |
11:12:42 | wodz | what are the flags? |
11:12:56 | kugel | #if (CONFIG_PLATFORM & PLATFORM_HOSTED) |
11:15:03 | kugel | oh hmm, actually it exists only for APPLICATION |
11:16:34 | | Quit Unhelpful (Ping timeout: 248 seconds) |
11:16:41 | wodz | it seems like NEED_WRITE is only needed in fopen() case right? |
11:18:05 | kugel | what do you mean? |
11:18:19 | kugel | it depends on the flags that are passed to fopen |
11:18:47 | | Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) |
11:19:01 | wodz | yes, but I don't need to specially check for file (IS_FILE) no? |
11:19:37 | kugel | can you fopen() dirs? |
11:20:07 | wodz | probably no |
11:20:19 | kugel | open also sets IS_FILE unconditionally |
11:21:10 | wodz | "The fopen() function opens the file whose name is the string pointed to by path and associates a stream with it." So you cannot fopen dir |
11:22:56 | | Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) |
11:24:43 | wodz | kugel: why is YPR0 en exception in many places? |
11:25:37 | kugel | it doesnt map <HOME> to the real home |
11:25:53 | kugel | for the YPR0 the real home is known at compile time |
11:30:52 | kugel | if it's too much hassle for you now you can leave it alone, perhaps I can do the rest at a later time |
11:31:27 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
11:35:51 | | Quit n1s (Ping timeout: 252 seconds) |
11:36:37 | | Join ender` [0] (~ender@foo.eternallybored.org) |
11:38:09 | | Quit ender` (Read error: Connection reset by peer) |
11:38:20 | | Join ender` [0] (~ender@foo.eternallybored.org) |
11:50:51 | wodz | kugel: rbpaths.c is not compiled for sim :/ |
11:53:58 | *** | Saving seen data "./dancer.seen" |
11:54:03 | | Quit pretty_function (Remote host closed the connection) |
12:00 |
12:07:58 | | Join pretty_function [0] (~sigBART@123.252.212.253) |
12:30:59 | | Quit dfkt_ (Ping timeout: 248 seconds) |
12:40:38 | JdGordon | [Saint]: how does the .icons file work? |
12:40:46 | JdGordon | how do you set the setting? |
12:44:30 | | Join Wardo [0] (~Mirandaha@bpb01-1-88-162-4-186.fbx.proxad.net) |
12:55:48 | | Join y4n [0] (~y4n@unaffiliated/y4ndexx) |
13:00 |
13:10:20 | kugel | wodz: yes, I found that too |
13:10:22 | kugel | :( |
13:10:40 | kugel | I forgot that sims io is wrapped in yet another place |
13:17:30 | kugel | uhh, I have a song that exposes heavy distortion under rockbox, but plays fine with vlc |
13:17:41 | kugel | on RaaA |
13:19:31 | kugel | android is fine, seems to be either an issue with my laptop or the C code of the codec (android uses asm optimzed code) |
13:19:54 | | Quit pretty_function (Remote host closed the connection) |
13:32:25 | | Quit ender` (Ping timeout: 240 seconds) |
13:39:02 | | Join ender` [0] (~ender@foo.eternallybored.org) |
13:39:55 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
13:53:59 | *** | Saving seen data "./dancer.seen" |
14:00 |
14:03:01 | | Quit wodz (Quit: Leaving) |
14:29:28 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
14:41:12 | | Join lorenzo92 [0] (~chatzilla@host62-106-dynamic.41-79-r.retail.telecomitalia.it) |
14:43:26 | lorenzo92 | kugel: remaining in the discussion of hosted platforms, I notice that under YPR0 memory isn't used enough, to express that better, I get a "no enough plugin memory" while trying to open some image files, also if there is a plenty of ram still to be used at any time (~12 mb if I correctly recall) |
14:44:29 | lorenzo92 | moreover, HOME folder isn't mapped since we simply do a symlink at startup to /.rockbox -> /mnt/media0/.rockbox |
14:48:20 | lorenzo92 | kugel: is this song affecting YPR0 too? |
14:49:23 | | Join prof_wolfff [0] (~prof_wolf@62.83.50.196.dyn.user.ono.com) |
14:54:51 | pamaury | saratoga: can you post the code you used to process the rds data ? |
14:55:38 | kugel | lorenzo92: I wouldnt think so (re: the song) |
14:59:44 | lorenzo92 | kugel: and about plugin buffers? Can we somehow increase its size? |
15:00 |
15:01:24 | kugel | which plugin did you run? |
15:01:49 | kugel | ah, imageviewer |
15:02:15 | kugel | should be 512k (as for every target) |
15:02:40 | gevaerts | Doesn't imageviewer grab the audio buffer if it needs to? |
15:03:37 | gevaerts | grep says it should |
15:04:38 | lorenzo92 | kugel: uh oh! only 512k, no I understand...hum |
15:04:43 | lorenzo92 | ah yeah can be |
15:04:56 | lorenzo92 | in fact when a song is playing chances to get this error are higher |
15:05:05 | gevaerts | That's weird |
15:05:21 | lorenzo92 | indeed |
15:05:37 | gevaerts | If it doesn't have enough memory for an image it should stop playback and grab the audio buffer, possibly after asking |
15:06:23 | lorenzo92 | but in any case, why no other ram is being used if the target has still much to give? hum I need to learn how buffers are allocated in rb ^^ |
15:07:09 | gevaerts | How much RAM does the device have, and how big is the audio buffer? |
15:07:18 | kugel | lorenzo92: for RaaA there's a large static array (MEMORYSIZE mb big), other allocations are made from this array |
15:07:33 | lorenzo92 | ok |
15:07:53 | kugel | increasing MEMORYSIZE should work but keep in mind that the OS (and other processes, if any) also need some spare memory |
15:11:58 | gevaerts | Also, I'd assume linux does some readahead, so there's a good chance the "wasted" memory will avoid some disk accesses anyway |
15:13:52 | lorenzo92 | gevaerts: can be, but 12 mb are still free, well I have a look right now through uart |
15:13:56 | lorenzo92 | just a second |
15:14:17 | gevaerts | Actually, on RaaA I'd say we should look into redoing the audio buffer to mmap() the files instead, combined with careful use of madvise() :) |
15:14:28 | * | gevaerts waits for a volunteer to step up for that |
15:15:07 | lorenzo92 | I will have time for this in february ;) |
15:15:15 | lorenzo92 | while porting R1 |
15:15:54 | lorenzo92 | and indeed optimizations for RaaA are necessary, since there are lot of possibilities related to it |
15:16:52 | kugel | gevaerts: what would we gain? |
15:17:20 | lorenzo92 | uh! stopping the process makes the alsa wrapper crash or something like that |
15:17:24 | lorenzo92 | just to say ;) |
15:17:58 | lorenzo92 | right now: MemTotal: 62416 kB |
15:18:00 | lorenzo92 | MemFree: 12532 kB |
15:18:09 | gevaerts | kugel: if things are properly tuned, optimal RAM use (the audio buffer wouldn't be fixed size any more, effectively). If things are not properly tuned, lower battery life, probably :) |
15:18:47 | gevaerts | lorenzo92: is this just after boot, or during playback? |
15:18:57 | lorenzo92 | during playback |
15:19:11 | gevaerts | Do you have swap? |
15:19:19 | kugel | the ypr0 build has MEMORYSIZE=32 currently, iirc |
15:19:24 | lorenzo92 | no swap |
15:19:58 | lorenzo92 | killing rockbox, we have 39956kb free |
15:20:11 | gevaerts | What sort of numbers do you have for Buffers and Cached? |
15:20:24 | lorenzo92 | let me do a pastebin |
15:21:05 | gevaerts | Without swap you have to be careful, since OOM is rather easy to trigger |
15:23:24 | gevaerts | Do you have the blockdev tool? Playing with the filesystem readahead values might be a good way to increase RAM efficiency without increasing MEMORYSIZE (and therefore without increasing OOM risk) |
15:23:30 | lorenzo92 | http://pastebin.com/jwDXGXes |
15:24:20 | gevaerts | Hmm |
15:24:23 | lorenzo92 | so it appears the allocation is done dynamically (correct) but is limited (not correct) |
15:25:15 | kugel | well, it's a static array from rockbox perspective |
15:25:27 | gevaerts | I'd say the way rockbox works today, linux caching is not very useful |
15:25:29 | kugel | how linux allocates it on process launch is a different story |
15:26:31 | gevaerts | So I'd say increasing MEMORYSIZE to 48 or something like that might be worth a try |
15:26:32 | lorenzo92 | it does copy-on-write I guess before executing |
15:26:46 | lorenzo92 | gevaerts, yes I can |
15:28:05 | gevaerts | Of course you really need a battery bench for each setting you try :) |
15:28:32 | * | kugel doubts the effect is een measurable |
15:29:00 | gevaerts | I'd say what you want is the linux directory cache, but not the linux page cache, since we have our own system for that |
15:29:54 | lorenzo92 | ok interesting |
15:30:04 | lorenzo92 | so I should disable caching? |
15:30:19 | kugel | well, i would leave a small page cache |
15:30:24 | | Join TheSphinX_ [0] (~briehl@p579CCF52.dip.t-dialin.net) |
15:31:20 | gevaerts | Well, not disable, just don't give it as much. |
15:31:23 | lorenzo92 | kugel: indeed, just lowering it...let me see in /proc/vm |
15:31:55 | gevaerts | And without swap, one easy way to do that is grabbing more for rockbox :) |
15:32:04 | | Quit TheSphinX_ (Read error: Operation timed out) |
15:33:03 | | Quit TheSphinX^ (Ping timeout: 248 seconds) |
15:34:30 | lorenzo92 | gevaerts: nice, thanks for the hint! dropping caches frees a plenty of ram |
15:35:02 | lorenzo92 | i.e. echo 1 > /proc/sys/vm/drop_caches |
15:35:47 | kugel | it doesnt necessarily let us operate more effeciently though |
15:36:04 | gevaerts | Well, dropping caches at some interval won't |
15:36:22 | lorenzo92 | no I need to set it indeed |
15:36:25 | | Join TheSphinX_ [0] (~briehl@p5B323C0F.dip.t-dialin.net) |
15:36:46 | gevaerts | Currently we're probably caching lots of stuff twice though, once in the audio buffer, and once (because it's been read recently) in the page cache |
15:37:03 | lorenzo92 | indeed |
15:37:03 | gevaerts | During normal use we're unlikely to read that data again |
15:37:50 | | Join VanniX [0] (~VanniX@host242-69-dynamic.49-82-r.retail.telecomitalia.it) |
15:37:50 | lorenzo92 | and in any case hw is fast enough :D |
15:37:58 | gevaerts | So I'd say either we reduce the audio buffer and tell the kernel to aggressively read ahead (so we use the page cache as the main buffer), or we increase the audio buffer and thereby effectively tell the kernel not to cache so much |
15:38:30 | lorenzo92 | I'd prefer the second, rockbox controls the device after all :D |
15:38:38 | kugel | I think the former is not very smart, unless we can give linux our playlist to readahead? :) |
15:38:39 | gevaerts | The first needs research, the second is easy to try :) |
15:39:05 | gevaerts | kugel: we can, if we want to. There's the readahead() system call |
15:39:40 | gevaerts | I'd go for a larger MEMORYSIZE first though |
15:39:45 | kugel | okay, but we have the code that does the same in place already |
15:39:58 | gevaerts | Exactly |
15:40:20 | lorenzo92 | I'm building a 48 mb build |
15:41:08 | gevaerts | Hmmm |
15:41:12 | kugel | if a 32mb build has 12mb free 48mb isn't going to work well, but worth a try |
15:41:39 | lorenzo92 | kugel: it should, since freeing buffers seems freeing lot of memory |
15:41:41 | gevaerts | kugel: that 12mb doesn't include the (imo useless) cache |
15:41:58 | gevaerts | So those 12mb are *really* wasted and not even duplicates |
15:42:47 | lorenzo92 | yes, exactly |
15:42:59 | lorenzo92 | free memory |
15:43:15 | kugel | bt 48mb - 32mb is also more than 12mb :) |
15:43:23 | gevaerts | Yes |
15:43:51 | lorenzo92 | yes I tought the same, but kernel should be smart enough or? |
15:43:55 | gevaerts | The page cache also eats more than it should |
15:43:55 | kugel | the paste shows linux has 40mb free before launching rockbox |
15:44:29 | gevaerts | Yes, but it has lots of data in cache (and cache is *not* counted in those 40mb) that we likely won't ever need again |
15:45:02 | kugel | how do you tell which cache to prioritize? |
15:45:07 | gevaerts | You can't |
15:45:08 | kugel | tell linux* |
15:45:21 | gevaerts | Well... |
15:45:27 | gevaerts | You can, but not without code |
15:45:48 | gevaerts | I'm not sure we really need any cache though |
15:46:02 | kugel | directory cache is nice to have |
15:46:04 | gevaerts | Which other processes are running? |
15:46:12 | gevaerts | True |
15:46:37 | * | gevaerts decides to ask google for help |
15:46:55 | VanniX | gevaerts, in linux? |
15:47:06 | gevaerts | yes |
15:47:23 | VanniX | wait, i can paste a ps |
15:47:35 | gevaerts | VanniX: on yp-r0 |
15:47:44 | VanniX | yep |
15:47:48 | gevaerts | ok |
15:48:07 | VanniX | http://pastebin.com/yK8yhULx |
15:48:19 | lorenzo92 | as you see, nothing :D |
15:48:28 | gevaerts | OK, so not much :) |
15:49:16 | gevaerts | So yes, what we ideally need to do is tell the kernel that the directory cache is important, the page cache is not |
15:49:17 | VanniX | http://pastebin.com/Pyq0m6SV <−− ps -l |
15:50:47 | lorenzo92 | I'm trying the 48 mb build in a few |
15:51:09 | gevaerts | hmmm |
15:51:12 | VanniX | Mem: 23780K used, 38648K free, 0K shrd, 5392K buff, 11552K cached |
15:53:48 | gevaerts | kugel: have a look at posix_fadvise(). We could (should?) call that for buffer filling with I think POSIX_FADV_SEQUENTIAL and POSIX_FADV_NOREUSE, and possibly POSIX_FADV_DONTNEED just before closing |
15:54:00 | *** | Saving seen data "./dancer.seen" |
15:54:23 | lorenzo92 | VanniX: you need to play a fikle |
15:54:35 | gevaerts | That doesn't prioritise the directory cache as such, but with any luck it should help |
15:54:35 | VanniX | ok :P |
15:54:36 | lorenzo92 | otherwise buffer isn't counted ;) |
15:55:17 | VanniX | Mem: 49808K used, 12620K free, 0K shrd, 120K buff, 11164K cached |
15:55:18 | VanniX | ;) |
15:56:59 | lorenzo92 | VanniX: the usb uart cable is great :D |
15:57:12 | gevaerts | lorenzo92: do you have vmstat on the ypr0? If so, running "vmstat 1" (or some higher number if you like) and watching bi and bo should show io patterns which might correlate with disk spinups, which might avoid lengthy battery benches :) |
15:57:52 | gevaerts | Of course, running tools also impacts free memory, so you might want to adjust MEMORYSIZE a bit to compensate :) |
15:59:24 | VanniX | lorenzo92, now i'm with physical uart XD |
15:59:29 | lorenzo92 | okay 48 mb is not good |
15:59:53 | lorenzo92 | VanniX: I mean, physical through usb |
16:00 |
16:00:47 | lorenzo92 | gevaerts: no vmstat |
16:01:21 | lorenzo92 | I try with 40 mb |
16:02:28 | lorenzo92 | okay one thing is clear |
16:02:49 | lorenzo92 | without dropping cache we have ~43mb, after ~55! |
16:03:02 | lorenzo92 | so lowering caching is a good point to do |
16:04:22 | lorenzo92 | maybe I need to tune /proc/sys/vm/vfs_cache_pressure ? |
16:04:48 | gevaerts | There are *many* things you can tune... |
16:05:04 | lorenzo92 | yeah that's why I ask :D |
16:05:12 | * | gevaerts doesn't even want to guess which ones to try first :) |
16:09:33 | kugel | lorenzo92: what happened? |
16:09:55 | lorenzo92 | kugel: simply gets Killed |
16:10:45 | kugel | that likely means not enogh memory to even start rockbox |
16:11:15 | * | kugel got confused a lot by this message during gsoc |
16:13:24 | lorenzo92 | lorenzo92: also gets confused by virtual memory tunin' |
16:15:29 | | Quit Wardo (Read error: Connection reset by peer) |
16:16:27 | | Join TheSphinX^ [0] (~briehl@p579CC089.dip.t-dialin.net) |
16:19:22 | | Quit TheSphinX_ (Ping timeout: 244 seconds) |
16:20:11 | lorenzo92 | okay I need to go, I will go deep into this, very interesting! I want to get my 12 mb that are left alone!! XD |
16:23:07 | | Quit lorenzo92 (Quit: ChatZilla 0.9.89 [Firefox 18.0/20130107224849]) |
16:26:13 | | Join esperegu [0] (~quassel@ip-213-124-221-122.ip.prioritytelecom.net) |
16:41:31 | | Join bertrik [0] (~quassel@89.200.34.39) |
16:41:31 | | Quit bertrik (Changing host) |
16:41:31 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
16:43:34 | | Quit esperegu (Read error: Connection reset by peer) |
16:43:52 | | Join ztf [0] (~53172d43@www.haxx.se) |
16:44:06 | | Join esperegu [0] (~quassel@ip-213-124-221-122.ip.prioritytelecom.net) |
16:44:12 | ztf | hello |
16:45:04 | ztf | is clip v1 hanging a known issue? |
16:45:28 | pamaury | bertrik: I made some progress on the stfm1000 radio as you heard ! |
16:45:45 | bertrik | nice |
16:46:37 | pamaury | I can successfully get sound. stereo/mono indicator doesn't seem to work or is unimplemented. And I'm looking at RDS. |
16:47:00 | pamaury | Actually your work was amazing, I only needed to fix the dri code |
16:47:35 | gevaerts | ztf: when does it hang? There are some known issues with USB for some people |
16:47:42 | gevaerts | Also, which version? |
16:47:58 | ztf | 3.1.2 |
16:48:01 | ztf | clip v1 |
16:48:12 | * | gevaerts assumes 3.12 |
16:48:13 | ztf | it hangs during playback |
16:48:33 | gevaerts | There was no 3.1.2, and if there had been, it would have been years ago :) |
16:48:34 | ztf | requires a hard reset |
16:48:51 | gevaerts | I'd suggest checking the filesystem for errors |
16:48:54 | bertrik | pamaury: I took the existing code and tried to simplify it, but never got further than digital noise from it :) |
16:49:10 | ztf | hm |
16:49:31 | ztf | 3.12 oops |
16:49:34 | ztf | anyway |
16:50:06 | pamaury | I had to change the way dri was enabled. A comment in the linux code said that if the clock was enabled too late you would get noise. I also implemented a correct double buffering scheme and now it works. The code is still ugly but I'll fix that. |
16:50:09 | ztf | how would one go about checking the filesystem? |
16:50:32 | ztf | i moved my music after installing rockbox btw |
16:50:45 | gevaerts | Which OS do you use? |
16:50:53 | ztf | linux atm |
16:51:38 | gevaerts | OK, fsck.vfat /dev/sd<something>1 |
16:51:57 | kugel | pamaury: what means dri in this context? |
16:52:07 | pamaury | digital radio interface |
16:52:13 | pamaury | a propriatery saif if you prefer |
16:52:17 | pamaury | :) |
16:52:29 | ztf | aight ill give it a try |
16:52:39 | * | kugel doesn't know about either, but thanks |
16:52:57 | pamaury | it's a serial audio interface, so you can transport sound in digital form |
16:53:40 | n1s | the radio outputs digital audio? |
16:53:46 | pamaury | yes |
16:53:54 | n1s | interesting |
16:54:23 | pamaury | and dri is a bit special in that it includes some synchronisation bits in the stream so that the SoC doesn't get lost, that's all basically |
16:55:02 | pamaury | and the streams is multiplexing four channels: L+R, L-R, RSSI and RDS |
16:55:38 | ztf | dosfsck 3.0.12, 29 Oct 2011, FAT32, LFN /dev/sdb1: 84 files, 16178/120752 clusters |
16:55:52 | ztf | doesnt seem to tell much : / |
16:56:38 | | Join zaphee [0] (~user@ede67-2-82-232-36-5.fbx.proxad.net) |
16:58:11 | bertrik | pamaury: I think it wasn't entirely clear to me what the sample rate of the digital audio was, or how to configure it |
16:58:12 | gevaerts | 84 files? That doesn't sound right |
16:58:46 | ztf | hmm now that i think about it.. |
16:58:52 | ztf | i've got 99 tracks on it atm |
16:59:33 | pamaury | bertrik: you cannot really configure it, you can tweak the serial interface speed (because you can actually multiplex more or less than 4 channels) but in all cases the sounds is sampled at 44.1kS/s and rds is sampled at 38kS/s |
16:59:56 | gevaerts | .rockbox has around 250 files in it as well |
17:00 |
17:00:30 | ztf | : S |
17:01:22 | | Join XavierGr [0] (~xavier@rockbox/staff/XavierGr) |
17:02:06 | gevaerts | You could try running it with -v. Maybe that says something useful |
17:02:16 | gevaerts | Possibly even -l |
17:03:33 | ztf | oh boy, wrong device lol sorry |
17:03:40 | ztf | thats my sdhc card |
17:03:50 | ztf | /facepalm |
17:03:51 | gevaerts | That would explain things :) |
17:05:49 | ztf | /dev/sdc: 538 files, 53613/62375 clusters |
17:07:09 | ztf | Reclaimed 161 unused clusters (5275648 bytes). |
17:08:09 | ztf | FATs differ but appear to be intact. Use which FAT ? and theres this question |
17:08:37 | gevaerts | That's basically just guessing. It's not possible to know which one is correct... |
17:08:59 | ztf | i tried both |
17:09:20 | ztf | perhaps i should try performing -r? |
17:10:08 | gevaerts | hmm |
17:10:36 | gevaerts | Unless you know FAT quite well, I suspect that's not really going to be very helpful |
17:11:37 | gevaerts | If you have backups of everything, I'd actually recommend -a instead :) |
17:12:15 | ztf | aight, lets do it : P |
17:13:50 | ztf | Performing changes. |
17:13:51 | ztf | oh well |
17:13:59 | ztf | thats not very informative |
17:14:04 | ztf | guess it didnt do anyting |
17:14:28 | gevaerts | You could run it again. If it doesn't see the errors any more, it did something |
17:14:54 | ztf | there was no Performing changes. this time |
17:15:10 | ztf | yeah here's hoping it did its magic |
17:15:32 | gevaerts | Anyway, the rockbox FAT code isn't as resilient as it should be against even slight filesystem corruption, so repairing the filesystem often fixes random issues |
17:15:45 | ztf | I see |
17:16:25 | ztf | well, thanks for assistance |
17:16:31 | ztf | = ) |
17:16:57 | ztf | bb |
17:16:59 | | Quit ztf (Quit: CGI:IRC) |
17:22:49 | | Quit XavierGr (Disconnected by services) |
17:22:51 | | Join XavierGr [0] (XavierGr@rockbox/staff/XavierGr) |
17:30:15 | | Quit zaphee (Quit: Leaving.) |
17:31:13 | | Join zaphee [0] (~user@ede67-2-82-232-36-5.fbx.proxad.net) |
17:32:14 | | Quit XavierGr (Disconnected by services) |
17:32:15 | | Join XavierGr [0] (~xavier@rockbox/staff/XavierGr) |
17:32:38 | | Join eckoit [0] (~ryan@50.65.10.24) |
17:41:57 | | Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) |
17:44:05 | | Part eckoit |
17:50:33 | | Quit bertrik (Ping timeout: 260 seconds) |
17:54:01 | *** | Saving seen data "./dancer.seen" |
18:00 |
18:19:53 | | Join wodz [0] (~wodz@89-76-32-53.dynamic.chello.pl) |
18:20:11 | wodz | is there a way to force compilation of 32bit sim on 64bit system? |
18:20:42 | funman | CC='gcc -m32' maybe? |
18:20:56 | wodz | you mean in root Makefile? |
18:21:08 | funman | for example yeah |
18:23:39 | wodz | it doesn't link this way |
18:23:54 | wodz | objects are 32bit though |
18:24:30 | kugel | -m32 should be sufficient, tried a make clean? |
18:24:33 | funman | hm 'gcc' is used for linking instead of gcc -m32? |
18:24:42 | funman | libSDL 32bits is missing / not found? |
18:26:12 | wodz | it barfs on 1) tons of something like this: libuisimulator.a(buttonmaps.o)' is incompatible with i386:x86-64 output 2) undefined reference to `__divdi3' /__udivdi3 |
18:26:21 | wodz | and yes I did make clean |
18:26:57 | wodz | -m32 is not passed to gcc when linking |
18:31:20 | | Quit thomasjfox (Quit: Konversation terminated!) |
18:34:01 | pamaury | wodz: you need the 32-bit version of the libraries |
18:34:20 | pamaury | mainly pthread and sdl I think |
18:35:47 | pamaury | and I would put -m32 in GCCOPTS and LDOPTS |
18:36:47 | wodz | I leave it as installing 32bit of SDL is trying to wipe out half of my system |
18:37:18 | kugel | no multiarch? |
18:39:56 | wodz | well I have quite a few 32bit programs installed and ubuntu should be smart enough so I don't know why it is so |
18:40:25 | wodz | anyway I am quite close to have functional forth kernel running as plugin :-) |
18:40:26 | funman | wodz: you are on debian? |
18:40:38 | wodz | ubuntu (xubuntu to be precise) |
18:40:46 | funman | do you have gcc-multilib? |
18:40:55 | wodz | yep |
18:41:28 | kugel | wodz: how are you installing sdl? apt-get install libsdl1.2:i386? |
18:41:53 | kugel | that should work since 11.10 or 12.04 |
18:42:37 | | Join AndChat|198900 [0] (~AndChat19@c-65-96-172-84.hsd1.ma.comcast.net) |
18:43:49 | AndChat|198900 | Pamaury: can you check that post on the zen in the new ports forum? |
18:44:04 | pamaury | ok |
18:44:21 | AndChat|198900 | (Saratoga on phone ) |
18:46:54 | pamaury | about "Creative ZEN" ? |
18:47:29 | AndChat|198900 | Yeah |
18:47:49 | AndChat|198900 | Iirc its a sigmatel very similar to the imx |
18:48:16 | pamaury | indeed, and the ZEN is very similar to the ZEN X-Fi which I own, iirc |
18:49:10 | pamaury | ok, I'll post an answer as soon as this internet connection becomes again, I cannot even load the forum page |
18:49:51 | wodz | kugel: hmm, I tried to install libsdl1.2-dev:i386 - maybe thats the problem |
18:50:04 | | Quit AndChat|198900 (Quit: Bye) |
18:50:32 | kugel | hm that should probably work as well |
19:00 |
19:24:53 | | Quit the-kyle (Read error: Connection reset by peer) |
19:25:00 | | Join the-kyle [0] (~kyle@cpe-024-211-185-030.nc.res.rr.com) |
19:26:22 | | Quit n1s (Quit: Ex-Chat) |
19:28:58 | | Quit wodz (Quit: Leaving) |
19:28:58 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
19:54:04 | *** | Saving seen data "./dancer.seen" |
20:00 |
20:12:21 | | Join TheSphinX_ [0] (~briehl@p5B323F6F.dip.t-dialin.net) |
20:13:25 | | Quit TheSphinX^ (Ping timeout: 240 seconds) |
20:14:22 | | Join TheSphinX^ [0] (~briehl@p5B32363D.dip.t-dialin.net) |
20:17:30 | | Quit TheSphinX_ (Ping timeout: 245 seconds) |
20:18:52 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
20:23:50 | | Join SuperBrainAK [0] (~Andy@71-36-165-101.phnx.qwest.net) |
20:31:56 | | Join TheSphinX_ [0] (~briehl@p5B3217ED.dip.t-dialin.net) |
20:34:08 | | Quit TheSphinX^ (Read error: Operation timed out) |
20:40:56 | | Quit Raptors (Ping timeout: 245 seconds) |
20:42:37 | | Quit TheSphinX_ (Ping timeout: 245 seconds) |
20:43:01 | | Join Raptors [0] (~whoneedsa@216-58-33-195.cpe.distributel.net) |
20:45:55 | | Join TheSphinX^ [0] (~briehl@p5B3217ED.dip.t-dialin.net) |
20:48:17 | | Join lebellium_ [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) |
20:49:39 | | Join lebellium__ [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) |
20:50:05 | saratoga | pamaury: http://pastebin.com/mHNKq5Gq |
20:50:09 | saratoga | sorry for matlab |
20:50:27 | | Quit lebellium__ (Read error: Connection reset by peer) |
20:50:55 | | Quit lebellium (Ping timeout: 248 seconds) |
20:50:58 | | Join lebellium__ [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) |
20:51:12 | | Nick lebellium__ is now known as lebellium (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) |
20:51:12 | saratoga | basically, a really long (2^14 point) bandpass filter to pull out the carrier, then multiply the signal times that to see if its in phase or out of phase |
20:51:25 | saratoga | probably need some more filtering in there to clean up noise |
20:51:55 | | Join TheSphinX_ [0] (~briehl@p5B3226FA.dip.t-dialin.net) |
20:52:45 | | Quit lebellium_ (Ping timeout: 252 seconds) |
20:54:27 | | Quit TheSphinX^ (Ping timeout: 248 seconds) |
21:00 |
21:09:18 | | Join Wardo [0] (~Mirandaha@176-120-190-109.dsl.ovh.fr) |
21:12:02 | | Quit esperegu (Ping timeout: 248 seconds) |
21:21:14 | | Quit y4n (Quit: Do you like hurting other people?) |
21:21:46 | | Quit TheSphinX_ (Ping timeout: 264 seconds) |
21:27:06 | | Quit saratoga (Ping timeout: 245 seconds) |
21:34:58 | | Join TheSphinX^ [0] (~briehl@91.50.47.76) |
21:54:05 | *** | Saving seen data "./dancer.seen" |
21:56:11 | | Join stripwax [0] (~Miranda@rockbox/developer/stripwax) |
22:00 |
22:01:14 | | Quit akaWolf (Ping timeout: 256 seconds) |
22:08:02 | | Quit SuperBrainAK (Ping timeout: 248 seconds) |
22:16:30 | | Join TheSphinX_ [0] (~briehl@p5B321AE9.dip.t-dialin.net) |
22:19:52 | | Quit TheSphinX^ (Ping timeout: 252 seconds) |
22:25:54 | | Join Honkboy [0] (~quassel@pD9EB2B17.dip.t-dialin.net) |
22:27:38 | | Quit TheSphinX_ (Ping timeout: 260 seconds) |
22:28:44 | | Quit Honkboy (Remote host closed the connection) |
22:31:31 | | Join TheSphinX^ [0] (~briehl@p5B323B98.dip.t-dialin.net) |
22:34:09 | | Join Strife89 [0] (~Strife89@207.144.201.128) |
22:34:12 | | Quit nateloaf (Quit: Leaving.) |
22:34:31 | | Join TheSphinX_ [0] (~briehl@p5B323BFC.dip.t-dialin.net) |
22:36:32 | | Join TheSphin- [0] (~briehl@p579CCAF5.dip.t-dialin.net) |
22:37:15 | | Quit TheSphinX_ (Read error: Operation timed out) |
22:37:35 | | Quit TheSphinX^ (Ping timeout: 248 seconds) |
22:41:43 | | Join lorenzo92 [0] (~chatzilla@host71-108-dynamic.4-87-r.retail.telecomitalia.it) |
22:48:02 | | Join TheSphinX^ [0] (~briehl@p579CCB17.dip.t-dialin.net) |
22:51:16 | | Quit TheSphin- (Ping timeout: 276 seconds) |
22:52:02 | | Join TheSphinX_ [0] (~briehl@p5B322AAC.dip.t-dialin.net) |
22:55:00 | | Quit TheSphinX^ (Ping timeout: 252 seconds) |
22:56:46 | | Quit stripwax (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
23:00 |
23:07:16 | [Saint] | JdGordon: Awesome work on the .icons file |
23:07:33 | [Saint] | (and viewers.config, but that is a whole mess of broken) |
23:11:05 | JdGordon | thats a nasty file to work in! :) |
23:11:12 | JdGordon | filetypes.c i mean |
23:16:07 | pamaury | why ? |
23:16:25 | [Saint] | It is, yes. I''m a little bit more savvy than I was the last time I looked there though. |
23:16:36 | [Saint] | I may not run out screaming this time. |
23:21:16 | | Join SuperBrainAK [0] (~Andy@71-36-165-101.phnx.qwest.net) |
23:21:26 | | Quit melmothX (Remote host closed the connection) |
23:24:13 | | Join Scromple [0] (~Simon@161.43.73.67) |
23:24:46 | pamaury | it doesn't look that bad imo |
23:47:12 | | Quit zaphee (Quit: Leaving.) |
23:54:07 | *** | Saving seen data "./dancer.seen" |
23:55:39 | | Join eckoit [0] (~ryan@50.65.10.24) |
23:55:45 | evilnick | [Saint]: Any idea where I should put the contents of a theme.zip for RaaAa? |
23:56:10 | [Saint] | I assume the device doesn't have a dedicated sdcard? |
23:56:29 | [Saint] | does /storage0 symlink to /sdcard or so? (it should) |
23:56:50 | evilnick | Yes, and yes |
23:57:24 | [Saint] | Right, it goes in "/sdcard" then. |
23:57:36 | [Saint] | (whereever that actually is, be it virtual or no) |
23:57:59 | evilnick | Sweet, I think I've got it - is there a cabbiev2 as part of the .apk? |
23:58:39 | [Saint] | There is, but it should be ignored. |
23:58:48 | [Saint] | Oh, depends on the res actually. |
23:58:52 | [Saint] | there may well not be. |