Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2012-09-28

00:03:32kugellorenzo92 (logs): found the problem with my patch
00:03:53kugelI 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:35sansaclipzipdoes anyone know how to fix the "undefined instru" white screen on sansa clip zip? looked online and didn't find anything
01:32:46sansaclipziphappens 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:24sansaclipzipthanks. 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:31sansaclipzipi 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:12sansaclipziphaha 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:45sansaclipziphow 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:23sansaclipzipthanks 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:38sansaclipzipoh 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:08sansaclipzipthanks 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:06sansaclipziphaha 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:06sansaclipzipI'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:28MendingAnyone 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:38thals1992Hello?
05:00
05:02:18Prodicusthals1992: Hello. If you have something to say, please say it; people will respond when they come back to their irc client.
05:04:42ProdicusHaving 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:55thals1992Hi 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:14thals1992I 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:02thals1992I guess I'll just check the log tomorrow then.
05:41:00amayerare 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:22thals1992yes
06:03:04thals1992the hd01 is all buttons the hd02 is not
06:06:35thals1992plugging 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:31thals1992I 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:33thals1992 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:53webguest39hello at all
08:24:21webguest39 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:49webguest39hello zagor can you help?
08:29:14Zagorwebguest39: http://www.rockbox.org/wiki/IrcGuidelines #9 :-)
08:30:59webguest39i 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:41webguest39who can help me with my mp3 player ? my mp3 has a data abort.
08:39:28Zagorwebguest39: you need to give more details. what player? when does it happen?
08:40:08webguest39it 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:25webguest39zagor 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:21Zagorwebguest39: come on, why do we have to drag the information out of you? *when* does it happen?
08:55:34webguest39today . i have copy a mp3s and has done , and have new boot than come this
08:56:44Zagorwhich rockbox version are you running? does it happen with the latest version?
08:56:59webguest393.1.9
08:57:11webguest393.9.1
08:57:26Zagorthen first try upgrading to the latest version
08:57:52 Join Buschel [0] (~chatzilla@p57905E53.dip.t-dialin.net)
08:58:39webguest39this problem is my pc cannot connect to mp3 player
09:00
09:02:45 Join petur [0] (~petur@rockbox/developer/petur)
09:03:55webguest39my pc find my device not zagor
09:06:16 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
09:06:20Zagorwebguest39: hold the LEFT button while turning on the player
09:07:27webguest39oh thanks i have my old system
09:07:58Zagornow you can upgrade rockbox
09:08:26Zagorthis is documented in the manual: http://download.rockbox.org/daily/manual/rockbox-sansafuze/rockbox-buildch3.html#x5-280003.1.3
09:09:45webguest39ok thank you
09:12:56webguest39and now i have yet , SWI at 34EA0584 zagor
09:13:59Zagorwebguest39: again, details please. what did you change, when does it happen?
09:15:30webguest39i have upgrading to lates vision from rockbox and then have reboot . aand he has this SWI at 34EA0584
09:16:33Zagorwebguest39: which version did you install?
09:16:48webguest393.11.2
09:17:21Zagorwebguest39: ok, now try the latest dev build: http://build.rockbox.org/data/rockbox-sansafuze.zip
09:18:46webguest39Extracting on the root of the mp3?
09:19:01[Saint]yes
09:19:09webguest39ok
09:19:36webguest39and then reboot the mp3
09:20:34webguest39ok it works
09:20:41Zagorexcellent
09:20:57webguest39thank you for helping
09:21:25Zagorhave fun!
09:22:28*[Saint] is never sure if it is a good thing when the above happens or not.
09:22:29webguest39cya all and a beautiful day
09:23:47 Quit webguest39 (Quit: CGI:IRC)
09:24:19Zagor[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:38Zagoryes. it would be *better* to know, but having it fixed is still an improvement
09:25:56Zagorcorrection: having it not occur
09:31:36 Join n1s [0] (~n1s@rockbox/developer/n1s)
09:34:44Buscheln1s: did I read correct in the logs? f2 saves 32 MHz and OpusDecoder 24 MHz if moved to IRAM?
09:36:25n1sBuschel: 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:52n1sthe number for OpusDecoder is correct though
09:37:56Buschelok, I misread the logs regarding f2. could you test my changes on cf though?
09:38:36BuschelI am just rebasing to your latest change. which gives me a hard time, because I never used git before :/
09:39:04n1syeah
09:40:47Buschelnice, 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:15n1syeah, the saving on arm was more than i expected
09:42:00Buscheldefinately. How did you find out that the multiplication with coef[1] is only relevant for custom modes?
09:44:01n1sBuschel: jmspeex told me, it's always 0 the static mode is in static_does_fixed.h
09:44:26n1ss/does/modes/
09:44:48n1saalways 0 with the static mode
09:44:50Buschelahh, got it. hard to find w/o any hint
09:47:08Buschelwith 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:23n1swith 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:19kugelare theere other test files?
09:53:25Buschelgood :)
09:53:34kugel64kbit/s seems low to be useful for music
09:53:50n1skugel: yes
09:55:19n1sok, 64kbps seems to be fast enough to listen without skipping even though we need to resample
09:55:56Buschelthe 256k file needs quite some more power...
09:56:49n1skugel: 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:43Buscheln1s: you said you ported some ogg-IRAM-alloc functionality to opus to allocate OpusDecoder. will you submit this solution?
09:57:51kugeln1s: makes sense
09:58:01n1s128k is 90.2 % realtime (137.64MHz)
09:58:41n1sBuschel: not sure if it makes sense if we dynamically alloc only the one buffer
09:58:53n1sor do you want to use it for something else?
09:59:35Buschelwhy 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:00Buschel-> f2, freq, X
10:00:43Buschelwe could of course just statically allocate for now and submit a more sophisticated solution later...
10:01:52n1sis there anything that doesn't fit with the worst case allocs that would be worthwile to have in iram?
10:03:35BuschelI do not know for sure. You think we should just statically allocate for now?
10:04:18Buschelon PP: 77.3 MHz (64k), 91.7 MHz (128k), 116.1 MHz (256k)
10:05:28Buschelbrb
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:27lorenzo92kugel: good, so then?
10:53:59Buscheln1s: just found another 6 MHz on PP :)
10:56:14lorenzo92kugel: 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:50wodztiming issue?
11:00
11:02:34Buscheln1s: did your latest submit change the output on arm?
11:05:02lorenzo92wodz: 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:04lorenzo92wodz: 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:29wodzTry 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:08wodzTorne: 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:18kugellorenzo92: 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:18kugellorenzo92: what theme can I test RDS with?
11:23:15lorenzo92kugel: yes yes, same device indeed. theme that's working is cabbiev2 and radioboy
11:23:37kugelcabbiev2 doesnt have rds info does it?
11:25:04n1sBuschel: 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:30lorenzo92kugel: it has...
11:25:39lorenzo92*does
11:25:52lorenzo92both station name and rds text
11:26:09kugeldebug->FM radio suggests there's no RDS info
11:26:33kugelPI changes, PS is spaces only and RT is empty
11:27:03lorenzo92kugel: if time is being updated, then it's timing issue!
11:27:06lorenzo92*just
11:27:18lorenzo92I mean RDS CT
11:27:47Buscheln1s: there's something going here :/
11:27:49kugelah there
11:27:58kugelother station has something
11:28:10 Join Thra11 [0] (~thrall@146.90.84.243)
11:30:27kugelscrolling is strange
11:31:00Buscheln1s: of course I meant "going wrong"
11:32:06kugelwodz: doesnt the linux kernel have this?
11:33:12wodzkugel: It is rather libc part
11:33:38kugelfor loading kernel modules?
11:33:42 Join Syconaut^ [0] (viper@c-60fd72d5.162-1-64736c10.cust.bredbandsbolaget.se)
11:33:56wodzah that what you mean, yes it should have
11:34:22wodzanyway I think bflt is dead end
11:34:36kugelonly because of mips?
11:35:11 Quit Syconaut (Ping timeout: 252 seconds)
11:35:37kugelanother alternative is to reimplement elf2flt
11:35:42wodzThis is the most obvious reason. Other is arm veneers, Third is hackiness of solution.
11:35:50wodzkugel: I mostly done that
11:36:15wodzI mean I heavily rewrote it.
11:36:35kugelI meant from scratch
11:36:48wodzBut the truth is that there are relocs which can't be simply represented as simple addend
11:36:53kugelthe arm veneers arent elf2flt's fault
11:37:21kugelany other solution would face the same problem
11:37:36n1sBuschel: are you sure about the sizes of all your static allocs?
11:38:07kugeland any other solution would also need to handle the complex mips relocs, whether offline or at runtime doesnt really matter
11:38:10Buscheln1s: no, those are taken from the 64k file.
11:38:54wodzWell, 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:44wodzI 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:58Buscheln1s: my local changes screw up for arm... :(
11:40:43kugelwodz: I wonder if the ld output is fully resolved, how can there be those complex relocs?
11:41:02kugelI would think in a fully resolved binary all relocs should be most simple
11:41:26wodzkugel: Have you read my BFLT wiki page?
11:41:44kugelno, I didnt know its existence yet :p
11:42:46wodzbasically 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:48wodzIt 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:03wodzyou have to mask instruction bits and do the shifts
11:44:21wodzR_MIPS_26 is even more weird :-)
11:44:41wodzaddend is expressed in words in lower 26bits of instruction
11:45:29wodzjump address is calculated as (PC & 0xf0000000) + ((instruction & 0x3ffffff)<<2)
11:45:41wodzgood luck expressing this as a simple addend
11:46:04kugelwhat is a "simple addend" exactly?
11:46:40 Quit bluebrother (Ping timeout: 244 seconds)
11:46:40wodzwhen you get final address as base + addend.
11:46:44kugellinked to 0, so you can add it to the actual section address to get the final address?
11:46:57wodzyes thats how elf2flt works
11:46:58 Quit fs-bluebot (Ping timeout: 256 seconds)
11:47:10kugelright, I just wasn't clear about the term
11:48:06kugeland 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:40wodzwhich two?
11:48:48kugelthe two MIPS cases
11:48:53wodzyes
11:49:01 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
11:49:15wodzat least this relocations are emitted by gcc/as
11:49:23kugeldoesnt the second one appear very similarly on ARM?
11:49:50 Join pacovila [0] (~fravd@89.130.175.197)
11:50:04wodzyes it is similar to R_ARM_CALL
11:50:13kugelhm, it probably doesnt have the shift because the lower bits need to be preserved to jump into thumb
11:51:11kugelbut 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:56wodzunless you can't express offset in limited number of bits and you have to insert veneer :-)
11:52:08kugelyou said above R_MIPS_26 is also PC relative
11:53:24wodzI 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:12kugelI think our current mips targets have so little IRAM is not worth using
11:54:19Torneyeah, we are heavily relying on the fact that ARM is almost entirely PC-relative under normal usage.
11:54:27Tornewhich is not true on other arches
11:54:43Torneit just happens that other than IRAM the reloc types we actually need to handle on ARM are all easy
11:54:48Torneanyway.
11:54:58Torneyes, bflt doesn't appear to solve all of our problems particularly well
11:55:11Tornethe fact that you even had to touch elf2flt at all was a bad sign
11:55:12Torne:)
11:55:19Torneshame.
11:55:24kugelwodz: well not exactly, but it's core-only.
11:56:10Torneso yeah, maybe we look at exactly what ELF features a plain loader would actually nead
11:56:29 Quit Rower85 (Client Quit)
11:56:39wodznot that much I guess
11:57:05Torneyou 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:19wodzexactly
11:57:22 Join Rower85 [0] (husvagn@82.196.99.90)
11:57:25Torneif you don't care about checking stuff very much.
11:57:40wodzIt has also the benefit to be well documented format
11:57:51Tornehow complicated applying relocations turns out to be, depends what relocation types the architectures in question actually need in practise
11:58:05Tornebut you can just implement them as needed :)
11:58:12wodzyes
11:58:25Torneso the things i'd wonder about are, how big is the ld -r output when stripped
11:58:35Tornecompared to the flt or to the original binary
11:58:39Torneer
11:58:45Tornenot original, but the old style binary
11:59:06 Quit Rower85 (Client Quit)
11:59:08kugelyou'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:25Tornekugel: actually it is easier
11:59:35wodzkugel: it is easier as elf reloc tables store information about reloc type
11:59:36Tornethe problem with doing that in FLT is that the format itself doesn't represent the data
11:59:44Tornewhereas in ELF it just says "this is this weird kind of relocation"
11:59:54Torneand so you just have a big switch statement on reloc type and do a different thing
12:00
12:00:13Tornein flt it sounds like we are in the position of undoing some of the simplifications flt has made
12:00:28TorneFLT deliberately chose not to have a reloc type field because the systems they care about don't need it
12:01:00kugelahh, right, the flt doesnt have the reloc type info in it
12:01:10kugelI was, for a moment, forgetting this fact
12:01:16wodzFrom the size point of view FLT with additional field about reloc type will still be smaller then fully fledged elf
12:02:00wodzBut the idea of simply linking plugin as unresolved elf is appealing
12:02:15wodzno hassle with external tools, conversions etc.
12:02:39Torneif you strip all the things that aren't needed then i dunno that it's gonna be that much bigger
12:02:54Torneone thing i just thought of, is how do you actually handle iram wrt. program headers.
12:03:32Tornei.e. get it to be an identifiable phdr section that you can pick a different load address for
12:03:40wodzmy idea was to use 31bit of vma as indicator
12:05:23*Torne looks up the phdr load format
12:06:09kugelwith a normal elf you have the section and its name and you don't need to play with bits, dont you?
12:06:19Tornekugel: section info is not actually used during loading
12:06:39Tornethe loader only cares about program segments defined by program headers
12:06:56Tornewhich are much simpler and have much less parametes than sections
12:06:58Torneand also don't have names :)
12:07:54kugeloh
12:08:15 Quit petur (Quit: *plop*)
12:08:18Tornewodz: in normal elf loading, the offsets between segments are preserved
12:08:34Torneso using the vaddr for that would be weird.
12:08:43Tornei'm not sure there is a nonweird solution
12:08:43wodzTorne: I know
12:09:21lorenzo92kugel: http://pastie.org/4854699
12:09:58wodzThe benefit of elf approach would be that Torne will have the opportunity to code veneer insertion on ARMs :-)
12:11:01kugellinux kernel module loading is a lot of cod
12:11:34Tornekugel: yes, but it does at least one thing that we don't actually currently nee to do
12:11:39Tornenamely, dynamic linking
12:11:58kugel~4k lines (400 of which are arm specific) if I see this right
12:12:00Tornealso, it is Really Careful about everything. :p
12:12:14kugelTorne: but we want to do it eventually
12:12:20Tornekugel: i don't know that we do
12:12:22Torneat least, not in the same way
12:12:32Tornedoing unix style named symbol dynamic linking would be very expensive
12:12:42Tornewe probably don't *ever* want to do that.
12:12:48Tornewe probably want ot link by ordinal the way DLLs work
12:13:03wodzkugel: are you looking at linux or uclinux sources?
12:13:11kugellinux
12:14:09kugelTorne: sorry, by dynamic linking I meant link to non-constant addresses
12:14:33kugelright, the kernel links kernel functions, while we go through the api struct
12:15:28TorneWell, we are already linking to non-constant addresses, through the API struct ;)
12:15:38TorneIt just happens that tehre's only one non-constant address.
12:15:54TorneWe 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:04Tornewhich would eliminate an indirection at every callsite
12:16:15Tornebut i expect we would wnat to do that by ordinal in the former api struct
12:16:17Tornerather than by name
12:16:26Tornewhich is pretty simple in practise :)
12:16:35Tornealso, we only ahve one place to search (core)
12:16:48Tornerather than having to search an incrementally constructed symbol namespace made of multiple dynamic objects
12:17:20Tornein practise i'm not even sure that eliminating the API struct woul dbe worth it
12:17:35kugelI 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:47TorneOh
12:17:50Tornethat's just relocation, though
12:17:57kugelI don't think we want to touch the method to call core functions
12:18:01Torneand 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:05Torneer
12:18:07Torneevery relocation type
12:19:33*Torne shrugs
12:20:02Tornemy 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:19Torneand 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:38Buscheln1s: found the issue. something is fishy about the standard implementation of MULT32_32_Q31()
12:20:47Tornei suggested it because i thought it would be significantly easier, but it looks like it's not :p
12:21:08Buscheln1s: the current implementation does not give the same results as a proper int64*int64>>31
12:21:55Torneso 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:07Tornebecause at least that way we get to use a standard and well known set of tools
12:23:36kugelwodz: ld doesnt insert veneers for mips?
12:24:11Tornekugel: that trick is pretty ARM-EABI specific
12:24:28wodzkugel: Don't think so. It can adjust R_MIPS_HI16 accordingly.
12:24:42Tornemost toolchains have always just required you to build your code with appropriate memory models
12:24:47Tornesee real-mode x86
12:24:56kugelI thought so too, but the R_MIPS_26 is actually the same problem
12:25:04Tornewhere you get to choose between "references to memory are all slow" or "you can only address a bit of memory"
12:25:40wodz26bits is quite a lot
12:26:39Torneis it a byte address, or a word address, also? :)
12:26:48wodzword
12:27:04 Quit minouch (Quit: CGI:IRC)
12:27:15Torneso +/-128MB?
12:27:18Tornethat's not too bad.
12:27:20TorneARm only does 32MB
12:27:23wodzand also MIPS address space is divided so 31bit of vma have special meaning
12:27:26Torneor 4MB in thumb
12:28:09wodzguess why I though about using 31bit of vma as marker :-)
12:30:28wodzI'll look at this elf thing. But my spare time is truly restricted so it may take forever...
12:30:41n1sBuschel: ah
12:30:58n1si haven't looked at it, is it used much
12:31:27kugelcan't we reuse an elf-loader from somewhere?
12:31:49kugel(and strip it down as-needed
12:31:55Buscheln1s: 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:26wodzkugel: I can't find anything suitably simple.
12:32:43n1sBuschel: did you check how big the diff in the output is?
12:32:52Buschelno, not yet
12:33:02kugelperhaps newlib or uclibc?
12:33:54wodzwill look
12:41:22n1sBuschel: yeah that macro looks weird, it's only doing 3 16*16 multiplications
12:41:47Buscheln1s: if I replace the current implementation with a real int64-multplication the results differs by max +/-3 (of 32768) in few situations
12:41:58Buschelso, we better replace it
12:42:16Buschelgotta pick up my son from Kindergarden now :)
12:56:37 Quit lorenzo92 (Remote host closed the connection)
12:58:24lebellium[Saint] logs : "%?tz<%tz|>" is really ugly" > indeed, fixed
13:00
13:00:03lebellium"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:02lebelliumdoes that come from the RDS issues in the latest builds?
13:05:00 Quit mgottschlag (Ping timeout: 245 seconds)
13:16:15wodzprex seems to have pretty simple elf loader
13:18:45 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93)
13:20:05kugellooks good
13:21:00 Quit Buschel (Ping timeout: 246 seconds)
13:23:46wodzelf_reloc.c for ARM doesn't care about call offset though. Anyway it seems like good start.
13:24:39n1sBuschel: yeah sounds good, would be nice to compare with a float decoder too
13:24:42kugelcode seems clean also
13:26:42 Quit perrikwp (Ping timeout: 256 seconds)
13:27:11wodzcan't find license but IIRC it is some form of BSD license
13:27:39kugelthe front page of prex says bsd
13:28:02kugelthe files have a license header too
13:29:18wodzthe question which BSD it is
13:29:51wodzah 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:39Buscheln1s: do you have float-decoder at hand?
15:01:45n1sno, not sure what would be the easiest app to use that will spit out a wav file
15:03:03Buscheln1s: is linopus working when FIXED_POINT is not sdefined?
15:03:34n1sright, that would be the easiest solution if it works :)
15:03:46n1sno idea if it does though
15:04:05n1seasy to test
15:04:51Buschelas we are talking of testing -> http://pastie.org/4855567 (71 MHz on pp)
15:06:47n1snope, doesn't build without FIXED_POINT
15:07:34n1sBuschel: what changed since lthe last patch?
15:09:11Buscheln1s: 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:28Buschel=) = " = 0 "
15:09:43 Join jpt9 [0] (~jpt9@unaffiliated/jpt9)
15:10:42jpt9Hey. 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:12n1sjpt9: correct
15:19:43n1sBuschel: 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:22jpt9n1s: Thanks. It looks like a pretty neat codec, especially for audiobooks.
15:20:27Buscheln1s: 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:21n1sBuschel: ok, i think i'll hack something up to see if it makes a difference :)
15:21:42Buschelit will, but I would not expect too much ;)
15:24:27lebelliumbertrik: 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:01Buscheln1s: 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:44n1ssounds like it
15:29:18Buschelis 48 kHz the native samplerate of the codec? or is it possible to synthesize to 44.1 kHz?
15:29:49bertriklebellium: nothing was changed recently regarding RDS
15:30:06bertrikRDS uses up an extra thread, maybe something else claimed it
15:30:37bertrikbut there does appear to be some kind of bug because RDS text seems to be updated before an entire message is received
15:30:59bertrikthe idea was that it's only updated on the UI when a full message is received
15:31:14n1sBuschel: yeah 48kHz, the downsampling in the deemphasis loop can downsample by integer factors when outputting (24, 16, 12, 8kHz)
15:31:32n1snot really usefull for us
15:32:07Buscheln1s: 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:30n1sah
15:33:40n1sthe downsampling is rather crude too, it just skips samples when outputting
15:34:03Buschelugly. best wishes from aliasing ;)
15:34:28lebelliumbertrik: 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:32Buscheln1s: 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:52n1sBuschel: the sim is segfaulting with your last patch
15:41:16Buschellet me check
15:42:07Buschelwhich file? the 64k one?
15:42:16n1syeah
15:42:30Buschelworks like charm here
15:42:42n1shmm, weird
15:42:51Buschellet me make a clean build
15:43:04n1sjust doing the same
15:45:43Buschelstill works
15:46:48Buschelbtw, I crosscompile a win32 executable under ubuntu64
15:47:07n1si use native linux 64
15:48:47Buschelwhat happens if you drop the change to fixed_generic.h?
15:51:27n1sno difference, i'll try gdb
15:51:39***Saving seen data "./dancer.seen"
15:52:26Buschelok
15:55:35 Quit mortalis (Quit: Leaving)
15:58:32n1si don't get it, it crashes in tf_decode
16:00
16:00:16n1si would try valgrind but i don't remember how to make the sim work with it
16:00:46Buschelcan you just roll back the changes file-by-file? this way we can dig into the causing change
16:01:14n1syeah, i'll try to look at it later or tomorrow, gtg now
16:01:23Buschelsee you later
16:07:52 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel)
16:08:23kugelpbertrik: i saw partial strings on the fms
16:08:33kugelpin*
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:54n1sBuschel: 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:28n1sincreasing the size to 26532 makes it work fine
18:33:06Buscheln1s: ahh, ok.
18:33:11n1si'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:23n1ss/att/attr/
18:34:19Buschelall of the IRAM changes are dirty hacks. we should never submit it like this :)
18:34:39n1salso 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:40Buschelif i understood correctly custom modes is used to define other windows, overlap lengths etc.
18:36:30n1syeah but will people create such files and expect them to work?
18:36:57n1sor is it just something that's intended for special purpose implementations?
18:37:11Buschelno idea
18:44:21n1s"Use
18:44:22n1s * of Opus Custom is discouraged for all but very special applications
18:44:22n1s * for which a frame size different from 2.5, 5, 10, or 20 ms is needed
18:44:22DBUGEnqueued KICK n1s
18:44:22n1s * (for either complexity or latency reasons) and where interoperability
18:44:22n1s * is less important."
18:44:48n1sso i guess we can ignore it and hope common encoder apps don't let users enable it
18:45:53BuschelI 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:50n1si 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:51Buschelwe 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:32BuschelI 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:48Buschelwhat do you think?
18:53:52n1syeah, that's safer
18:54:24n1si'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:13Buschelsomething like this -> http://pastie.org/4856637
18:59:20 Join TheSphinX^ [0] (~briehl@p5B323F13.dip.t-dialin.net)
19:00
19:00:42Buschelbeer 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:56saratogaBuschel: opus resamples everything to 48k internally
19:32:25saratogaapparently 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:44saratogai 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:06saratogaoutside 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:33Buschelsaratoga: 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:54saratogabuschel: theres some discussino about this on HA i think
20:39:58Buschelsaratoga: sampling rate is just defining the playback speed of those samples.
20:40:09saratogabut i think the difference is that the MDCT isn't always used for each frame
20:41:04saratogaso 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:27Buschelwell, i am not into the technical details. but i am concerned about forced src within a codec
20:41:41Buschelquality and computing wise
20:42:14ProdicusBasing 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:43ProdicusSample rate conversion should be transparent and considerably faster than encoding/decoding.
20:43:46saratogai think for their target applications, 24/48k is probably >99% of all audio
20:44:14kugelit would be best if we supported 48k natively
20:44:33Buschelsrc 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:00saratogayeah for us its not ideal
20:45:10ProdicusSRC does not take even a hundredth as much cpu power as encoding or decoding
20:45:13saratogabut the codec isn't really made for portable use
20:45:26saratogaProdicus: high quality SRC is actually a lot slower then decoding
20:45:41saratogaif you can tolerate some aliasing you can do it faster then decoding though
20:45:59Buschelsrc is a always trade-off between cpu and quality
20:46:00ProdicusIf by "high quality" you mean sox's extra expensive sinc filter, sure.
20:46:23saratogalinear interpolation is about 3 MHz, verses about 20-25MHz for most MDCT codecs on ARM9
20:46:43saratogayou don't have to get much better then linear interpolation before your SRC exceeds your decode time
20:47:03Buschelhowever, if it is designed this way we need to live with it :)
20:47:31saratogayeah its a low latency codec, so needs of portable devices isn't really a concern for them
20:47:38Buschelbut i still do not like it
20:47:55 Quit mgottschlag (Read error: Connection reset by peer)
20:48:06saratogawe should make the sample rate in rockbox confirable though in case people want to run at 48k
20:48:10saratogai don't think it would be very hard
20:49:20ProdicusI'd definitely use a 48k version, as I've been planning to reencode my entire collection in opus.
20:50:00Buschelwould 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:17saratogai 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:30Buschelwhen crossfade is used a fixed rate is chosen
20:50:38saratogayeah but you'd have to change clocks, which probably means stopping playback for a bit while it reclocks
20:50:48kugelvoice would probably just play a bit faster
20:50:56saratogaand of course flush allt he PCM buffers since the time will be wrong
20:51:10saratogaso yes possible, but difficult and probably not ideal
20:51:32saratogathis would probably be something where we require a reboot to change
20:51:41kugeli 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:49Buschela small portion of silence would be fine. but you're right, the pcm buffer stuff will be a mess
20:52:05saratogathe DSP code shouldn't be assumign a sample rate, which is why we have the native frequency defines
20:52:12saratogabut who knows
20:52:18saratogathere are probably hidden assumptions
20:52:26saratogaalthough jhmikes has quite nicely cleaned up that code
20:52:46saratogaso yeah, try it and see :)
20:53:09BuschelProdicus: re-encode? I hope you're not talking of re-encoding a lossy format to another lossy format?
20:53:13kugelyou could use android to get it working, setting the output format to 48k is dead simple there
20:53:21kugel(I mean RaaAoA)
20:53:52saratogasetting the output format on native targets is easy too, most support 48k (or could be easily added if the driver doesn't)
20:53:54ProdicusBuschel: no, silly, I would have called that transcoding. I have the FLACs on an external hard drive.
20:53:55saratogawe use it in some plugins
20:54:07BuschelProdicus: :)
20:54:43saratogaits 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:54kugeldo our targets support non-44.1k throughout?
20:57:27ProdicusBuschel: 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:07EpicanisHonestly, 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:47saratogakugel: no not all, i know the ipod 6g for instance is missing the 48k driver option
21:02:02saratogabut a lot of targets (most i think) have it, at least the stable ones
21:03:19saratogafor most music, 80k anything will sound fine, you have to pick hard samples before theres usually some problem in most formats
21:06:15ProdicusPerhaps 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:28ProdicusSkipping the lowpass would be even worse.
21:14:31saratogaProdicus: thats VBR mode, which is probably not what you want for < 128k
21:14:56saratogain ABR i believe the lowpass is higher, and usually quality is better as well
21:15:22saratogaIIUC the lowpass settings in LAME are more about limitations in the VBR model then anything
21:15:25AlexPIt'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:46AlexPe.g. my car radio accepts mp3 (and maybe aac? I can't remember)
21:15:52Buschelaren't there different preset models in lame?
21:16:29Buscheli mean for encoding
21:16:52Buscheli remember some preset names were "stolen" from mpc ;)
21:17:17Buschel-> thumb, radio, standard, extreme, insane
21:20:25saratogayeah, but they just map to different VBR quality settings or ABR settings
21:21:05saratogayeah looking at the code, I think ABR 96 uses a 15.1 khz lowpass, which is quite reasonable
21:21:37saratogaalthough to be honest i never understood why they use a lowpass at all instead of just very courses quantizing higher bands
21:22:11saratogamaybe distortion? i can't understand how the stupid hybrid mp3 filter really works
21:22:20ProdicusBecause the MP3 characteristic warbly high frequency distortions are worse than having no high frequency content.
21:22:28saratoga"very coarsely quantizing higher bands"
21:22:49saratogawho cares? not like you can hear higher frequencies
21:23:18 Join petur [0] (~petur@rockbox/developer/petur)
21:23:19Prodicus96kbps abr does use 15.1, but 80kbps is quite close to the level where it jumps down to 11250
21:23:56ProdicusIf you can't hear higher frequencies, why waste bits encoding them? If you can, then why listen to awful distorted artifacts?
21:24:53saratoga11500 is recommended for 64k
21:25:01saratogawhich is quite a lot lower
21:25:12saratogamp3 will have a lot of trouble at those bitrates
21:25:37saratogaProdicus: my question is why does not wasting bits mean you need a lowpass?
21:26:12saratogaseems like kind of a dumb way to do things given that your'e quantizing things in the frequency domain anyway
21:26:19Buschelnormally 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:59saratogayeah i guess that makes sense
21:28:59ProdicusLooks 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:19Buschelif a psychoacoustic model adds a penalty to avoid this on/off it is possible to not limit the bandwidth
21:30:49saratogai 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:19ProdicusStill, 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:18Buschela 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:33derfBuschel: 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:34Buscheli 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:29wodzTorne: 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:41derfI mean, most actual sound cards (at least in general-purpose devices) will resample 44.1 kHz to 48 kHz anyway.
23:26:47wodzsizes are for PP build
23:27:09kugelJdGordon: ping
23:28:32kugelwodz: what's the difference between stripped elf and relocatable elf?
23:30:13wodzkugel: 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:04kugelwhat's in the stripped one that's not in the relocatable one?
23:31:58wodzkugel: nothing - stripped fully resolved should be subset of relocatable (neglecting veneers stuff)
23:33:01kugelit sounded like the reloctable elf would be slightly bigger than the .rock (but still much smaller than the stripped one)
23:34:16wodzah, no it will be slightly bigger then fully resolved stripped elf
23:34:47wodzso something like 2x .rock size
23:35:25wodzI guess it is worst for smaller plugins as headers overhead will be bigger in this case
23:37:49wodzyeah, for cube it is elf:rock 38560:5364
23:37:56kugelffs. every image on the wps are drawn for every viewport!
23:40:30kugelah no, it's just a very strange logic
23:41:04kugel(each image seems to exist for every viewport, but the display flag is only set for the viewport it is actually in)
23:45:26wodzhmm 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:16wodzyeah, turning off segments alignment (-n flag to ld) shrinks elfs quite a lot
23:57:30wodzcube is elf:rock 5908:5364 pitch_detector is elf:rock 54140:53448

Previous day | Next day