00:03:32 | kugel | lorenzo92 (logs): found the problem with my patch |
00:03:53 | kugel | I didn't know queue_wait_w_tmo() cannot take TIMEOUT_BLOCK |
00:12:31 | | Part amayer |
00:28:07 | | Quit Wardo (Read error: Connection reset by peer) |
00:37:05 | | Quit ender` (Quit: One of my moneymaking ideas is to write a virus, and copyright it, and sue everyone who gets infected. Impossible? Just like GMO crops! -- AndyCanfield) |
00:37:34 | | Quit mgottschlag (Ping timeout: 244 seconds) |
00:44:52 | | Join eckoit_ [0] (~ryan@96.53.108.182) |
00:45:36 | | Quit eckoit (Ping timeout: 255 seconds) |
00:45:36 | | Nick eckoit_ is now known as eckoit (~ryan@96.53.108.182) |
00:50:56 | | Quit Thra11 (Ping timeout: 252 seconds) |
01:00 |
01:11:27 | | Quit eckoit (Quit: eckoit) |
01:20:39 | | Quit sakax (Quit: Leaving) |
01:23:42 | | Join eckoit [0] (~ryan@50.65.10.24) |
01:30:36 | | Join sansaclipzip [0] (~32352e52@www.haxx.se) |
01:32:35 | sansaclipzip | does anyone know how to fix the "undefined instru" white screen on sansa clip zip? looked online and didn't find anything |
01:32:46 | sansaclipzip | happens when I plug into USB |
01:34:05 | | Nick scorche` is now known as scorche (~scorche@rockbox/administrator/scorche) |
01:38:35 | | Quit n1s (Quit: Ex-Chat) |
01:39:41 | [Saint] | sansaclipzip: the rest of the error screen would (possibly) be more helpful that a partial error. |
01:39:58 | [Saint] | also, the exact revision as reported by rockboxinfo would be nice too. |
01:40:25 | [Saint] | s/that a/than a/ |
01:44:24 | sansaclipzip | thanks. but the error does not display completely, that's all that I get. and sorry, how can I find the revision? |
01:45:33 | [Saint] | that's really all you're getting? "undefined instru"? There should be at least one other line with the address of the instruction. |
01:45:36 | [Saint] | that's, odd. |
01:46:28 | [Saint] | The revision isn't really all that useful if it cvan't be aligned with a map file to find where it's failing. That's a shame. |
01:48:31 | sansaclipzip | i just get a white blinking screen with "undefined instru"..this has happened before and resolved itself, could it be because I didn't safely remove the player from the USB? |
01:49:11 | [Saint] | That could be it, yes. That is something you should never do. |
01:49:18 | [Saint] | ...with any removable storage. |
01:49:20 | [Saint] | ever :) |
01:50:12 | sansaclipzip | haha yeah, I guess I've learned that now. just too lazy spend 5 seconds to safely remove. I'll just keeping messing around and try to fix it. thanks for the help. |
01:50:38 | [Saint] | It might pay to run a check of the filesystem. |
01:50:45 | sansaclipzip | how can I do that? |
01:51:18 | *** | Saving seen data "./dancer.seen" |
01:52:16 | [Saint] | chkdsk on windows (google "chkdsk+Windows"), or fsck.vfat on linux (type "man fsck.vfat" in the terminal and press Enter). |
01:56:23 | sansaclipzip | thanks i'll try that if this doesnt work. I just booted into the original firmware..should I delete the .rockbox folder from the player? and then reinstall rockbox? |
01:56:57 | [Saint] | That won't necessarily "fix" anything, but sure...you can do that. |
01:57:54 | [Saint] | The OF should include (somewhere in its labyrinthine menu structure) an option to repair/format the disk, this *will* fix disk errors. |
01:58:34 | [Saint] | (and, you'll also lose any media you don't have backed up..but, with filesystem corruption you should count it all as gone anyway really) |
01:58:38 | sansaclipzip | oh cool. didn't know that, thanks. then a fresh install of rockbox after wiping the disk? |
01:58:47 | * | [Saint] nods |
02:00 |
02:06:08 | sansaclipzip | thanks a lot [Saint]. I reformatted it, reinstalled rockbox, and now it works. |
02:06:40 | [Saint] | Awesome. Well, I guess that puts some credit towards the "didn't safely remove" option. :) |
02:07:06 | sansaclipzip | haha yeah. I guess I'll do that safely remove thing more often now. thanks again. |
02:07:38 | [Saint] | If you're on Windows, you can disable write-caching to /minimize/ the risk that data isn't currently written to disk at time of ejection, but, the safest option is to just always safely remove. |
02:08:06 | sansaclipzip | I'm not that computersmart. i'll just stick with safely removing thank you |
02:11:28 | | Quit sansaclipzip (Quit: CGI:IRC (EOF)) |
02:53:44 | | Join Strife89 [0] (~Strife89@69.160.178.235) |
03:00 |
03:38:12 | | Join pedro_angelo [0] (~pedro_ang@201-29-168-126.user.veloxzone.com.br) |
03:40:14 | | Part Strife89 ("Departure.") |
03:51:19 | *** | Saving seen data "./dancer.seen" |
03:58:36 | | Join amayer [0] (~alex@h210.53.213.151.dynamic.ip.windstream.net) |
04:00 |
04:15:32 | | Quit mystica555 (Remote host closed the connection) |
04:17:50 | | Quit factor (Read error: Connection reset by peer) |
04:17:51 | | Quit amiconn (Disconnected by services) |
04:17:51 | | Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) |
04:17:51 | | Quit pixelma (Disconnected by services) |
04:17:52 | | Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) |
04:17:54 | | Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) |
04:17:57 | | Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) |
04:35:28 | | Join factor [0] (~factor@r74-195-187-97.msk1cmtc01.mskgok.ok.dh.suddenlink.net) |
04:37:47 | | Join TheSphinX^ [0] (~briehl@p5B323F13.dip.t-dialin.net) |
04:41:44 | | Quit TheSphinX_ (Ping timeout: 260 seconds) |
04:49:02 | | Join Mending [0] (~4b768a2a@www.haxx.se) |
04:49:28 | Mending | Anyone up for helping me with rockbox? |
04:50:37 | | Quit Mending (Client Quit) |
04:50:44 | | Join Mending [0] (~4b768a2a@www.haxx.se) |
04:52:12 | | Quit Mending (Client Quit) |
04:53:42 | | Join thals1992 [0] (438e8228@gateway/web/freenode/ip.67.142.130.40) |
04:56:38 | thals1992 | Hello? |
05:00 |
05:02:18 | Prodicus | thals1992: Hello. If you have something to say, please say it; people will respond when they come back to their irc client. |
05:04:42 | Prodicus | Having a dozen people each come in and say "Hello, I have a question. Can anybody help me out?" and then leaving when they don't get answers within 30 seconds can be a little bit frustrating. |
05:05:55 | thals1992 | Hi devs, just wanted to see if there any interest of porting or even hacking insignia hd01 or hd02. I cant seem to find pcb shots. |
05:10:14 | thals1992 | I own both units and am willing to lend them. srry its taking forever to type. opl9 and . dont work and it takes forever to type |
05:13:17 | | Quit wtachi (Ping timeout: 264 seconds) |
05:24:27 | | Quit TheSeven (Disconnected by services) |
05:24:36 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
05:33:02 | thals1992 | I guess I'll just check the log tomorrow then. |
05:41:00 | amayer | are those devices touch screen? |
05:51:21 | *** | Saving seen data "./dancer.seen" |
05:56:43 | | Join Totalled_ [0] (~Totalled@c-98-245-9-211.hsd1.co.comcast.net) |
05:59:08 | | Quit Totalled (Read error: Connection reset by peer) |
05:59:08 | | Nick Totalled_ is now known as Totalled (~Totalled@c-98-245-9-211.hsd1.co.comcast.net) |
06:00 |
06:02:22 | thals1992 | yes |
06:03:04 | thals1992 | the hd01 is all buttons the hd02 is not |
06:06:35 | thals1992 | plugging them in seems to do nothing. devmgmt doesnt show a device. they are solely used as charging ports. afaik |
06:08:33 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
06:09:31 | thals1992 | I actually have the oem headphones for both devices if it might make a difference in signal (probably not though) |
06:25:18 | | Quit mystica555 (Remote host closed the connection) |
06:27:40 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
06:27:42 | | Quit mystica555 (Excess Flood) |
06:28:02 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
06:28:02 | | Quit mystica555 (Excess Flood) |
06:28:22 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
06:28:22 | | Quit mystica555 (Excess Flood) |
06:28:42 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
06:28:43 | | Quit mystica555 (Excess Flood) |
06:29:02 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
06:29:03 | | Quit mystica555 (Excess Flood) |
06:29:22 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
06:29:23 | | Quit mystica555 (Excess Flood) |
06:29:41 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
06:29:42 | | Quit mystica555 (Excess Flood) |
06:33:33 | thals1992 | ill try again tomorrow, its 1232 est here. i'll try email the dev list aswell. thanks in advance |
06:34:29 | | Part thals1992 |
06:48:15 | | Part amayer |
06:59:24 | | Quit Rower85 (Read error: Connection reset by peer) |
07:00 |
07:09:05 | | Join wtachi [0] (~chat@bloom.wtachi.us) |
07:32:10 | | Join mortalis [0] (~mortalis@195.34.194.126.kalibroao.ru) |
07:49:52 | | Join kevku [0] (x@indeed.tastes.like.everything.mm.am) |
07:51:25 | *** | Saving seen data "./dancer.seen" |
07:57:37 | | Join Keripo [0] (~Keripo@c-76-22-63-234.hsd1.wa.comcast.net) |
08:00 |
08:06:02 | | Join LinusN [0] (~linus@giant.haxx.se) |
08:10:18 | | Quit pedro_angelo (Remote host closed the connection) |
08:13:27 | | Quit eckoit (Quit: eckoit) |
08:18:24 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
08:18:27 | | Quit mystica555 (Excess Flood) |
08:18:45 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
08:18:47 | | Quit mystica555 (Excess Flood) |
08:19:07 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
08:19:08 | | Quit mystica555 (Excess Flood) |
08:19:26 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
08:19:27 | | Quit mystica555 (Excess Flood) |
08:19:45 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
08:19:46 | | Quit mystica555 (Excess Flood) |
08:20:04 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
08:20:05 | | Quit mystica555 (Excess Flood) |
08:21:52 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
08:21:54 | | Quit mystica555 (Excess Flood) |
08:22:03 | | Join webguest39 [0] (~55b497c5@www.haxx.se) |
08:22:53 | webguest39 | hello at all |
08:24:21 | webguest39 | I have a problem with my mp3 player |
08:27:05 | | Join Zagor [0] (~bjst@sestofw01.enea.se) |
08:27:05 | | Quit Zagor (Changing host) |
08:27:05 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
08:27:49 | webguest39 | hello zagor can you help? |
08:29:14 | Zagor | webguest39: http://www.rockbox.org/wiki/IrcGuidelines #9 :-) |
08:30:59 | webguest39 | i have read . but my mp3 player has a data abort. |
08:36:10 | | Join n1s [0] (~n1s@nl118-168-30.student.uu.se) |
08:36:10 | | Quit n1s (Changing host) |
08:36:10 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
08:36:26 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
08:37:41 | webguest39 | who can help me with my mp3 player ? my mp3 has a data abort. |
08:39:28 | Zagor | webguest39: you need to give more details. what player? when does it happen? |
08:40:08 | webguest39 | it is a sandisk sansa fuze v1 . data abort at 30801028 FSR 0x8 (domain 0, fault 8) address 0xE9CEC9F4 |
08:42:39 | | Join ender` [0] (krneki@foo.eternallybored.org) |
08:49:38 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
08:49:40 | | Quit mystica555 (Excess Flood) |
08:49:59 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
08:50:00 | | Quit mystica555 (Excess Flood) |
08:50:19 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
08:50:20 | | Quit mystica555 (Excess Flood) |
08:50:25 | webguest39 | zagor what can i with the player? |
08:50:39 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
08:50:40 | | Quit mystica555 (Excess Flood) |
08:53:49 | | Quit n1s (Read error: Connection timed out) |
08:54:21 | Zagor | webguest39: come on, why do we have to drag the information out of you? *when* does it happen? |
08:55:34 | webguest39 | today . i have copy a mp3s and has done , and have new boot than come this |
08:56:44 | Zagor | which rockbox version are you running? does it happen with the latest version? |
08:56:59 | webguest39 | 3.1.9 |
08:57:11 | webguest39 | 3.9.1 |
08:57:26 | Zagor | then first try upgrading to the latest version |
08:57:52 | | Join Buschel [0] (~chatzilla@p57905E53.dip.t-dialin.net) |
08:58:39 | webguest39 | this problem is my pc cannot connect to mp3 player |
09:00 |
09:02:45 | | Join petur [0] (~petur@rockbox/developer/petur) |
09:03:55 | webguest39 | my pc find my device not zagor |
09:06:16 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
09:06:20 | Zagor | webguest39: hold the LEFT button while turning on the player |
09:07:27 | webguest39 | oh thanks i have my old system |
09:07:58 | Zagor | now you can upgrade rockbox |
09:08:26 | Zagor | this is documented in the manual: http://download.rockbox.org/daily/manual/rockbox-sansafuze/rockbox-buildch3.html#x5-280003.1.3 |
09:09:45 | webguest39 | ok thank you |
09:12:56 | webguest39 | and now i have yet , SWI at 34EA0584 zagor |
09:13:59 | Zagor | webguest39: again, details please. what did you change, when does it happen? |
09:15:30 | webguest39 | i have upgrading to lates vision from rockbox and then have reboot . aand he has this SWI at 34EA0584 |
09:16:33 | Zagor | webguest39: which version did you install? |
09:16:48 | webguest39 | 3.11.2 |
09:17:21 | Zagor | webguest39: ok, now try the latest dev build: http://build.rockbox.org/data/rockbox-sansafuze.zip |
09:18:46 | webguest39 | Extracting on the root of the mp3? |
09:19:01 | [Saint] | yes |
09:19:09 | webguest39 | ok |
09:19:36 | webguest39 | and then reboot the mp3 |
09:20:34 | webguest39 | ok it works |
09:20:41 | Zagor | excellent |
09:20:57 | webguest39 | thank you for helping |
09:21:25 | Zagor | have fun! |
09:22:28 | * | [Saint] is never sure if it is a good thing when the above happens or not. |
09:22:29 | webguest39 | cya all and a beautiful day |
09:23:47 | | Quit webguest39 (Quit: CGI:IRC) |
09:24:19 | Zagor | [Saint]: a bug in 3.11.2 is fixed in dev. sounds like a good thing to me. |
09:25:03 | [Saint] | even if the cause and solution remain unknown? |
09:25:38 | Zagor | yes. it would be *better* to know, but having it fixed is still an improvement |
09:25:56 | Zagor | correction: having it not occur |
09:31:36 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
09:34:44 | Buschel | n1s: did I read correct in the logs? f2 saves 32 MHz and OpusDecoder 24 MHz if moved to IRAM? |
09:36:25 | n1s | Buschel: no, not f2, f (i pushed a change to put it on the stack which is in iram on wednesday http://git.rockbox.org/?p=rockbox.git;a=commit;h=f636aa0) |
09:36:52 | n1s | the number for OpusDecoder is correct though |
09:37:56 | Buschel | ok, I misread the logs regarding f2. could you test my changes on cf though? |
09:38:36 | Buschel | I am just rebasing to your latest change. which gives me a hard time, because I never used git before :/ |
09:39:04 | n1s | yeah |
09:40:47 | Buschel | nice, yor latest chgange saved another 4.3 MHz on my PP as well :) |
09:41:02 | | Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) |
09:41:15 | n1s | yeah, the saving on arm was more than i expected |
09:42:00 | Buschel | definately. How did you find out that the multiplication with coef[1] is only relevant for custom modes? |
09:44:01 | n1s | Buschel: jmspeex told me, it's always 0 the static mode is in static_does_fixed.h |
09:44:26 | n1s | s/does/modes/ |
09:44:48 | n1s | aalways 0 with the static mode |
09:44:50 | Buschel | ahh, got it. hard to find w/o any hint |
09:47:08 | Buschel | with all my local changes I am realtime now here (77.3 MHz). this is w/o the src though... |
09:51:29 | *** | Saving seen data "./dancer.seen" |
09:52:23 | n1s | with my earlier pile of hacks i got to just aboove 100% with your patch on top of git i get 122.1% (101.7MHz) on 64kbps |
09:53:19 | kugel | are theere other test files? |
09:53:25 | Buschel | good :) |
09:53:34 | kugel | 64kbit/s seems low to be useful for music |
09:53:50 | n1s | kugel: yes |
09:55:19 | n1s | ok, 64kbps seems to be fast enough to listen without skipping even though we need to resample |
09:55:56 | Buschel | the 256k file needs quite some more power... |
09:56:49 | n1s | kugel: i mainly chose it as when i started looking at this it was below 50% realtime so a benchmark took 6 minutes or so :/ |
09:57:43 | Buschel | n1s: you said you ported some ogg-IRAM-alloc functionality to opus to allocate OpusDecoder. will you submit this solution? |
09:57:51 | kugel | n1s: makes sense |
09:58:01 | n1s | 128k is 90.2 % realtime (137.64MHz) |
09:58:41 | n1s | Buschel: not sure if it makes sense if we dynamically alloc only the one buffer |
09:58:53 | n1s | or do you want to use it for something else? |
09:59:35 | Buschel | why shouln't we use it for some of the other variables as well? this way we might be more efficient compared to static "worst case" allocations |
10:00 |
10:00:00 | Buschel | -> f2, freq, X |
10:00:43 | Buschel | we could of course just statically allocate for now and submit a more sophisticated solution later... |
10:01:52 | n1s | is there anything that doesn't fit with the worst case allocs that would be worthwile to have in iram? |
10:03:35 | Buschel | I do not know for sure. You think we should just statically allocate for now? |
10:04:18 | Buschel | on PP: 77.3 MHz (64k), 91.7 MHz (128k), 116.1 MHz (256k) |
10:05:28 | Buschel | brb |
10:12:05 | | Quit XavierGr (Ping timeout: 260 seconds) |
10:38:12 | | Quit Prodicus (Ping timeout: 248 seconds) |
10:52:51 | | Join lorenzo92 [0] (~chatzilla@host232-108-dynamic.54-79-r.retail.telecomitalia.it) |
10:53:01 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
10:53:27 | lorenzo92 | kugel: good, so then? |
10:53:59 | Buschel | n1s: just found another 6 MHz on PP :) |
10:56:14 | lorenzo92 | kugel: moreover, back to my experiments with usb connection. it happens a strange thing. if I place some printfs in usb.c, screendump *doesn't* crash. If I don't, crashes!!! |
10:59:50 | wodz | timing issue? |
11:00 |
11:02:34 | Buschel | n1s: did your latest submit change the output on arm? |
11:05:02 | lorenzo92 | wodz: well, perhaps some conflicts since there is another ioctl to /dev/minivet at the same time to see whether a charger is connected or not...I'm just waiting for the ttl converter to be able to debug that ^^ |
11:08:04 | lorenzo92 | wodz: but these calls are protected by mutexes in kernel, then should not be that the problem..because until I insert the cable works perfectly |
11:09:29 | wodz | Try adding some delay and see if it also fixes crash. If it is so you are experiencing timing problem IMO. |
11:11:38 | | Join minouch [0] (~d590c461@www.haxx.se) |
11:20:08 | wodz | Torne: BTW why not write simplified elf loader? Link plugins with -r and perform relocations on our own? elf2flt is a hack anyway. On MIPS doing relocations 'flat way' is rather impossible, etc, etc. The cost is code complexity of course. |
11:20:18 | kugel | lorenzo92: the kernel mutexes only protect from two ioctl's on the same device at the same time, not two ioctls on different devices, no? |
11:21:18 | kugel | lorenzo92: what theme can I test RDS with? |
11:23:15 | lorenzo92 | kugel: yes yes, same device indeed. theme that's working is cabbiev2 and radioboy |
11:23:37 | kugel | cabbiev2 doesnt have rds info does it? |
11:25:04 | n1s | Buschel: i think it can as the second multiplication that i removed was just zeroing the two lsbs of the tmp var that is then scaled down by adding 1<<11 and right shifting it 12 so it _might_ affect the rounding in very rare cases but it did not when checking crc on the 64k file |
11:25:30 | lorenzo92 | kugel: it has... |
11:25:39 | lorenzo92 | *does |
11:25:52 | lorenzo92 | both station name and rds text |
11:26:09 | kugel | debug->FM radio suggests there's no RDS info |
11:26:33 | kugel | PI changes, PS is spaces only and RT is empty |
11:27:03 | lorenzo92 | kugel: if time is being updated, then it's timing issue! |
11:27:06 | lorenzo92 | *just |
11:27:18 | lorenzo92 | I mean RDS CT |
11:27:47 | Buschel | n1s: there's something going here :/ |
11:27:49 | kugel | ah there |
11:27:58 | kugel | other station has something |
11:28:10 | | Join Thra11 [0] (~thrall@146.90.84.243) |
11:30:27 | kugel | scrolling is strange |
11:31:00 | Buschel | n1s: of course I meant "going wrong" |
11:32:06 | kugel | wodz: doesnt the linux kernel have this? |
11:33:12 | wodz | kugel: It is rather libc part |
11:33:38 | kugel | for loading kernel modules? |
11:33:42 | | Join Syconaut^ [0] (viper@c-60fd72d5.162-1-64736c10.cust.bredbandsbolaget.se) |
11:33:56 | wodz | ah that what you mean, yes it should have |
11:34:22 | wodz | anyway I think bflt is dead end |
11:34:36 | kugel | only because of mips? |
11:35:11 | | Quit Syconaut (Ping timeout: 252 seconds) |
11:35:37 | kugel | another alternative is to reimplement elf2flt |
11:35:42 | wodz | This is the most obvious reason. Other is arm veneers, Third is hackiness of solution. |
11:35:50 | wodz | kugel: I mostly done that |
11:36:15 | wodz | I mean I heavily rewrote it. |
11:36:35 | kugel | I meant from scratch |
11:36:48 | wodz | But the truth is that there are relocs which can't be simply represented as simple addend |
11:36:53 | kugel | the arm veneers arent elf2flt's fault |
11:37:21 | kugel | any other solution would face the same problem |
11:37:36 | n1s | Buschel: are you sure about the sizes of all your static allocs? |
11:38:07 | kugel | and any other solution would also need to handle the complex mips relocs, whether offline or at runtime doesnt really matter |
11:38:10 | Buschel | n1s: no, those are taken from the 64k file. |
11:38:54 | wodz | Well, that depends on perspective. If you link with -r which is what should really be used if you want to resolve static allocation then you take the responsibility to insert veneers for R_ARM_CALL |
11:39:44 | wodz | I still think it is dumb not to emit relocs for veneers but from the other hand what we do is abuse of good practice |
11:39:58 | Buschel | n1s: my local changes screw up for arm... :( |
11:40:43 | kugel | wodz: I wonder if the ld output is fully resolved, how can there be those complex relocs? |
11:41:02 | kugel | I would think in a fully resolved binary all relocs should be most simple |
11:41:26 | wodz | kugel: Have you read my BFLT wiki page? |
11:41:44 | kugel | no, I didnt know its existence yet :p |
11:42:46 | wodz | basically MIPS decided to code addend in instruction itself. They split address into two halves R_MIPS_HI16 takes upper 16bits of absolute address, R_MIPS_LO16 takes lower 16bits of absolute address. |
11:43:48 | wodz | It is all easy but as other part of 32bit word is used to code instruction you have no simple way to express this relocation in flt way (simple addend) |
11:44:03 | wodz | you have to mask instruction bits and do the shifts |
11:44:21 | wodz | R_MIPS_26 is even more weird :-) |
11:44:41 | wodz | addend is expressed in words in lower 26bits of instruction |
11:45:29 | wodz | jump address is calculated as (PC & 0xf0000000) + ((instruction & 0x3ffffff)<<2) |
11:45:41 | wodz | good luck expressing this as a simple addend |
11:46:04 | kugel | what is a "simple addend" exactly? |
11:46:40 | | Quit bluebrother (Ping timeout: 244 seconds) |
11:46:40 | wodz | when you get final address as base + addend. |
11:46:44 | kugel | linked to 0, so you can add it to the actual section address to get the final address? |
11:46:57 | wodz | yes thats how elf2flt works |
11:46:58 | | Quit fs-bluebot (Ping timeout: 256 seconds) |
11:47:10 | kugel | right, I just wasn't clear about the term |
11:48:06 | kugel | and our runtime loader would need to handle this two cases? |
11:48:18 | | Join fs-bluebot [0] (~fs-bluebo@g226069254.adsl.alicedsl.de) |
11:48:40 | wodz | which two? |
11:48:48 | kugel | the two MIPS cases |
11:48:53 | wodz | yes |
11:49:01 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
11:49:15 | wodz | at least this relocations are emitted by gcc/as |
11:49:23 | kugel | doesnt the second one appear very similarly on ARM? |
11:49:50 | | Join pacovila [0] (~fravd@89.130.175.197) |
11:50:04 | wodz | yes it is similar to R_ARM_CALL |
11:50:13 | kugel | hm, it probably doesnt have the shift because the lower bits need to be preserved to jump into thumb |
11:51:11 | kugel | but it's also PC relative so it doesnt need to be relocated at all right? |
11:51:32 | *** | Saving seen data "./dancer.seen" |
11:51:56 | wodz | unless you can't express offset in limited number of bits and you have to insert veneer :-) |
11:52:08 | kugel | you said above R_MIPS_26 is also PC relative |
11:53:24 | wodz | I think usually we can treat it as resolved, yes. I don't know if MIPS target use iram. If so we will have the same problem as with ARM |
11:53:27 | | Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) |
11:54:12 | kugel | I think our current mips targets have so little IRAM is not worth using |
11:54:19 | Torne | yeah, we are heavily relying on the fact that ARM is almost entirely PC-relative under normal usage. |
11:54:27 | Torne | which is not true on other arches |
11:54:43 | Torne | it just happens that other than IRAM the reloc types we actually need to handle on ARM are all easy |
11:54:48 | Torne | anyway. |
11:54:58 | Torne | yes, bflt doesn't appear to solve all of our problems particularly well |
11:55:11 | Torne | the fact that you even had to touch elf2flt at all was a bad sign |
11:55:12 | Torne | :) |
11:55:19 | Torne | shame. |
11:55:24 | kugel | wodz: well not exactly, but it's core-only. |
11:56:10 | Torne | so yeah, maybe we look at exactly what ELF features a plain loader would actually nead |
11:56:29 | | Quit Rower85 (Client Quit) |
11:56:39 | wodz | not that much I guess |
11:57:05 | Torne | you pretty much just open it, find the program headers, load stuff into ram as the program headers say, then find the reloc tables and apply relocations |
11:57:19 | wodz | exactly |
11:57:22 | | Join Rower85 [0] (husvagn@82.196.99.90) |
11:57:25 | Torne | if you don't care about checking stuff very much. |
11:57:40 | wodz | It has also the benefit to be well documented format |
11:57:51 | Torne | how complicated applying relocations turns out to be, depends what relocation types the architectures in question actually need in practise |
11:58:05 | Torne | but you can just implement them as needed :) |
11:58:12 | wodz | yes |
11:58:25 | Torne | so the things i'd wonder about are, how big is the ld -r output when stripped |
11:58:35 | Torne | compared to the flt or to the original binary |
11:58:39 | Torne | er |
11:58:45 | Torne | not original, but the old style binary |
11:59:06 | | Quit Rower85 (Client Quit) |
11:59:08 | kugel | you'd still need to handle both mips cases, so it's no more easy that where we are now |
11:59:21 | | Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) |
11:59:25 | Torne | kugel: actually it is easier |
11:59:35 | wodz | kugel: it is easier as elf reloc tables store information about reloc type |
11:59:36 | Torne | the problem with doing that in FLT is that the format itself doesn't represent the data |
11:59:44 | Torne | whereas in ELF it just says "this is this weird kind of relocation" |
11:59:54 | Torne | and so you just have a big switch statement on reloc type and do a different thing |
12:00 |
12:00:13 | Torne | in flt it sounds like we are in the position of undoing some of the simplifications flt has made |
12:00:28 | Torne | FLT deliberately chose not to have a reloc type field because the systems they care about don't need it |
12:01:00 | kugel | ahh, right, the flt doesnt have the reloc type info in it |
12:01:10 | kugel | I was, for a moment, forgetting this fact |
12:01:16 | wodz | From the size point of view FLT with additional field about reloc type will still be smaller then fully fledged elf |
12:02:00 | wodz | But the idea of simply linking plugin as unresolved elf is appealing |
12:02:15 | wodz | no hassle with external tools, conversions etc. |
12:02:39 | Torne | if you strip all the things that aren't needed then i dunno that it's gonna be that much bigger |
12:02:54 | Torne | one thing i just thought of, is how do you actually handle iram wrt. program headers. |
12:03:32 | Torne | i.e. get it to be an identifiable phdr section that you can pick a different load address for |
12:03:40 | wodz | my idea was to use 31bit of vma as indicator |
12:05:23 | * | Torne looks up the phdr load format |
12:06:09 | kugel | with a normal elf you have the section and its name and you don't need to play with bits, dont you? |
12:06:19 | Torne | kugel: section info is not actually used during loading |
12:06:39 | Torne | the loader only cares about program segments defined by program headers |
12:06:56 | Torne | which are much simpler and have much less parametes than sections |
12:06:58 | Torne | and also don't have names :) |
12:07:54 | kugel | oh |
12:08:15 | | Quit petur (Quit: *plop*) |
12:08:18 | Torne | wodz: in normal elf loading, the offsets between segments are preserved |
12:08:34 | Torne | so using the vaddr for that would be weird. |
12:08:43 | Torne | i'm not sure there is a nonweird solution |
12:08:43 | wodz | Torne: I know |
12:09:21 | lorenzo92 | kugel: http://pastie.org/4854699 |
12:09:58 | wodz | The benefit of elf approach would be that Torne will have the opportunity to code veneer insertion on ARMs :-) |
12:11:01 | kugel | linux kernel module loading is a lot of cod |
12:11:34 | Torne | kugel: yes, but it does at least one thing that we don't actually currently nee to do |
12:11:39 | Torne | namely, dynamic linking |
12:11:58 | kugel | ~4k lines (400 of which are arm specific) if I see this right |
12:12:00 | Torne | also, it is Really Careful about everything. :p |
12:12:14 | kugel | Torne: but we want to do it eventually |
12:12:20 | Torne | kugel: i don't know that we do |
12:12:22 | Torne | at least, not in the same way |
12:12:32 | Torne | doing unix style named symbol dynamic linking would be very expensive |
12:12:42 | Torne | we probably don't *ever* want to do that. |
12:12:48 | Torne | we probably want ot link by ordinal the way DLLs work |
12:13:03 | wodz | kugel: are you looking at linux or uclinux sources? |
12:13:11 | kugel | linux |
12:14:09 | kugel | Torne: sorry, by dynamic linking I meant link to non-constant addresses |
12:14:33 | kugel | right, the kernel links kernel functions, while we go through the api struct |
12:15:28 | Torne | Well, we are already linking to non-constant addresses, through the API struct ;) |
12:15:38 | Torne | It just happens that tehre's only one non-constant address. |
12:15:54 | Torne | We could expand that to turn the api struct into an ordinal table instead and then have one non-constant address for each api function |
12:16:04 | Torne | which would eliminate an indirection at every callsite |
12:16:15 | Torne | but i expect we would wnat to do that by ordinal in the former api struct |
12:16:17 | Torne | rather than by name |
12:16:26 | Torne | which is pretty simple in practise :) |
12:16:35 | Torne | also, we only ahve one place to search (core) |
12:16:48 | Torne | rather than having to search an incrementally constructed symbol namespace made of multiple dynamic objects |
12:17:20 | Torne | in practise i'm not even sure that eliminating the API struct woul dbe worth it |
12:17:35 | kugel | I meant we eventually want the plugin loaded to a non-constant address |
12:17:35 | | Join lebellium [0] (~chatzilla@85.179.77.153) |
12:17:47 | Torne | Oh |
12:17:50 | Torne | that's just relocation, though |
12:17:57 | kugel | I don't think we want to touch the method to call core functions |
12:18:01 | Torne | and relocation is easy as long as you don't ahve to write a relocating loader that handles every relocation table of every architecture |
12:18:05 | Torne | er |
12:18:07 | Torne | every relocation type |
12:19:33 | * | Torne shrugs |
12:20:02 | Torne | my point here is that wodz seems to ahve pretty conclusively demonstrated that my theory that flt would be a viable way to avoid the complexity of writing an elf loader is wrong |
12:20:19 | Torne | and that's not entirely a surprise, it's not like i actually tried it myself. i had only read docs on it :p |
12:20:38 | Buschel | n1s: found the issue. something is fishy about the standard implementation of MULT32_32_Q31() |
12:20:47 | Torne | i suggested it because i thought it would be significantly easier, but it looks like it's not :p |
12:21:08 | Buschel | n1s: the current implementation does not give the same results as a proper int64*int64>>31 |
12:21:55 | Torne | so yeah, if wodz is willing to have a go at trying to write the minimal code to handle the parts of ELF that we need, then it will probably work out better than continuing to hack on elf2flt |
12:22:07 | Torne | because at least that way we get to use a standard and well known set of tools |
12:23:36 | kugel | wodz: ld doesnt insert veneers for mips? |
12:24:11 | Torne | kugel: that trick is pretty ARM-EABI specific |
12:24:28 | wodz | kugel: Don't think so. It can adjust R_MIPS_HI16 accordingly. |
12:24:42 | Torne | most toolchains have always just required you to build your code with appropriate memory models |
12:24:47 | Torne | see real-mode x86 |
12:24:56 | kugel | I thought so too, but the R_MIPS_26 is actually the same problem |
12:25:04 | Torne | where you get to choose between "references to memory are all slow" or "you can only address a bit of memory" |
12:25:40 | wodz | 26bits is quite a lot |
12:26:39 | Torne | is it a byte address, or a word address, also? :) |
12:26:48 | wodz | word |
12:27:04 | | Quit minouch (Quit: CGI:IRC) |
12:27:15 | Torne | so +/-128MB? |
12:27:18 | Torne | that's not too bad. |
12:27:20 | Torne | ARm only does 32MB |
12:27:23 | wodz | and also MIPS address space is divided so 31bit of vma have special meaning |
12:27:26 | Torne | or 4MB in thumb |
12:28:09 | wodz | guess why I though about using 31bit of vma as marker :-) |
12:30:28 | wodz | I'll look at this elf thing. But my spare time is truly restricted so it may take forever... |
12:30:41 | n1s | Buschel: ah |
12:30:58 | n1s | i haven't looked at it, is it used much |
12:31:27 | kugel | can't we reuse an elf-loader from somewhere? |
12:31:49 | kugel | (and strip it down as-needed |
12:31:55 | Buschel | n1s: no, not really. but about 0.8 MHz can be saved if replaced by proper asm. but for this we should also change the macro itself to use 64-bit multiplication |
12:32:26 | wodz | kugel: I can't find anything suitably simple. |
12:32:43 | n1s | Buschel: did you check how big the diff in the output is? |
12:32:52 | Buschel | no, not yet |
12:33:02 | kugel | perhaps newlib or uclibc? |
12:33:54 | wodz | will look |
12:41:22 | n1s | Buschel: yeah that macro looks weird, it's only doing 3 16*16 multiplications |
12:41:47 | Buschel | n1s: if I replace the current implementation with a real int64-multplication the results differs by max +/-3 (of 32768) in few situations |
12:41:58 | Buschel | so, we better replace it |
12:42:16 | Buschel | gotta pick up my son from Kindergarden now :) |
12:56:37 | | Quit lorenzo92 (Remote host closed the connection) |
12:58:24 | lebellium | [Saint] logs : "%?tz<%tz|>" is really ugly" > indeed, fixed |
13:00 |
13:00:03 | lebellium | "I also wonder if scrolling is messing it up. the way rds works, it wouldn't surprise me." > without scrolling it seems not to crash anymore but the RDS text is definitely cut off while it shouldn't be and I never experienced any issue with scrolling RDS text (same code) on my theme for Clip Zip |
13:02:02 | lebellium | does that come from the RDS issues in the latest builds? |
13:05:00 | | Quit mgottschlag (Ping timeout: 245 seconds) |
13:16:15 | wodz | prex seems to have pretty simple elf loader |
13:18:45 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
13:20:05 | kugel | looks good |
13:21:00 | | Quit Buschel (Ping timeout: 246 seconds) |
13:23:46 | wodz | elf_reloc.c for ARM doesn't care about call offset though. Anyway it seems like good start. |
13:24:39 | n1s | Buschel: yeah sounds good, would be nice to compare with a float decoder too |
13:24:42 | kugel | code seems clean also |
13:26:42 | | Quit perrikwp (Ping timeout: 256 seconds) |
13:27:11 | wodz | can't find license but IIRC it is some form of BSD license |
13:27:39 | kugel | the front page of prex says bsd |
13:28:02 | kugel | the files have a license header too |
13:29:18 | wodz | the question which BSD it is |
13:29:51 | wodz | ah revised BSD so we are ok |
13:36:10 | | Join perrikwp [0] (~quassel@cpe-075-177-082-185.triad.res.rr.com) |
13:36:34 | | Join dfkt [0] (dfkt@chello084112032026.1.11.vie.surfer.at) |
13:36:36 | | Quit dfkt (Changing host) |
13:36:36 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
13:37:45 | | Quit mikroflops (Ping timeout: 244 seconds) |
13:41:07 | | Quit perrikwp (Ping timeout: 248 seconds) |
13:43:21 | | Join perrikwp [0] (~quassel@cpe-075-177-082-185.triad.res.rr.com) |
13:46:27 | | Join Prodicus [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) |
13:46:44 | | Join pedro_angelo [0] (~pedro_ang@201-29-168-126.user.veloxzone.com.br) |
13:48:01 | | Quit wodz (Quit: Leaving) |
13:49:04 | | Join mikroflops [0] (~yogurt@h-34-21.a238.priv.bahnhof.se) |
13:51:36 | *** | Saving seen data "./dancer.seen" |
13:53:10 | | Join advcomp2019__ [0] (~advcomp20@unaffiliated/advcomp2019) |
13:56:18 | | Quit advcomp2019_ (Ping timeout: 246 seconds) |
13:58:40 | | Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) |
14:00 |
14:09:52 | | Quit Keripo (Quit: Leaving.) |
14:10:02 | | Quit pedro_angelo (Remote host closed the connection) |
14:11:13 | | Join amayer_ [0] (~alex@mail.weberadvertising.com) |
14:23:53 | | Join MethoS- [0] (~clemens@134.102.106.250) |
14:28:45 | | Quit MethoS- (Client Quit) |
14:51:47 | | Join Buschel [0] (~chatzilla@p57905E53.dip.t-dialin.net) |
15:00 |
15:00:39 | Buschel | n1s: do you have float-decoder at hand? |
15:01:45 | n1s | no, not sure what would be the easiest app to use that will spit out a wav file |
15:03:03 | Buschel | n1s: is linopus working when FIXED_POINT is not sdefined? |
15:03:34 | n1s | right, that would be the easiest solution if it works :) |
15:03:46 | n1s | no idea if it does though |
15:04:05 | n1s | easy to test |
15:04:51 | Buschel | as we are talking of testing -> http://pastie.org/4855567 (71 MHz on pp) |
15:06:47 | n1s | nope, doesn't build without FIXED_POINT |
15:07:34 | n1s | Buschel: what changed since lthe last patch? |
15:09:11 | Buschel | n1s: some changes to comb_filter which save ~6 MHz on arm. it exploits the fact that g0 and g1 are =0 in many cases |
15:09:28 | Buschel | =) = " = 0 " |
15:09:43 | | Join jpt9 [0] (~jpt9@unaffiliated/jpt9) |
15:10:42 | jpt9 | Hey. I assume that since it's currently being worked on, Opus support probably won't be in the very next release of Rockbox? |
15:11:12 | n1s | jpt9: correct |
15:19:43 | n1s | Buschel: cool, are they usually 0 at the same time or would more fine grained check, doing the macs with just the nonzero gains be worthwile? |
15:20:22 | jpt9 | n1s: Thanks. It looks like a pretty neat codec, especially for audiobooks. |
15:20:27 | Buschel | n1s: mostly both are zero at the same time. I did want to exploit the other situations as it makes the code much worse readable |
15:21:21 | n1s | Buschel: ok, i think i'll hack something up to see if it makes a difference :) |
15:21:42 | Buschel | it will, but I would not expect too much ;) |
15:24:27 | lebellium | bertrik: I reverted back to an old build (April) on my Clip Zip and the RDS seems to work far better than with the latest build. There's definitely a RDS issue in the latest builds, even on native targets. |
15:28:01 | Buschel | n1s: just compared rockbox output with the output from a precmpiled win32-decoder (−−rate 48000 −−no-dither). rockbox differs with max +/- 2415 (of 32768), but -85 dBFS average. the error energy is a bit lower when using the int64 multiplication. so, I guess it is good to use it instead of the weird macro... |
15:28:44 | n1s | sounds like it |
15:29:18 | Buschel | is 48 kHz the native samplerate of the codec? or is it possible to synthesize to 44.1 kHz? |
15:29:49 | bertrik | lebellium: nothing was changed recently regarding RDS |
15:30:06 | bertrik | RDS uses up an extra thread, maybe something else claimed it |
15:30:37 | bertrik | but there does appear to be some kind of bug because RDS text seems to be updated before an entire message is received |
15:30:59 | bertrik | the idea was that it's only updated on the UI when a full message is received |
15:31:14 | n1s | Buschel: yeah 48kHz, the downsampling in the deemphasis loop can downsample by integer factors when outputting (24, 16, 12, 8kHz) |
15:31:32 | n1s | not really usefull for us |
15:32:07 | Buschel | n1s: I was just wondering because the win32-decoder just outputs 44.1 kHz by default. I needed to force it to output 48 kHz. |
15:32:30 | n1s | ah |
15:33:40 | n1s | the downsampling is rather crude too, it just skips samples when outputting |
15:34:03 | Buschel | ugly. best wishes from aliasing ;) |
15:34:28 | lebellium | bertrik: ok. What I noticed is that with the latest builds RDS text display strange characters (see http://imageshack.us/a/img837/2154/dump120926124439.png ) and that RDS name doesn't show up most of time while it displays immediately for almost any station with my April build |
15:40:32 | Buschel | n1s: if you like you can submit the changes (w/o the IRAM stuff of course). I do not have any gerrit access yet... |
15:40:52 | n1s | Buschel: the sim is segfaulting with your last patch |
15:41:16 | Buschel | let me check |
15:42:07 | Buschel | which file? the 64k one? |
15:42:16 | n1s | yeah |
15:42:30 | Buschel | works like charm here |
15:42:42 | n1s | hmm, weird |
15:42:51 | Buschel | let me make a clean build |
15:43:04 | n1s | just doing the same |
15:45:43 | Buschel | still works |
15:46:48 | Buschel | btw, I crosscompile a win32 executable under ubuntu64 |
15:47:07 | n1s | i use native linux 64 |
15:48:47 | Buschel | what happens if you drop the change to fixed_generic.h? |
15:51:27 | n1s | no difference, i'll try gdb |
15:51:39 | *** | Saving seen data "./dancer.seen" |
15:52:26 | Buschel | ok |
15:55:35 | | Quit mortalis (Quit: Leaving) |
15:58:32 | n1s | i don't get it, it crashes in tf_decode |
16:00 |
16:00:16 | n1s | i would try valgrind but i don't remember how to make the sim work with it |
16:00:46 | Buschel | can you just roll back the changes file-by-file? this way we can dig into the causing change |
16:01:14 | n1s | yeah, i'll try to look at it later or tomorrow, gtg now |
16:01:23 | Buschel | see you later |
16:07:52 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
16:08:23 | kugelp | bertrik: i saw partial strings on the fms |
16:08:33 | kugelp | in* |
16:14:03 | | Quit bertrik (Ping timeout: 246 seconds) |
16:14:42 | | Quit benedikt93 (Quit: Bye ;)) |
16:15:30 | | Join pretty_function [0] (~sigBART@123.252.214.150) |
16:32:49 | | Quit Thra11 (Quit: kthxbai) |
16:36:32 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
16:38:13 | | Join eckoit [0] (~ryan@50.65.10.24) |
16:55:12 | | Quit Zagor (Quit: Clint excited) |
16:56:19 | | Nick Guinness` is now known as Guinness (Slayer@c-68-55-111-159.hsd1.va.comcast.net) |
16:59:54 | | Part LinusN |
17:00 |
17:18:45 | | Quit pretty_function (Ping timeout: 245 seconds) |
17:19:28 | | Join sciopath [0] (~sciopath@yer91-2-82-237-54-159.fbx.proxad.net) |
17:19:36 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
17:23:08 | | Join WalkGood [0] (~4@unaffiliated/walkgood) |
17:24:20 | | Join XavierGr [0] (XavierGr@rockbox/staff/XavierGr) |
17:36:10 | | Join pretty_function [0] (~sigBART@123.252.214.150) |
17:40:57 | | Quit pretty_function (Ping timeout: 245 seconds) |
17:43:47 | | Quit Buschel (Ping timeout: 248 seconds) |
17:51:41 | *** | Saving seen data "./dancer.seen" |
17:52:14 | | Quit linuxstb (Quit: This computer has gone to sleep) |
17:53:08 | | Join linuxstb [0] (~linuxstb@host86-136-64-97.range86-136.btcentralplus.com) |
17:58:17 | | Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) |
18:00 |
18:01:08 | | Quit sciopath (Quit: Quitte) |
18:14:07 | | Join Buschel [0] (~chatzilla@p57905E53.dip.t-dialin.net) |
18:19:59 | | Quit Buschel (Ping timeout: 252 seconds) |
18:23:12 | | Join Buschel [0] (~chatzilla@p57905E53.dip.t-dialin.net) |
18:30:54 | n1s | Buschel: i know what the problem is, the static buffer for OpusDecoder is too small on 64 bit, i guess there are some pointers in there |
18:32:28 | n1s | increasing the size to 26532 makes it work fine |
18:33:06 | Buschel | n1s: ahh, ok. |
18:33:11 | n1s | i'd also like to add an alignment att and maybe #ifdef this for !define(CUSTOM_MODES) as it will blow up for those |
18:33:23 | n1s | s/att/attr/ |
18:34:19 | Buschel | all of the IRAM changes are dirty hacks. we should never submit it like this :) |
18:34:39 | n1s | also i'm not really sure when someone would like to enable custom modes so i guess i should check out what it's really about |
18:35:40 | Buschel | if i understood correctly custom modes is used to define other windows, overlap lengths etc. |
18:36:30 | n1s | yeah but will people create such files and expect them to work? |
18:36:57 | n1s | or is it just something that's intended for special purpose implementations? |
18:37:11 | Buschel | no idea |
18:44:21 | n1s | "Use |
18:44:22 | n1s | * of Opus Custom is discouraged for all but very special applications |
18:44:22 | n1s | * for which a frame size different from 2.5, 5, 10, or 20 ms is needed |
18:44:22 | DBUG | Enqueued KICK n1s |
18:44:22 | n1s | * (for either complexity or latency reasons) and where interoperability |
18:44:22 | n1s | * is less important." |
18:44:48 | n1s | so i guess we can ignore it and hope common encoder apps don't let users enable it |
18:45:53 | Buschel | I am a bit confused why opus used 48 kHz only. what happens if there is 44.1 kHz input? is there SRC happening in the encoder? |
18:48:50 | n1s | i think something like http://pastebin.com/y2xyzceF would be ok for the iram decoder state, assuming we reject files with > 2 channels or it will explode |
18:51:51 | Buschel | we should add a check to abort or allocate if opus_decoder_get_size(channels) is more than 26532. and we should add a #define for this number like "#define STATIC_DECODER_SIZE 26532" |
18:52:32 | Buschel | I did something similar with the faac allocation. in the worst case we simply do not use the iram buffer and fall back to opius_alloc |
18:52:48 | Buschel | what do you think? |
18:53:52 | n1s | yeah, that's safer |
18:54:24 | n1s | i'm off for tonight, beertime :) |
18:55:54 | | Quit linuxstb (Quit: This computer has gone to sleep) |
18:57:14 | | Join linuxstb [0] (~linuxstb@host86-136-64-97.range86-136.btcentralplus.com) |
18:58:38 | | Quit TheSphinX^ (Ping timeout: 265 seconds) |
18:59:13 | Buschel | something like this -> http://pastie.org/4856637 |
18:59:20 | | Join TheSphinX^ [0] (~briehl@p5B323F13.dip.t-dialin.net) |
19:00 |
19:00:42 | Buschel | beer sounds like a good idea :) |
19:10:16 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
19:10:19 | | Quit mystica555 (Excess Flood) |
19:10:38 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
19:10:39 | | Quit mystica555 (Excess Flood) |
19:10:58 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
19:10:59 | | Quit mystica555 (Excess Flood) |
19:11:18 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
19:11:18 | | Quit mystica555 (Excess Flood) |
19:11:36 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
19:11:37 | | Quit mystica555 (Excess Flood) |
19:11:56 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
19:11:56 | | Quit mystica555 (Excess Flood) |
19:12:15 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
19:12:15 | | Quit mystica555 (Excess Flood) |
19:12:34 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
19:12:34 | | Quit mystica555 (Excess Flood) |
19:12:53 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
19:12:53 | | Quit mystica555 (Client Quit) |
19:16:29 | | Quit t0rc (Quit: WeeChat 0.3.8) |
19:21:35 | | Join Buschel_ [0] (~chatzilla@p57905E53.dip.t-dialin.net) |
19:25:37 | | Quit Buschel (Ping timeout: 252 seconds) |
19:25:45 | | Nick Buschel_ is now known as Buschel (~chatzilla@p57905E53.dip.t-dialin.net) |
19:27:23 | | Join Epicanis [0] (~Epicanis@static-72-95-113-7.port.east.myfairpoint.net) |
19:30:13 | | Join pretty_function [0] (~sigBART@123.252.214.150) |
19:31:47 | | Join saratoga [0] (123e0cca@gateway/web/freenode/ip.18.62.12.202) |
19:31:56 | saratoga | Buschel: opus resamples everything to 48k internally |
19:32:25 | saratoga | apparently this simplies things in the MDCT, and also has some advantages (IIRC) for hybrid mode where both MDCT and voice coding are used |
19:34:44 | saratoga | i guess this is sensible enough for opus anyway, since a low latency codec will probably be used for streaming and embedded applications where the sample rate will likely be 48k anyway |
19:35:06 | saratoga | outside of CDDA, using other then 48k makes no sense anyway |
19:46:35 | | Join mystica555 [0] (~Mike@75-166-107-42.hlrn.qwest.net) |
19:46:35 | | Quit mystica555 (Client Quit) |
19:51:45 | *** | Saving seen data "./dancer.seen" |
20:00 |
20:22:48 | | Join stoffel [0] (~quassel@pD9E43101.dip.t-dialin.net) |
20:39:33 | Buschel | saratoga: i do not get the point. because when it comes to encoding the only difference is the psychoacoustic model (mapping from spectral lines to critical bands). the codec itself only transfers a set of samples to frequency domain and back again. |
20:39:54 | saratoga | buschel: theres some discussino about this on HA i think |
20:39:58 | Buschel | saratoga: sampling rate is just defining the playback speed of those samples. |
20:40:09 | saratoga | but i think the difference is that the MDCT isn't always used for each frame |
20:41:04 | saratoga | so its probably easier for them if they can just assume the MDCT is always done at one sampling rate so that the SILK part doesn't have to pay attention to what the mdct sampling rate is |
20:41:27 | Buschel | well, i am not into the technical details. but i am concerned about forced src within a codec |
20:41:41 | Buschel | quality and computing wise |
20:42:14 | Prodicus | Basing stuff on 48k makes a lot of things simpler. They're able to switch seamlessly between 8,16,24, and 48k encoding modes, they don't have to signal different frequency bands but can rely on the predefined bit allocation schemes, etc. |
20:42:43 | Prodicus | Sample rate conversion should be transparent and considerably faster than encoding/decoding. |
20:43:46 | saratoga | i think for their target applications, 24/48k is probably >99% of all audio |
20:44:14 | kugel | it would be best if we supported 48k natively |
20:44:33 | Buschel | src consumes a reasonable amount of cpu power. this reduces playback time. i definately want a codec which does not alter the origin's sample rate... |
20:45:00 | saratoga | yeah for us its not ideal |
20:45:10 | Prodicus | SRC does not take even a hundredth as much cpu power as encoding or decoding |
20:45:13 | saratoga | but the codec isn't really made for portable use |
20:45:26 | saratoga | Prodicus: high quality SRC is actually a lot slower then decoding |
20:45:41 | saratoga | if you can tolerate some aliasing you can do it faster then decoding though |
20:45:59 | Buschel | src is a always trade-off between cpu and quality |
20:46:00 | Prodicus | If by "high quality" you mean sox's extra expensive sinc filter, sure. |
20:46:23 | saratoga | linear interpolation is about 3 MHz, verses about 20-25MHz for most MDCT codecs on ARM9 |
20:46:43 | saratoga | you don't have to get much better then linear interpolation before your SRC exceeds your decode time |
20:47:03 | Buschel | however, if it is designed this way we need to live with it :) |
20:47:31 | saratoga | yeah its a low latency codec, so needs of portable devices isn't really a concern for them |
20:47:38 | Buschel | but i still do not like it |
20:47:55 | | Quit mgottschlag (Read error: Connection reset by peer) |
20:48:06 | saratoga | we should make the sample rate in rockbox confirable though in case people want to run at 48k |
20:48:10 | saratoga | i don't think it would be very hard |
20:49:20 | Prodicus | I'd definitely use a 48k version, as I've been planning to reencode my entire collection in opus. |
20:50:00 | Buschel | would it be possible to change the sample rate based on the played audio files at runtime? so, 44.1, then 48, then 44.1 gaian? |
20:50:17 | saratoga | i guess just changing the sample rate define to 48000 in the dsp header would do most of it, but i bet it horribly breaks things like voice |
20:50:30 | Buschel | when crossfade is used a fixed rate is chosen |
20:50:38 | saratoga | yeah but you'd have to change clocks, which probably means stopping playback for a bit while it reclocks |
20:50:48 | kugel | voice would probably just play a bit faster |
20:50:56 | saratoga | and of course flush allt he PCM buffers since the time will be wrong |
20:51:10 | saratoga | so yes possible, but difficult and probably not ideal |
20:51:32 | saratoga | this would probably be something where we require a reboot to change |
20:51:41 | kugel | i think some high level code (dsp, ...) assumes 44.1k; low level pcm code should be fine except the hardware needs to be (re-)configured for 48k |
20:51:49 | Buschel | a small portion of silence would be fine. but you're right, the pcm buffer stuff will be a mess |
20:52:05 | saratoga | the DSP code shouldn't be assumign a sample rate, which is why we have the native frequency defines |
20:52:12 | saratoga | but who knows |
20:52:18 | saratoga | there are probably hidden assumptions |
20:52:26 | saratoga | although jhmikes has quite nicely cleaned up that code |
20:52:46 | saratoga | so yeah, try it and see :) |
20:53:09 | Buschel | Prodicus: re-encode? I hope you're not talking of re-encoding a lossy format to another lossy format? |
20:53:13 | kugel | you could use android to get it working, setting the output format to 48k is dead simple there |
20:53:21 | kugel | (I mean RaaAoA) |
20:53:52 | saratoga | setting the output format on native targets is easy too, most support 48k (or could be easily added if the driver doesn't) |
20:53:54 | Prodicus | Buschel: no, silly, I would have called that transcoding. I have the FLACs on an external hard drive. |
20:53:55 | saratoga | we use it in some plugins |
20:54:07 | Buschel | Prodicus: :) |
20:54:43 | saratoga | its just that the DSP and PCM buffering code has probably never been tested at anything but 44100 so who knows what will happen |
20:54:47 | | Join sciopath [0] (~sciopath@yer91-2-82-237-54-159.fbx.proxad.net) |
20:56:54 | kugel | do our targets support non-44.1k throughout? |
20:57:27 | Prodicus | Buschel: I've had all my music in 160kbps mp3 and have found that 80kbps opus sounds just as good to me, and then Opus's speech/hybrid modes will help considerably with my audiobooks. |
21:00 |
21:01:07 | Epicanis | Honestly, opus at 96k seems to be good for all but the most demanding "commercial" output, and 112-128kbps should cover that. Worth at least two-three steps up in size compared to mp3. |
21:01:47 | saratoga | kugel: no not all, i know the ipod 6g for instance is missing the 48k driver option |
21:02:02 | saratoga | but a lot of targets (most i think) have it, at least the stable ones |
21:03:19 | saratoga | for most music, 80k anything will sound fine, you have to pick hard samples before theres usually some problem in most formats |
21:06:15 | Prodicus | Perhaps AAC and Vorbis are "fine" at 80kbps but mp3 certainly isn't. To keep distortion low, at that kind of bitrate LAME is lowpassing at 12500 Hz, which will be pretty obvious in a lot of music. |
21:06:28 | Prodicus | Skipping the lowpass would be even worse. |
21:14:31 | saratoga | Prodicus: thats VBR mode, which is probably not what you want for < 128k |
21:14:56 | saratoga | in ABR i believe the lowpass is higher, and usually quality is better as well |
21:15:22 | saratoga | IIUC the lowpass settings in LAME are more about limitations in the VBR model then anything |
21:15:25 | AlexP | It's a shame that most formats other than mp3 are pointless for quite a lot of people due to lack of hardware support |
21:15:46 | AlexP | e.g. my car radio accepts mp3 (and maybe aac? I can't remember) |
21:15:52 | Buschel | aren't there different preset models in lame? |
21:16:29 | Buschel | i mean for encoding |
21:16:52 | Buschel | i remember some preset names were "stolen" from mpc ;) |
21:17:17 | Buschel | -> thumb, radio, standard, extreme, insane |
21:20:25 | saratoga | yeah, but they just map to different VBR quality settings or ABR settings |
21:21:05 | saratoga | yeah looking at the code, I think ABR 96 uses a 15.1 khz lowpass, which is quite reasonable |
21:21:37 | saratoga | although to be honest i never understood why they use a lowpass at all instead of just very courses quantizing higher bands |
21:22:11 | saratoga | maybe distortion? i can't understand how the stupid hybrid mp3 filter really works |
21:22:20 | Prodicus | Because the MP3 characteristic warbly high frequency distortions are worse than having no high frequency content. |
21:22:28 | saratoga | "very coarsely quantizing higher bands" |
21:22:49 | saratoga | who cares? not like you can hear higher frequencies |
21:23:18 | | Join petur [0] (~petur@rockbox/developer/petur) |
21:23:19 | Prodicus | 96kbps abr does use 15.1, but 80kbps is quite close to the level where it jumps down to 11250 |
21:23:56 | Prodicus | If you can't hear higher frequencies, why waste bits encoding them? If you can, then why listen to awful distorted artifacts? |
21:24:53 | saratoga | 11500 is recommended for 64k |
21:25:01 | saratoga | which is quite a lot lower |
21:25:12 | saratoga | mp3 will have a lot of trouble at those bitrates |
21:25:37 | saratoga | Prodicus: my question is why does not wasting bits mean you need a lowpass? |
21:26:12 | saratoga | seems like kind of a dumb way to do things given that your'e quantizing things in the frequency domain anyway |
21:26:19 | Buschel | normally the problem with hi freqs is that those will be encoded in one frame and dropped in another. this gets worse at lower bitrates. this on/off is more distracting than just limiting the bandwidth |
21:27:59 | saratoga | yeah i guess that makes sense |
21:28:59 | Prodicus | Looks like they've recently changed the ABR behavior, 80kbps now has a 13.5kHz lowpass (http://lame.cvs.sourceforge.net/viewvc/lame/lame/libmp3lame/lame.c?revision=1.366&content-type=text%2Fplain , in optimum_bandwidth()) |
21:29:19 | Buschel | if a psychoacoustic model adds a penalty to avoid this on/off it is possible to not limit the bandwidth |
21:30:49 | saratoga | i guess also mp3 has weird limitations on how different bands are quantized, so maybe its hard to do given the format's design |
21:31:19 | Prodicus | Still, at those rates you're better off spending your bits on more crucial frequency bands. I don't think the lowpass is just a "lazy psychoacoustic model" issue. Just about all mp3 encoders do the same thing. I know FhG's encoders are even more aggressive with lowpass than LAME is. |
21:32:05 | | Quit jpt9 (Quit: Bye) |
21:33:18 | Buschel | a good psymodel should put the bits where they are crucial. |
21:45:37 | | Quit WalkGood () |
21:45:48 | | Quit eckoit (Quit: eckoit) |
21:45:55 | | Quit alexbobp (Ping timeout: 256 seconds) |
21:46:54 | | Join bertrik [0] (~quassel@ip545056ba.adsl-surfen.hetnet.nl) |
21:46:54 | | Quit bertrik (Changing host) |
21:46:54 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
21:49:46 | | Join alexbobp [0] (~alex@capitalthree.pwnz.org) |
21:51:49 | *** | Saving seen data "./dancer.seen" |
21:56:29 | | Join eckoit [0] (~ryan@50.65.10.24) |
22:00 |
22:00:56 | | Quit eckoit (Ping timeout: 245 seconds) |
22:02:42 | | Quit pretty_function (Ping timeout: 255 seconds) |
22:05:52 | | Quit factor (Ping timeout: 255 seconds) |
22:07:50 | | Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) |
22:18:34 | | Join pamaury [0] (~quassel@5.157.114.2) |
22:18:34 | | Quit pamaury (Changing host) |
22:18:34 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
22:18:55 | | Join [Saint_] [0] (~saint@rockbox/user/saint) |
22:19:52 | | Quit [Saint] (Ping timeout: 264 seconds) |
22:23:24 | | Join prof_wolfff [0] (~prof_wolf@213.37.219.103.dyn.user.ono.com) |
22:23:26 | | Quit stoffel (Ping timeout: 245 seconds) |
22:27:50 | | Join factor [0] (~factor@r74-195-187-97.msk1cmtc01.mskgok.ok.dh.suddenlink.net) |
22:51:38 | | Join zchs [0] (~zchs@ool-ad02eb3f.dyn.optonline.net) |
22:54:35 | | Join lebellium_ [0] (~chatzilla@78.52.243.156) |
22:56:12 | | Quit lebellium (Ping timeout: 246 seconds) |
22:56:14 | | Nick lebellium_ is now known as lebellium (~chatzilla@78.52.243.156) |
23:00 |
23:07:05 | | Quit pamaury (Ping timeout: 245 seconds) |
23:08:51 | | Part amayer_ |
23:13:33 | derf | Buschel: The quality degradation from even a simple resampler (as long as it's not super-crappy like linear interpolation or something) will be much smaller than the degradation introduced by the lossy encoding. |
23:15:34 | Buschel | i can follow that, but i still do not like it. it contradicts my ideal of a codec |
23:15:54 | | Quit kevku (Read error: Connection reset by peer) |
23:17:11 | | Join wodz [0] (~wodz@89-76-32-53.dynamic.chello.pl) |
23:26:29 | wodz | Torne: About the sizes - striped pitch_detector.elf is 115548 bytes while pitch_detector.rock is 53448. This is fully relocated binary so relocatable elf will be slightly bigger. |
23:26:41 | derf | I mean, most actual sound cards (at least in general-purpose devices) will resample 44.1 kHz to 48 kHz anyway. |
23:26:47 | wodz | sizes are for PP build |
23:27:09 | kugel | JdGordon: ping |
23:28:32 | kugel | wodz: what's the difference between stripped elf and relocatable elf? |
23:30:13 | wodz | kugel: striped elf lack debug sections and symbols not needed for relocation. Relocatable elf contains .rel/.rela sections with relocation informations + symbol table needed |
23:30:15 | | Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) |
23:31:04 | kugel | what's in the stripped one that's not in the relocatable one? |
23:31:58 | wodz | kugel: nothing - stripped fully resolved should be subset of relocatable (neglecting veneers stuff) |
23:33:01 | kugel | it sounded like the reloctable elf would be slightly bigger than the .rock (but still much smaller than the stripped one) |
23:34:16 | wodz | ah, no it will be slightly bigger then fully resolved stripped elf |
23:34:47 | wodz | so something like 2x .rock size |
23:35:25 | wodz | I guess it is worst for smaller plugins as headers overhead will be bigger in this case |
23:37:49 | wodz | yeah, for cube it is elf:rock 38560:5364 |
23:37:56 | kugel | ffs. every image on the wps are drawn for every viewport! |
23:40:30 | kugel | ah no, it's just a very strange logic |
23:41:04 | kugel | (each image seems to exist for every viewport, but the display flag is only set for the viewport it is actually in) |
23:45:26 | wodz | hmm such big elfs seems to come from alignment set to 0x8000 ! |
23:51:51 | *** | Saving seen data "./dancer.seen" |
23:53:46 | | Quit petur (Remote host closed the connection) |
23:55:16 | wodz | yeah, turning off segments alignment (-n flag to ld) shrinks elfs quite a lot |
23:57:30 | wodz | cube is elf:rock 5908:5364 pitch_detector is elf:rock 54140:53448 |