--- Log for 22.11.110 Server: card.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 6 days and 17 hours ago 00.03.37 Join MethoS- [0] (~clemens@134.102.106.250) 00.10.08 Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) 00.13.57 # saratoga: The beast also charges from USB 00.14.05 # But unlike the F, it doesn't charge from USB when turned off (the F does) 00.14.27 # do I need to force it? i just plugged it in and it said discharging until i added ac power 00.15.18 Quit ender` (Quit: "I'm the head wizard now. I've only got to give an order and a thousand wizards will ... uh ... disobey, come to think of it, or say 'What?', or start to argue. But they have to take notice." -- Archchancellor (Terry Pratchett: Lords and Ladies)) 00.15.19 # I generally don't have to. 00.15.27 # Just hold Menu while plugging in, and there it goes. 00.15.49 # It doesn't show the same charging display that AC power does, but battery charge does go up over time 00.16.01 Quit dfkt (Ping timeout: 245 seconds) 00.16.25 # hmm it didn't go into USB mode either, so maybe i should try a different cable 00.20.49 # oh you said menu, i was expecting it to be select like on teh sansas 00.20.51 # that worked 00.21.12 # any reason we have a specific button to hold to get charge mode? it would be easier for users if you could hold any button 00.22.53 Join webguest43 [0] (~5a23269f@giant.haxx.se) 00.24.22 Quit webguest43 (Client Quit) 00.26.56 # aligning a few structs in libmad speed it up on the beast 00.26.59 # saratoga: I've been saying it should be any button for a while. I haven't really heard anyone argue strongly against it. 00.27.10 # any idea where the check is? 00.27.25 # grep suggests usb.c or powermangmt.c 00.27.39 # No idea. 00.28.18 # I think people have argued against it, but I honestly can't remember anything beyond "some buttons could have unexpected behaviour like fast forward" which doesn't seem much of a real problem / likelihood (I think people will realize holding a button will do whatever that button *does* until they insert the USB cable) 00.30.05 Quit stripwax (Quit: http://miranda-im.org) 00.30.29 Join ReimuHakurei [0] (~reimu@adsl-75-16-233-192.dsl.kntpin.sbcglobal.net) 00.30.43 # i wonder how you force alignment in a .S file 00.33.41 Quit dys (Ping timeout: 276 seconds) 00.33.54 Join JdGordon| [0] (~jonno@vl10.gw.ok-labs.com) 00.33.54 Quit JdGordon| (Changing host) 00.33.54 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 00.34.32 Quit JdGord (Quit: Bye) 00.37.59 # saratoga: the usb connect thing is something that always get discussed but nothing ever happens with 00.38.10 # do you know where the check is 00.38.21 # I personally think a menu on connect is the best way to do it but noone will come to an agreement 00.38.42 # no, gevaerts would probbaly know 00.38.52 # or search for button_get() in firmware/ 00.40.44 # saratoga: usb_power_button() in usb.c 00.41.13 # FWIW I believe I can pick up a Cowon S9 for $175. Not cheap, but cheaper than $250. 00.41.14 # The button to use is in usb.h 00.41.30 # what header do i need to use MEM_ALIGN 00.41.34 # JdGordon|: Well there still needs to be a decision for cases where a menu can't come up, or be used for whatever reason, so menuless behaviour is still good whether or not a menu will go in in the future. 00.41.56 # it shouldn't check for any particular button, just if (btn) 00.42.01 # no bitmask 00.42.22 # that has been one of the common arguments 00.42.25 # ahh, nevermind. That was a local price. On ebay one can score a refurb for less than that. 00.42.45 # * JdGordon| is hoping to score a mini2g for $30 :) 00.43.28 # wtf adding codec.h is enough for layer3.c, but not for huffman.c 00.43.36 # can one macro depend on two headers? 00.45.27 # and make clean returns to both not compiling . . . 00.47.44 # sounds like you got yerself a broken header :p 00.47.58 # how the hell do i get system.h into a codec 00.49.53 # what do you need from it? it might be wrapped in !PLUGIN/CODEC? 00.50.20 # i just want to use mem_align in a codec 00.50.31 # and it randomly works or doesn't work in some files depending on the make -j setting 00.53.01 # huh __attribute__((aligned(16))) doesn't work either 00.53.11 # are there restrictions on what types of variables can be aligned? 00.53.21 # is your system stuffed? 00.53.38 # that all just sounds broken 00.54.13 *** Saving seen data "./dancer.seen" 00.54.52 # no i see what it is 00.55.05 # the attribute has to go before the = 00.55.34 # I was doing "int x = 0 MEM_ALIGN;" 01.03.43 # anyone available to test on android? 01.04.23 # is it possible to go on web site with rockbox 01.04.25 # i get a small speed up on the beast, but I'd be curious what its like on Android where alignment seems more important 01.04.29 # no 01.06.47 Quit markun (Ping timeout: 240 seconds) 01.07.14 # what does USBPOWER_BTN_IGNORE do exactly? 01.07.46 # is it preview to appear its a future version? 01.09.05 # no 01.09.51 # why? 01.09.53 # oh the sansa USBPOWER_BTN_IGNORE is power, but holding power will just turn off the player 01.09.56 # what is the idea here? 01.10.04 # Jonas29: not possible 01.11.54 Join dys [0] (~andreas@krlh-5f72148d.pool.mediaWays.net) 01.12.26 # saratoga: why is it not possible? 01.12.37 # hardware limitations 01.12.42 # ok 01.13.45 # on the ipod touch, there is a hardware limitations 01.15.23 # we don't run on the ipod touch 01.16.14 # USBPOWER_BTN_IGNORE was added by amiconn in r7674 specifically for the archos players, it seems people continued to update the macros as new players were added even though they're often nonsensical 01.17.03 # ok it is probably eventually provided 01.17.40 # if it is, it'll probably be as an application so you would just use the apple web browser 01.19.13 # gevaerts: logs say you added the inverted USB connect logic for the H10, do you remember why thats needed? 01.28.51 Join markun [0] (~markun@5ED33C2C.cm-7-4a.dynamic.ziggo.nl) 01.28.51 Quit markun (Changing host) 01.28.51 Join markun [0] (~markun@rockbox/developer/markun) 01.34.21 # saratoga: What button is it on the H10. I seem to remember when that happened and it making sense, but I can't for the life of me remember why so I may just be confused 01.34.48 # BUTTON_RIGHT 01.37.18 Quit ReimuHakurei (Ping timeout: 264 seconds) 01.40.31 Join Keripo [0] (~Keripo@eng239.wireless-resnet.upenn.edu) 01.48.46 # bah we use rockbox USB anyway, so that code never runs 01.48.52 # gonna throw up a patch 01.51.05 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 01.55.50 Quit Llorean (Read error: Connection reset by peer) 02.07.30 # FS#11769 - Change USB charge mode detection key 02.07.48 # i'd appreciate if amiconn or someone else who wrote the code originally for archos could comment on it 02.10.48 Join ReimuHakurei [0] (~reimu@74.112.212.15) 02.18.55 # how hard is it to add a yes/no menu option to a plugin? 02.20.15 # not at all 02.20.17 Quit BHSPitMonkey (Ping timeout: 265 seconds) 02.21.17 Join Llorean [0] (~DarkkOne@adsl-66-142-150-38.dsl.hstntx.swbell.net) 02.21.38 Quit Llorean (Client Quit) 02.22.47 # JdGordon|: right now, test_codec calls "do_menu" and then checks the result to figure out what to do, what would I need to have an option to set boosting to yes/no without returning from teh do_menu call ? 02.23.00 # basically i want to be able to choose any of the options on the menu with or without boosting 02.24.54 # probably not very much... hang on 02.27.29 # just add an item to the MENUITEM_STRINGLIST() and check for it, then goto show_menu; 02.30.50 # JdGordon|: I have to do a "rb->set_option" if I want the yes/no menu right? 02.31.19 # sounds right 02.31.32 # umm, maybe not 02.32.16 # you could just do "toggle boost" and then a splash saying "Boost on/off" 02.33.40 # yes/no is probably better though, since eventually i want to have othe roptions 02.34.09 # in the opt_items structs, what does the second column mean? its usually -1 02.34.10 # I cant remember if set_option only works with the global_setting settings or not 02.34.13 # ... probably doesnt 02.34.18 # lang string 02.35.23 # umm, I meant it probably *does* work how you want it 02.36.40 # yeah i figured 02.36.47 # well compiling now, will bug you in probably 1 minute 02.37.40 # finally getting around to fixing up test_codec a little 02.40.30 # JdGordon|: ok it draws the menu, but it doesn't actually update teh variable 02.40.52 # i just did "rb->set_option("Boosting", &boost, INT, boost_settings, 2, NULL);" 02.40.52 # pastebin 02.40.56 # where boost is the variable 02.41.02 # it apparently stays set to zero 02.41.24 # did it pop up the set opiton gui? 02.41.44 # yeah 02.41.52 # and it even defaulted to the right value 02.41.58 # but changing it didn't seem to do anything 02.42.11 # http://pastebin.com/MvpmVnBB 02.42.36 # I havnt looked at set_option() is AGES, check how other plugins use it 02.44.27 # i'm using it the same as fireworks.c, so maybe i'm doing something else wrong 02.44.45 Join enginerd [0] (~znielsen@cblmdm24-53-147-95.buckeyecom.net) 02.46.21 # Anybody have experience with rockbox on a Toshiba Gigabeat S? 02.46.46 # a little, just playing with it now 02.47.45 # I had 3.6 installed previously with very few issues and I tried to update to 3.7 and am having trouble 02.48.08 # when I plug the device into the computer it enters the "error" screen 02.48.46 # I was able to get it to load but as soon as I reconnected to add music it started acting up 02.49.01 # does rockbox actually work on it? 02.49.17 # it did at first but I can't get it to load now 02.49.23 # probably a screwed up file system 02.49.32 # and suggestions 02.50.07 # JdGordon|: any idea why test_codec doesn't update teh screen if the backlight is off? 02.50.27 # it means that if the backlight goes off while the plugin is running, then it finishes, theres no way to get the output 02.50.35 # i'tll just show the last thing blitted to the screen while it was on forever 02.50.57 # battery saving, on some targets no updates happen with the backlight off 02.51.52 # how do i tell the screen to update the framebuffer if the screen is off? 02.52.01 Join Llorean [0] (~DarkkOne@adsl-66-142-150-38.dsl.hstntx.swbell.net) 02.52.03 # I don't know if you can 02.52.21 Quit Llorean (Changing host) 02.52.21 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 02.54.15 *** Saving seen data "./dancer.seen" 02.54.29 # JdGordon|: I think the problem is i'm not telling set_option what to put in the output correctly 02.54.43 # i assume it just puts the index of the option, but maybe thats not the case? 02.54.55 # thats what it should be doing 02.55.24 # whats that last NULL param? 02.56.00 # i'm not sure, but other things seem to do it 02.58.21 # could you take another look at what I have? http://pastebin.com/YjNL263V 02.58.27 # boost seems to be always zero 02.58.39 # it must be something stupid 03.00.10 # it looks correct :/ 03.02.13 # wait 03.02.21 # the Yes/No are shown in reverse order on the screen 03.02.33 # so Yes maps to 0 and No to 1 I bet 03.04.03 Quit froggyman (Quit: Bye) 03.04.20 # which target? 03.05.07 # clip+ 03.05.28 # clip+ shouldnt be swapping things 03.05.35 # yeah I don't get it 03.05.41 # the struct has NO, then YES 03.05.46 # but on device its YES then NO 03.06.09 # i'm going to make the menu print the values it returns 03.06.26 Quit Boldfilter (Quit: Boldfilter) 03.06.47 # saratoga: I used the gbs_update_1_2_us.exe to restore the device (which worked as it should). When I run the beastpatcher.exe and it should reboot to "bootloader USB mode" it enters the error number 2 03.06.53 # any ideas? 03.07.01 # no, but check the wiki 03.07.24 # theres a lot of documentation there 03.07.47 # ok 03.08.55 # oh fucking hell how does log_text not recognize \n as new line 03.10.00 # does the beast not have boosting? 03.14.39 # I think yes it doesnt 03.15.00 # weird 03.15.27 Quit DerPapst (Quit: Leaving.) 03.16.02 Join eWill [0] (~chatzilla@adsl-99-139-149-70.dsl.dytnoh.sbcglobal.net) 03.16.04 # that wouldnt stop set_option() from working though 03.17.53 # Say I install RB to a Fuze v2, and all is good. Later I upgrade RB, but some core RB boot file gets corrupted, and RB won't boot. Does this mean I will have to CRACK OPEN my player in order to shot the two pins that allow recovery mode? 03.18.10 # *shot = short 03.18.57 # eWill: no, you can still hold the left button to boot the OF 03.19.13 # thanks a lot :) 03.20.40 # JdGordon|: i think its working now 03.20.46 # not really sure what i was doing wrong 03.20.58 Quit enginerd (Quit: Leaving) 03.22.59 # New commit by 03saratoga (r28637): Add option to run test_codec unboosted on players with boosting. 03.24.50 Join froggyman [0] (~seth@unaffiliated/froggyman) 03.25.01 # r28637 build result: All green 03.28.03 # Just ordered a re certified Fuze v2 4gb. I'm all excited. 03.28.14 # New commit by 03saratoga (r28638): Fix mistake on targets without frequency scaling. 03.30.10 # r28638 build result: All green 03.42.24 Quit eWill (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630]) 03.43.11 Join Xerion_ [0] (~xerion@54194281.cm-5-2b.dynamic.ziggo.nl) 03.45.03 Quit Xerion (Ping timeout: 240 seconds) 03.45.04 Nick Xerion_ is now known as Xerion (~xerion@54194281.cm-5-2b.dynamic.ziggo.nl) 03.45.23 Quit Rob2223 (Read error: Connection reset by peer) 03.45.58 Join Rob2222 [0] (~Miranda@p4FFF1EE5.dip.t-dialin.net) 03.51.15 # New commit by 03saratoga (r28639): Force alignment of various data structures in libmad. Speeds up Gigabeat S decoding by about 1MHz. 03.52.56 # r28639 build result: All green 03.57.52 # kugel: i can't get your ruby script to parse the MHz field on my test_codec output 03.57.59 # i just get 0MHz 04.01.56 Join dys` [0] (~andreas@krlh-5f727557.pool.mediaWays.net) 04.03.59 # with my mp3 optimizations, mp3 is now faster then vorbis on arm11 04.04.03 Quit bluebrother (Disconnected by services) 04.04.05 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 04.06.49 Quit dys (Ping timeout: 276 seconds) 04.14.13 Join Barahir [0] (~jonathan@frnk-590fc885.pool.mediaWays.net) 04.14.29 Quit Barahir_ (Read error: Operation timed out) 04.18.42 Quit Keripo (Read error: Connection reset by peer) 04.19.20 Join Keripo [0] (~Keripo@eng239.wireless-resnet.upenn.edu) 04.35.45 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 04.45.43 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 04.46.33 Quit Jonas29 (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101027154941]) 04.47.58 Quit TheSeven (Ping timeout: 240 seconds) 04.53.12 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.54.17 *** Saving seen data "./dancer.seen" 04.54.43 Quit anewuser () 04.55.37 Quit pixelma (Disconnected by services) 04.55.39 Quit amiconn (Disconnected by services) 04.55.39 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.55.39 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.55.41 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.55.59 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 05.01.53 Join dys`` [0] (~andreas@krlh-5f7226f8.pool.mediaWays.net) 05.03.41 Quit Keripo (Quit: Leaving.) 05.04.01 Quit dys` (Ping timeout: 276 seconds) 05.06.57 Quit amiconn (Quit: No Ping reply in 64 seconds.) 05.07.06 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 05.07.26 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 05.10.37 Join Llorean1 [0] (~DarkkOne@ppp-70-250-112-222.dsl.hstntx.swbell.net) 05.10.38 Quit Llorean (Read error: Connection reset by peer) 05.13.16 Nick Llorean1 is now known as Llorean (~DarkkOne@ppp-70-250-112-222.dsl.hstntx.swbell.net) 05.13.21 Quit Llorean (Changing host) 05.13.21 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 05.14.52 Quit saratoga (Quit: Page closed) 05.21.16 Join ReimuHakurei_ [0] (~reimu@74.112.212.15) 05.25.16 Quit ReimuHakurei (Ping timeout: 255 seconds) 05.34.20 Quit ps-auxw (Ping timeout: 260 seconds) 05.44.05 Quit Horscht (Quit: Verlassend) 05.45.40 Join ps-auxw [0] (~arneb@p4FF7EFEE.dip.t-dialin.net) 05.46.23 Quit factor (Quit: Leaving) 05.46.35 Quit MethoS- (Remote host closed the connection) 06.02.19 Join KiwiCam [0] (~Kiwicam@ip-118-90-117-233.xdsl.xnet.co.nz) 06.05.25 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 06.12.21 Quit InsDel (Read error: Connection reset by peer) 06.29.02 Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 06.31.01 Part toffe82 06.39.40 Quit KiwiCam (Ping timeout: 260 seconds) 06.50.29 Join Llorean1 [0] (~DarkkOne@adsl-69-153-200-83.dsl.hstntx.swbell.net) 06.50.43 Quit Llorean (Disconnected by services) 06.50.45 Nick Llorean1 is now known as Llorean (~DarkkOne@adsl-69-153-200-83.dsl.hstntx.swbell.net) 06.50.47 Quit Llorean (Changing host) 06.50.47 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 06.54.19 *** Saving seen data "./dancer.seen" 07.11.11 Join xxcv [0] (~hello@c211-30-174-99.carlnfd1.nsw.optusnet.com.au) 07.17.38 Quit JesusFreak316 (Ping timeout: 245 seconds) 07.28.20 Quit JdGordon| (Quit: leaving) 07.32.36 Join Buschel [0] (~chatzilla@p54A3A5B7.dip.t-dialin.net) 07.34.49 Join KiwiCam [0] (~Kiwicam@ip-118-90-1-20.xdsl.xnet.co.nz) 07.35.39 Join JdGord [0] (~jd@122.110.124.5) 07.36.04 Join Topy [0] (~Topy44@f048107186.adsl.alicedsl.de) 07.39.43 Quit T44 (Ping timeout: 245 seconds) 08.04.35 # New commit by 03saratoga (r28640): Align various libwma buffers. Saves about 1 MHz on the Gigabeat S. 08.06.06 # saratoga: stil awake? 08.06.40 # r28640 build result: All green 08.08.23 # saratoga: can you give this a try on your beast? -> http://pastie.org/1316790 08.10.49 Join saratoga [0] (9803c6dd@gateway/web/freenode/ip.152.3.198.221) 08.12.13 # Buschel: 35.93 with that patch 08.12.50 # saratoga: thanks, and without? 08.13.21 # there is still no atrac3 sample in our test file compilation 08.13.29 # yes I made one tonight 08.13.42 # just have to find a CDR and I can make one from the official test file 08.13.50 # 35.84 without that patch 08.13.50 # perfect :) 08.13.56 # so basically no change 08.13.59 # yep. 08.14.46 # but it looks worth having so I say commit 08.14.52 # might help on android 08.14.54 # saratoga: Seen http://www.rockbox.org/wiki/TargetSpecificOptimization#Coldfire ? 08.15.07 Quit KiwiCam (Ping timeout: 252 seconds) 08.15.09 # amiconn, no thanks 08.15.43 # did you see the patch i put up before about USB charge mode? 08.16.47 # Buschel: alignment mostly helps if you do ldm or load doubles to aligned buffers, so if aligning something doesn't help theres probably no multiple loads going on 08.17.01 # that might mean theres a chance to further optimize accessing that buffer 08.18.09 # yes, seems like the access to qmf_window[] is the main optimization 08.20.21 # need to go to work now, see you later 08.20.23 Quit Buschel (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630]) 08.22.06 # Buschel: weird that outSamples didn't make a difference, its accessed 4 words at a time 08.22.15 # maybe it was aligned by chance 08.28.14 # saratoga: The USB power button should always be chosen so that the action its long-press will trigger is not confusing or dangerous 08.28.36 # amiconn: If it's "all buttons" then assuming any button has a safe action, it'll always be available to the user 08.28.46 # Since "safe" can vary from screen to screen, or even based on the opinion of the user. 08.29.07 # I consider context menu generally safer than quickscreen, for example 08.29.10 # But not everyone agrees. 08.29.11 # The commit message for 7674 says why USBPOWER_BTN_IGNORE was added. 08.30.41 # The original ones (MODE for ondios, F1 for recorder fm/v2) are the menu buttons on their respective targets 08.31.00 # * Llorean doesn't see how "all buttons" introduces a new danger. 08.31.17 # Is the theory that users will assume that not a single button on the player will do anything other than allow USB mode when held? 08.31.29 # It does - for the very same reason why USBPOWER_BTN_IGNORE was introduced 08.31.52 # Could you explain that simply? 08.31.55 # That would cause devices with flashed rockbox to *always* enter usb power mode on startup 08.32.36 # So boot and then insert the cable? 08.32.40 # I.e. the button which is used to power up the device *must* be ignored 08.33.01 # What if you can't boot without power from USB? 08.33.02 # Or put in a special condition that the BTN_IGNORE button is ignore until boot "completes" safely 08.33.24 Quit BHSPitMonkey (Remote host closed the connection) 08.33.28 # Completion is too quick for this 08.33.31 # If you can't boot without power from USB, isn't going into USB charging mode acceptable? You could then replug if you'd like UMS much like you have to if you're charging anyway and decide you want UMS access. 08.33.47 # The boot is too fast to give the user time to let go of the button? 08.34.14 # The Ondio can be used from USB power with no batteries inserted. If any button enters USB power mode, you would always end up there, and be unable to enter mass storage mode 08.34.48 # So the boot is too fast for a user to be able to let go of the button before it completes? 08.35.17 Join kish_ [0] (~o2@unaffiliated/spice) 08.35.19 # Yes, because you need to hold it for a short while, until you can be sure that it boots 08.35.34 # Otherwise USBPOWER_BTN_IGNORE wouldn't have been introduced 08.36.04 # Things are introduced that aren't strictly speaking necessary, so I wasn't willing to make that assumption 08.36.45 # Even then, why not just ignore all "power" buttons? Since it's nonsense to hold down the button that shuts down the player to try to insert USB. If you're even a little slow you don't get anything 08.37.27 # Yes, that's what is necessary. 08.37.27 Join Guest34717 [0] (~bjst@giant.haxx.se) 08.37.27 Quit Guest34717 (Changing host) 08.37.27 Join Guest34717 [0] (~bjst@rockbox/developer/Zagor) 08.37.39 Nick Guest34717 is now known as Zagor (~bjst@rockbox/developer/Zagor) 08.37.55 # Or allow a button on the player to disconnect USB (if HID is not enabled) and a menu entry to enter MSC if charging from USB (these might be nice anyway) 08.38.26 # I'd really like a button to drop out of MSC, honestly, for my car where trying to hold down things is impractical, or where the player is waked by USB power and then enters MSC and replugging the cable is potentially unsafe while driving. 08.38.59 Join esperegu [0] (~quassel@145.116.15.244) 08.39.18 # Yes, that might be useful. It also seems that some users would prefern an option what to do on usb insert instead of that button-hold mechanism 08.39.56 # My ideal would be an option to decide if the default is connect or charge, every button (or nearly every button) causing it to perform the other action, and a button that gets me out of MSC if I'm accidentally in it without having to replug. 08.40.32 # I think a menu would slow things down, and you'd still want it to timeout to one or the other (and which it would timeout to being probably user selected) anyway 08.40.34 # Something that resemples "Stop" would be the proper button for this I think 08.40.38 # Probably, yes. 08.41.12 # I'm not talking about a menu at insert (which might be impossible in the current screen) 08.41.58 # Ah, well some people want a menu at insert. Not me, though. 08.42.21 # I want a menu where I can decide what insert will do by default, then if I hold a button it does the opposite of what I've chosen. 08.42.47 # Since I'd much prefer the default on my in-car player to be charge, while the default on my Beast to be MSC 08.44.43 # -> an option 08.44.58 # * amiconn wonders why binsize on the Player increased so much lately 08.45.08 # rasher: Are you still running the binsize graphs? 08.45.22 Quit xxcv (Ping timeout: 245 seconds) 08.46.44 Quit JdGord (Quit: Bye) 08.48.47 Join xavieran [0] (~xavieran@ppp118-209-255-13.lns20.mel6.internode.on.net) 08.48.48 # amiconn: I am. It'll often be days between that computer is turned on though 08.51.34 # Player has hit the 200KB loader limit, causing it to use the self-extractor now 08.54.23 *** Saving seen data "./dancer.seen" 08.57.14 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 09.03.45 Join ender` [0] (krneki@foo.eternallybored.org) 09.04.16 Join DerPapst [0] (~Alexander@p5DE5A242.dip.t-dialin.net) 09.24.39 Join Rob2223 [0] (~Miranda@p4FFF23AF.dip.t-dialin.net) 09.25.45 Join petur [0] (d408b802@rockbox/developer/petur) 09.25.49 Quit S00row (Read error: Connection reset by peer) 09.26.46 Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) 09.28.27 Quit Rob2222 (Ping timeout: 265 seconds) 09.31.07 Join kramer3d [0] (~kramer@residents-ReservedNAT-129-174-190-10.residents.gmu.edu) 09.31.07 Quit kramer3d (Changing host) 09.31.07 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 09.31.08 Quit S00row (Read error: Connection reset by peer) 09.31.44 Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) 09.32.27 Join utanapischti [0] (~username@p4FF2CFEF.dip.t-dialin.net) 09.34.42 Join LinusN [0] (~linus@giant.haxx.se) 09.34.42 Quit LinusN (Changing host) 09.34.42 Join LinusN [0] (~linus@rockbox/developer/LinusN) 09.36.53 Quit sasquatch (Ping timeout: 276 seconds) 09.38.53 Quit liar (Read error: No route to host) 09.39.08 Quit user890104 (Ping timeout: 272 seconds) 09.40.34 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 09.49.18 Join swilde [0] (~wilde@aktaia.intevation.org) 09.52.22 Join user890104 [0] (Venci@Venci-Notebook-LAN.ipv6.6bez10.info) 09.57.59 Quit DerPapst (Quit: Leaving.) 09.59.06 Join JdGord [0] (~jd@122.110.124.5) 10.10.14 Quit xavieran (Ping timeout: 265 seconds) 10.15.32 Quit S00row (Read error: Connection reset by peer) 10.17.08 Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) 10.17.57 Quit factor (Read error: Connection reset by peer) 10.22.07 # saratoga: that code isn't originally mine (although I may have accidentally removed it at some point and then readded it), but the reason for it is that (at least on MTP H10s) you have to hold the right button to get to the ROM USB mode, so in practice you have to hold the right button already before the reboot 10.25.14 # Probably irrelevant now that we don't reboot for USB any more of course 10.30.56 Nick dys`` is now known as dys (~andreas@krlh-5f7226f8.pool.mediaWays.net) 10.30.59 Part LinusN 10.32.22 Join u42p [0] (~u42p@d096239.adsl.hansenet.de) 10.33.18 # (how) can i make rockbox start when i plug my sansa clip+ into usb? currently the original firmware loads. i am using http://www.rockbox.org/tracker/task/11664?show_task= 10.33.31 Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 10.35.20 Join DerPapst [0] (~Alexander@dslb-088-069-135-094.pools.arcor-ip.net) 10.45.32 Join LinusN [0] (~linus@rockbox/developer/LinusN) 10.47.56 Quit GeekShadow (Ping timeout: 255 seconds) 10.48.10 # u42p: you'll need to use a bootloader that knows about the fact that rockbox can handle USB, but I have no idea how to do that on a sansa or if there are precompiled ones available 10.51.06 Join xxcv [0] (~hello@c211-30-174-99.carlnfd1.nsw.optusnet.com.au) 10.52.49 # ah, i was guessing correctly yseterday then. well, gonna wait until that is officially done then 10.52.50 # thanks! 10.54.25 *** Saving seen data "./dancer.seen" 10.58.24 # u42p: such a bootloader will be released as soon as rockbox handles USB itself 10.58.57 Quit kramer3d (Ping timeout: 272 seconds) 11.08.18 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 11.28.17 Join casainho [0] (~chatzilla@pal-213-228-181-14.netvisao.pt) 11.30.55 Quit xxcv () 11.50.58 Join xxcv [0] (~hello@c211-30-174-99.carlnfd1.nsw.optusnet.com.au) 11.52.15 Quit xxcv (Client Quit) 11.56.05 Join Llorean1 [0] (~DarkkOne@adsl-69-153-196-187.dsl.hstntx.swbell.net) 11.57.38 Quit Llorean (Ping timeout: 240 seconds) 11.57.45 Join Llorean [0] (~DarkkOne@adsl-69-153-193-183.dsl.hstntx.swbell.net) 11.57.47 Quit Llorean (Changing host) 11.57.47 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 11.59.41 Join n1s [0] (~n1s@nl118-174-240.student.uu.se) 11.59.41 Quit n1s (Changing host) 11.59.41 Join n1s [0] (~n1s@rockbox/developer/n1s) 12.01.12 Quit Llorean1 (Ping timeout: 276 seconds) 12.05.38 Quit Dreamxtreme (Read error: Connection reset by peer) 12.06.19 Join Keripo [0] (~Keripo@eng028.wireless-resnet.upenn.edu) 12.08.28 Quit Keripo (Client Quit) 12.15.39 # AlexP: did you follow commits to trunk to check for stable-suitability? 12.15.56 # I'm thinking it may be time for a point release 12.17.40 # * TheSeven has a question about "const" 12.19.02 # if i have a register that needs to be set to an address, and the data at that address won't be affected by the address being written to that register, how do i declare that? 12.19.42 # #define DMAC0C0SRCADDR (*((volatile void**)(0x38200100))) will complain that the const qualifier (on the argument passed to the function that writes the address to that register) is discarded 12.20.03 # #define DMAC0C0SRCADDR (*((volatile const void**)(0x38200100))) seems to tell the compiler that the register would be read-only 12.20.16 # is there even a way to do that? 12.24.20 # come on, there must have been similar cases before... 12.24.36 Join Dreamxtreme [0] (~Dre@92.30.31.119) 12.24.39 # or didn't we bother about register types at all and just casted everything to an int when writing to a reg? 12.25.16 # TheSeven: i'm not sure i understand what you mean but i think you want volatile void* const* if i remember the syntax correctly 12.26.21 # ie pointer to a constant pointer to volatile data 12.27.57 # isn't it, in fact, void * volatile const * 12.28.01 # or something similarly insane 12.28.09 # since it's the pointer which is volatile, not the target 12.28.17 # oh 12.28.27 # volatile const is nice :) 12.29.24 # personally i vote for casting it to int 12.29.43 # and having the registers all be the same type 12.31.34 # what i actually want is a pointer to a volatile pointer to constant data 12.32.16 # const void* volatile* foo 12.32.31 # * n1s recommends cdecl 12.33.01 # but basically just write it backwards 12.34.08 # what does *((volatile const void**)whatever) actually do then? 12.34.28 # or even &(*((volatile const void**)(whatever))) 12.34.50 # http://www.cdecl.org/ 12.35.47 # volatile const void** is "pointer to pointer to volatile const void" so you cast whatever to that and dereference the first pointer so you get a "pointer to volatile const" 12.36.03 Quit JdGord (Quit: Bye) 12.36.24 # (*((volatile const void**)(0x38200100))) = &(*((volatile uint32_t*)(0x38300040))); 12.36.26 # funny, eh? :D 12.37.03 # &(*(...)) seems pointless 12.40.54 # but not pointerless :) 12.41.19 # sry for lame joke :p 12.42.52 Quit Gnea (Ping timeout: 245 seconds) 12.42.54 # n1s: it isn't if the * is part of a define, but the & is outside 12.43.07 # this is basically DMAC0C0DESTADDR = &LCDWDATA; 12.44.01 # if "cast x into pointer to volatile pointer to const void" is what i want, that would be "(const void * volatile *)x" 12.45.02 # yes 12.45.20 # now look at http://svn.rockbox.org/viewvc.cgi/trunk/firmware/export/s5l8700.h?view=markup 12.45.41 # doesn't this mean that REG32_PTR_T should actually be "uint32_t volatile*" 12.46.15 # no, because the relative order of a (normal) typename and const/volatile is meaningless 12.46.24 # "volatile int" and "int volatile" are the same type 12.46.43 # ok, but as soon as this is void* instead of uint32_t, it isn't? 12.46.46 # it gets complicated if the typename is actually a typedef for a composite 12.46.50 # Yeah 12.46.57 # this is just one of those things in C 12.47.14 # urgh 12.47.31 # it accepts both, and people tend to write volatile int, but as soon as the type isn't a primitive it may matter which you write 12.49.38 # it would be much more sensible if the language required qualifiers to follow types always, because then the read-right-to-left rule would mostly be sufficient :) 12.49.45 # typedefs can still fuck it up if you try hard enough 12.51.49 Join Jerom [0] (~jerome@79.132.52.183) 12.52.41 # yeah, those "volatile int"s were what made me think they would be generally written left-to-right 12.53.41 # yup, but it's tough because people have been writing volatile int for too long to change their habits ;) 12.53.59 # the cases like this are too rare 12.54.29 *** Saving seen data "./dancer.seen" 12.55.02 # now why does (*((void* volatile*)(0x38200104))) = &(*((uint32_t volatile*)(0x38300040))); say "assignment discards qualifiers from pointer target type"? 12.55.48 # the same happens for void* test = &(*((uint32_t volatile*)(0x38300040))); 12.56.21 # does it think the DMA controller might not know about its volatility? 12.56.29 # because dereferencing it and then taking its address again eliminates the volatile 12.56.34 # i think 12.56.47 # any way to suppress that? (it's intentional) 12.57.00 # more casting :) 12.57.04 # no. in fact, i think that expressoin might even be required to have side effects 12.57.23 # *((uint32_t volatile*)(address)) is supposed to issue a read 12.57.26 # because of the volatile 12.57.30 # i still want writes to *((uint32_t volatile*)(0x38300040)) (which is used as a define in there) to be volatile 12.57.40 # I don't think you can do it 12.58.05 # using an intermediate var to store the adress would work, no? 12.58.16 # only with *another* cast 12.58.47 # is there some way to get to the address inside that define without triggering that warning or issuing a read to it? 12.58.51 Quit user890104 () 12.58.54 # anyway, i think you'll find the type of your RHS there is uint32_t * 12.58.57 # (even if it means some more casts :) ) 12.59.09 # and the type of the LHS is void * volatile 12.59.16 # so it is indeed discarding qualifiers 12.59.39 # what's bad about (void* volatile) = (uint32_t*)? 12.59.50 # hm 13.00.06 # doesn't this just mean that the LHS must be written to immediately? 13.00.16 # the type cast to void shouldn't matter IIUC 13.00.16 # * Torne repeats his earlier suggestion that you cast the address to an int 13.00.19 # :) 13.00.48 # let's say we have #define LCDWDATA (*((uint32_t volatile*)(0x38300040))) 13.01.09 # int whatever = (int)&LCDWDATA; won't help, right? 13.01.21 # why not> 13.01.27 # so there's nothing I can do outside of that define to get at its address? 13.01.47 # IIUC the "&LCDWDATA" part is sufficient to trigger the warning 13.01.58 # not on its own 13.02.06 # it's an assignment warning 13.02.12 # * TheSeven has misunderstood something then :) 13.02.15 # an expression can't generate that without an assignment in it 13.02.39 # so basically DMAC0C0DESTADDR = (void*)((int)LCDWDATA); might work? 13.03.04 # (not without an &) 13.03.07 # (and who knows) 13.03.19 # * Torne suggests just defining the LHS register as volatile int * 13.03.30 # and abandoning any pretence of type safety 13.03.52 # addresses are uint32_t. it doesn't need to actually be a pointer :) 13.04.10 # TheSeven: Why care about register types? So far we didn't 13.04.42 # indeed 13.04.43 # because I personally don't like casting addresses to integers all the time for DMA 13.04.53 # Hmm? 13.04.55 # well, pointers :) 13.05.16 # the code would be full of REG = (uint32_t)thing; 13.05.17 # actual type safety is impossible in C anyway, just give up :) 13.06.04 # Why? The cast is implicit anyway 13.06.22 # REG = thing; triggers a warning 13.07.19 # Look at mcf5249.h, pp5020.h etc - registers are defined as (*(volatile unsigned long*)(0xADDRESS)) (or short resp. char) all over 13.11.04 Join T44 [0] (~Topy44@g227189253.adsl.alicedsl.de) 13.11.29 Quit Topy (Read error: Connection reset by peer) 13.14.12 Join Gnea [0] (~gnea@2610:130:112:400:225:d3ff:fe72:4512) 13.14.19 Quit Gnea (Changing host) 13.14.19 Join Gnea [0] (~gnea@unaffiliated/gnea) 13.15.53 Join xxcv [0] (~null@c211-30-174-99.carlnfd1.nsw.optusnet.com.au) 13.17.00 # amiconn: you can't implicitly cast from void * to uint32_t 13.21.56 Quit Jerom (Quit: Leaving.) 13.22.19 Join dfkt [0] (dfkt@unaffiliated/dfkt) 13.26.48 # Torne: Well you can, but it will throw a warning 13.27.32 # I checked some places which I know use addresses in conjunction with registers. Casts are used where necessary, but there aren't that many places 13.28.21 # It's needed for public variables which need to have the correct type (e.g. lcd_framebuffer); for private variables some drivers just use an int32 even if it holds an address -> no cast necessary 13.34.59 # well, yah, i count "with a warning" as "can't" :) 14.08.02 Quit xxcv () 14.18.30 # hmm, seems like the coldfire tremor slowdown with gcc 4.4 is mainly in the fft stuff, the profiling threw me off at first since gcc 3.4 basically disables inlining when profiling while 4.4 does not 14.20.03 # maybe asming fft4/8/16 will help 14.32.34 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 14.34.53 Nick benedikt93 is now known as benedikt93|AFK (~benedikt9@unaffiliated/benedikt93) 14.38.56 Join kkit|sh [0] (krazykit@silenceisdefeat.com) 14.39.19 Quit krazykit (Quit: awe yeeeeeee) 14.42.11 Join saratoga_ [0] (42391dc9@gateway/web/freenode/ip.66.57.29.201) 14.43.46 # n1s: ive hoped someone would look at fft8 on cf for a while 14.44.09 # it accounts for a large fraction of the entire fft 14.44.23 # and its very short 14.44.35 # saratoga_: yes, i'm taking a look now, starting with fft4 now, gcc4.4 produces significantly worse code for this than 3.4 :/ 14.45.01 # yeah it screwed up on arm too 14.45.11 Quit Zambezi (Remote host closed the connection) 14.45.46 # iirc fft4 becomes a few loads adds and stores in fft8 and gcc has no idea how to do it 14.47.56 # is there any advantage to sequential loads to iram on cf, 14.48.04 # ? 14.48.30 # not much, should be slightly faster 14.49.24 # i want to special case the 2048/512 fft case for targets with lots of iram or only dram 14.49.44 # rearrange the trig values to be sequential 14.50.19 # probably help a lot on arm11, no idea if its useful on cf targets with 128k iram 14.50.42 # would waste probably 8 kb of ram 14.52.25 Join evilnick_B [0] (0c140464@rockbox/staff/evilnick) 14.53.02 # special lookup tables you mean? 14.53.28 Join kevku [0] (~kevku@2001:7d0:0:f000::135d) 14.53.58 Quit Gnea (Ping timeout: 240 seconds) 14.54.31 *** Saving seen data "./dancer.seen" 14.55.35 # hmm, in fact load multiple should save cpu cycles when done from iram too, according to the cpu user manual 14.55.59 # movem takes 1+n cycles while regular loads take 2 cycles 14.56.18 # same as arm7 then 14.57.03 # the current mdct is extremely clever about trig values thanks to stripwx, savesa ton of memory 14.57.18 # but the access patterns are a bit weird 14.57.18 # saratoga: and even if not using movem, sequential loads usually mean autoinc adressing modes can be used which is faster than constant offsetts 15.00.02 # most codecs only use the 2048 block size 95 percent of the time, so we could halve the size of the trig tables, the add a separate table for the common case of the 2048 transform 15.00.20 # then sort it for sequential acess 15.01.50 # that would probably help cf a bit if it could be in iram, but to make full use of sequential accesses we need to write asm... 15.04.18 # well yeah but thats not my problem :) 15.09.03 Join InsDel [0] (~haqr.net@c-98-231-87-43.hsd1.fl.comcast.net) 15.12.48 # maybe we can let the codecs optionally set up the tables (copying the one(s) it wants to use to iram) 15.13.35 # probably better to just make it a compile time option 15.14.11 # there not much use in varying it per codec 15.14.51 # if the codec or file uses a different block size 15.15.08 # (tremor does this with its dewindowing tables already) 15.15.15 # right now theres one table used for all sizes 15.15.37 # its really quite clever 15.16.18 # yes but if we have to chose between having the special case table or the generic table in iram, one compile time choice may not fit all codecs and files 15.16.49 Quit JdGordon (Ping timeout: 245 seconds) 15.18.03 # are there codecs where we couldnt spare 8kb on cf? 15.18.51 # several i think, at least for the targets with 96kB iram 15.18.58 # hmm 15.19.14 # i dislike the idea of having state in the fft 15.19.22 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 15.19.26 # yes, the whole iram thing is a mess 15.19.41 # since it would make it ackward to have a plugin and codec use the fft at once 15.20.16 # they would have their own instance, no? 15.20.27 Join komputes [0] (~komputes@ubuntu/member/komputes) 15.20.30 # codeclib is linked statically to each codec 15.20.45 Quit benedikt93|AFK (Ping timeout: 276 seconds) 15.24.23 Quit saratoga_ (Ping timeout: 265 seconds) 15.40.30 # the fft seems to have been the cause of the slowdown indeed, a brain dead/naive fft4 asm implementation saved 0.3MHz 15.40.58 # let's see it it can be made a little faster 15.54.50 Join kugel [0] (~kugel@141.45.201.221) 15.54.52 Quit kugel (Changing host) 15.54.52 Join kugel [0] (~kugel@rockbox/developer/kugel) 15.59.41 Quit InsDel (Changing host) 15.59.42 Join InsDel [0] (~haqr.net@unaffiliated/insdel) 15.59.50 # amiconn: i'd use intptr_t, IIUC it even enables implicit casts 16.00.59 Quit CaptainKewl (Ping timeout: 252 seconds) 16.01.03 Join timccc [0] (~timccc@112.166.15.141) 16.06.39 Quit kugel (Read error: Connection reset by peer) 16.06.51 Join MethoS- [0] (~clemens@134.102.106.250) 16.08.01 Join Qbe [0] (~43ad9740@giant.haxx.se) 16.08.14 Quit MethoS- (Remote host closed the connection) 16.08.50 Quit Kitr88 () 16.10.08 Quit tchan (Quit: WeeChat 0.3.3-dev) 16.10.41 # Hi all, download.rockbox.org appears to be unreachable this morning--for me, anyway. Is anyone else having this problem? 16.11.39 # Qbe: indeed. use http://haxx.rockbox.org for now. 16.12.20 # Thanks very much. It's time to get something better on my e260. 16.13.51 Join MethoS- [0] (~clemens@134.102.106.250) 16.13.59 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 16.18.10 # haxx.rockbox.org worked like a charm. Thanks again for the help. 16.18.21 # you're welcome 16.18.23 Join Kitar|st [0] (Kitarist@BSN-143-99-156.dial-up.dsl.siol.net) 16.18.34 Quit Qbe (Quit: CGI:IRC 0.5.9 (2006/06/06)) 16.18.48 Quit evilnick_B (Quit: Page closed) 16.19.53 Join ReimuHakurei__ [0] (~reimu@74.112.212.15) 16.19.53 Quit ReimuHakurei_ (Read error: Connection reset by peer) 16.27.09 Join evilnick_B [0] (0c140464@rockbox/staff/evilnick) 16.38.26 Join toffe82 [0] (~chatzilla@maf.wirelesstcp.net) 16.39.26 # i've seen a lot of people complain about building rockbox on cygwin 16.39.46 # is our cygwin environment broken or does it just not work with current rockbox svn? 16.41.20 # last I tried it worked (except --non-eabi on arm targets) 16.42.32 Join JesusFreak316 [0] (~JesusFrea@WirelessTampa1-nat-185.laptops.usf.edu) 16.43.07 Join Zambezi [0] (Zulu@80.67.9.2) 16.47.14 Quit benedikt93 (Quit: Bye ;)) 16.48.05 Quit JesusFreak316 (Ping timeout: 245 seconds) 16.48.46 # i got 2 extra hours with the Fuzev1 and the lowered max clock 16.48.48 # not bad 16.49.52 # saratoga: nice 16.50.07 Join tchan1 [0] (~tchan@c-69-243-144-187.hsd1.il.comcast.net) 16.50.11 # probably would get more with the lowered max voltage too 16.50.45 # asm fft4 closed the gap between gcc 4.4 and 3.4 by 0.5MHz as it makes no speed diff on the old gcc... 16.50.58 # so i'll probably take a stab at fft8 later 16.51.17 Quit tchan1 (Read error: Connection reset by peer) 16.52.07 Join tchan1 [0] (~tchan@c-69-243-144-187.hsd1.il.comcast.net) 16.52.15 Quit tchan (Ping timeout: 250 seconds) 16.54.33 *** Saving seen data "./dancer.seen" 16.54.58 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 16.55.57 Part Zagor 17.00.19 # hmm, this is more complicated than i thought, fft8 loads some of the values fft4 stores again, maybe that can be exploited... 17.03.35 Part LinusN 17.12.03 # Zagor, Bagder: could one of you upload this file to the test_codecs folder on the download server: http://duke.edu/~mgg6/rockbox/atrac3_lp2_132.oma 17.12.27 # by the way if anyone else was thinking of trying to find the sony software needed to create atrac files, i suggest that they not do so 17.12.31 # nothing is worth that 17.19.48 Join Topy [0] (~Topy44@g227208019.adsl.alicedsl.de) 17.20.35 Quit T44 (Ping timeout: 245 seconds) 17.26.37 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 17.27.20 Quit tchan (Read error: Connection reset by peer) 17.28.09 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 17.28.43 Quit tchan1 (Ping timeout: 245 seconds) 17.31.25 Join JesusFreak316 [0] (~JesusFrea@WirelessTampa1-nat-185.laptops.usf.edu) 17.35.20 Quit tchan (Read error: Connection reset by peer) 17.36.10 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 17.38.26 Join Topy44 [0] (~Topy44@g227163143.adsl.alicedsl.de) 17.40.35 Quit Topy (Ping timeout: 245 seconds) 17.41.16 # hm... it would be really cool to have the "compressor" available on recording 17.41.51 # for recording interviews and stuff like that, where the volume is somewhat changing and unpredictable 17.43.13 Quit JesusFreak316 (Remote host closed the connection) 17.43.39 Join JesusFreak316 [0] (~JesusFrea@WirelessTampa1-nat-185.laptops.usf.edu) 17.44.39 Quit petur (Quit: Page closed) 17.45.19 # Doesn't one of the gain options help with that? 17.53.24 # Auto-Gain Control 17.54.14 # it's not available on all recording targets 17.55.03 # I even believe it's *only* there on the H100/300s, not sure though 17.57.19 # pixelma: yes, only iriver h100/300 18.01.45 # saratoga: FWIW, I just successfully built r28640 for all 3 of my targets under cygwin (OndioFM, M5, c200v1) 18.05.57 Nick jfc^3 is now known as jfc^2 (~john@dpc6682208002.direcpc.com) 18.12.14 # gevaerts: yes, I've been trying to keep an eye out 18.12.18 # one mo 18.14.59 Part u42p ("Leaving") 18.21.57 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.21.57 Quit bertrik (Changing host) 18.21.57 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 18.24.44 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 18.37.31 Quit DerPapst (Quit: Leaving.) 18.40.23 Join eWill [0] (~chatzilla@adsl-99-139-147-115.dsl.dytnoh.sbcglobal.net) 18.40.55 # Has any DAP producer ever officially acknowledged Rockbox? 18.41.23 # don't think so, why? 18.41.46 # What does "officially acknowledged" actually mean? 18.42.39 # Just curious. I was going through some Fuze forums, and keep seeping people requesting things on the OF, that RB already does. 18.42.52 # by "Officially acknowledged" 18.43.19 # I mean like symbolic head-nod or something. 18.43.37 # * gevaerts has the same question about that :) 18.43.59 # or suggested to some customer that they should install RB. 18.46.01 # We got some datasheets and a development model of some player I think 18.46.44 # I don't think we got datasheets 18.47.58 # "development model" -- does that mean the company sent RB a free player so you could start working on it? I'd love to know the company -- sounds like someone worth supporting. 18.48.18 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 18.48.34 # eWill: does sending someone $50 worth of gifts really mean *that* much? 18.48.42 # the cost of a player is rarely the roadblock preventing a port 18.50.03 # I guess maybe not, it just sounded like "they want me to have what I want", but after thought, I guess maybe it could be an effort simply to make more money...? 18.50.37 # "Rockbox works on our player! -- buy it!" 18.50.47 # datasheets would be very welcome as they would make porting much easier and much less painful 18.51.24 # eWill: still, I'd readily support a company that embraced rockbox on their product 18.51.26 # But they are under contract not to disclose the datasheets -- right? 18.51.28 # and actually provided useful information 18.51.47 # Not just being difficult -- right? 18.52.32 # the player manuafacturers are, sometimes, but the chip manufacturers are usually able to give out datasheets but they don't want to 18.52.36 # I'm pretty sure we got datasheets from AMS 18.52.48 # yes, ams is an exception 18.53.30 # some datasheets are already freely available like for the hardware in the beast 18.53.49 # If a chip manufacturer published their datasheets, would that make it easier for competitors to steal ideas? 18.54.08 # probably not 18.54.36 *** Saving seen data "./dancer.seen" 18.55.54 Quit JesusFreak316 (Ping timeout: 252 seconds) 18.58.23 # |teletype| 18.58.30 # teletype 18.58.38 # \italic\ 18.59.02 # \/italic 18.59.08 # \/italic/ 19.00.04 # eWill: please stop that 19.00.29 # oops sorry i have two tabs open. thought i was in the other one. 19.01.00 Join Strife89 [0] (a80dbf52@gateway/web/freenode/ip.168.13.191.82) 19.02.03 # bertrik: I had a look at the elftosb2 program 19.02.48 # some strings mention Rijndael CBC MAC 19.03.44 # some it could be some sort of SHA-128 but I tried with zero key on some random program and it does not seem to be plain SHA-128 19.08.48 # too bad, nice try anyway 19.09.24 # I currently trying to see if the executable section has exactly the same size as the binary. I alrzady noted that elftosb2 strips some part of the elf header 19.09.48 Join KiwiCam [0] (~Kiwicam@ip-118-90-20-170.xdsl.xnet.co.nz) 19.09.58 # but it could also add some hashing at regular positions, which would make it even harder to understand to algorithm :) 19.10.38 Join DerPapst [0] (~Alexander@p5DE5AD09.dip.t-dialin.net) 19.10.55 # so you've already actually added something to a .sb with elftosb? 19.11.13 # I tried it with some chumby binaries 19.12.43 # I just built a dummy executable, then add it to the command file using load and indeed, it adds the binary 19.13.09 # when there is no encryption, it just creates a ____ section with the content but with part of elf header stripped. 19.13.11 # Just some ideas: make time() always return the same value with some preload magic, stub /dev/urandom 19.14.40 # I also decided that it was way to difficult to reverse engineer elftosb2, it's written in C++ and even though there lots of strings out there, it would probably be a nightmare 19.14.44 # *too 19.14.45 # And with "zero-key" encryption the binary is still undecryptable? 19.14.50 # yes 19.15.11 # but I still have lots of ideas before giving up 19.15.53 # Unless sandisk used some kind of default key, I think it's nearly impossible to make it accept a custom image. The crypto seems solid. 19.16.55 # * TheSeven guesses that D1671/D1759 might be part of the chip number of the nano3g/nano4g PMU. Any ideas what this thing could be? 19.17.02 # well, sha-128 is quite solid indeed :( But we have to make sure first that they didn't use the default key 19.17.45 # bertrik: sandisk uses firmware signing? 19.17.52 # on what device? 19.18.07 # alexbobP, I think so, not completely sure, on the fuze+ 19.18.48 # Are there any open source voice recognition programs (wondering if a RB voice recognition would be possible). 19.19.11 Join Jerom [0] (~jerome@79.132.52.183) 19.23.43 # eWill: there are, but rockbox voice recognition would probably be way too hard for embedded hardware to handle 19.23.54 # bertrik: ah. well that's ironic then, because the fuze+ isn't *worth* porting to :P 19.23.57 # it's just shit hardware 19.26.49 Join Horscht [0] (~Horschti@p4FD4EA86.dip.t-dialin.net) 19.26.49 Quit Horscht (Changing host) 19.26.49 Join Horscht [0] (~Horschti@xbmc/user/horscht) 19.31.34 # n1s: On coldfire, loading with constant offset, no offset, autoinc and autodec are equally fast 19.31.47 # amiconn: not in my experience 19.31.51 # Only indexed addressing is slower 19.32.15 # n1s: They all take two cycles for 32 bit, 3 cycles for 16 bit and 8 bit 19.32.23 # what i've seen si that constant offsetts are slower 19.32.41 # (i'd guess because they make the instructions longer) 19.32.52 Join panni_ [0] (hannes@ip-178-203-101-205.unitymediagroup.de) 19.33.15 # same with using 32 bit immediate values 19.33.28 # Here we're talking 16 bit offsets though 19.34.03 # Iirc the pipeline is able to fetch 32 bits per cycle, so even back-to-back loads with 16 bit offsets shouldn't starve the pipeline 19.34.39 # You may see aliasing effects caused by the icache though. These are tricky 19.34.54 # right, not sure if i've tested with move.l but emac paralell loading was measurably faster with sequential access and postinc rather that offsetts when i made a test for Buschel on mpc 19.35.14 # those becone 48 bit instrs when using offsetts thogh 19.35.20 # Well, emac parallel load is of course faster 19.35.30 # How many revisions back are on svn? 19.35.49 # i mean that emac parallell load with postinc is faster than emac paralell load with offsett 19.35.55 # And instructions using two extension words will starve if issued back-to-back 19.35.59 # eWill: back to r1 19.36.21 # amiconn: ok, so that is maybe only true for emac paralell loads then 19.36.47 # It only is if you're also issuing them back-to-back 19.37.24 # (difference in that mpc filter loop was 0.9MHz with the dct reordered so that the paralell loads were sequential) 19.37.29 # Actually even then it shouldn't, because emac with parallel load needs two cycles anyway 19.37.43 # wow cool. I've got to do the "find a good revision -- then go half way between that an the bad one -- then go half way between that and the bad one...." thing. What did you call that again? 19.38.04 # eWill: bisection 19.38.22 # That may be simple aliasing. Reordering functions will change speed, often by several percent, in an unpredictable way. Slower or faster... 19.39.00 # (unless the code involved is in iram, of course) 19.40.09 # i know, but that loop is in iram (as it's by far the hottest in the codec AFAIU) 19.41.57 # Make sure it actually is... when specifying both 'inline' and ICODE_ATTR, and the parent function is not in iram, the result may be different from what's intended 19.42.23 # It should be obvious, but nevertheless I've seen cases of that in rockbox 19.43.02 # the one in musepack is a real asm function so it will never be inlined 19.43.25 # New commit by 03Buschel (r28641): Fix typo in comment. 19.43.32 # btw i wonder why gcc doesn't warn if a function is inlined so it ends up in another section when you explicitley specify one 19.43.49 Join Buschel [0] (~chatzilla@p54A3A5DC.dip.t-dialin.net) 19.44.14 # Because it's gcc? 19.45.08 # true that 19.45.27 # r28641 build result: All green 19.45.47 # spotted another bug in it yesterday that causes our workaround that makes profiling work with gcc3.4 to break in 4.4 :) 19.46.12 # although the workaround isn't needed in 4.4 so no big problem 19.47.08 Join krabador [0] (~krabador@host84-29-dynamic.251-95-r.retail.telecomitalia.it) 19.48.41 Quit GeekShadow (Read error: Connection reset by peer) 19.49.04 Join GeekShad0w [0] (~Antoine@ree79-1-78-237-225-34.fbx.proxad.net) 19.49.16 Join piggz [0] (~piggz@78.144.114.53) 19.49.50 # reagrding yesterdays discussion on sleep/shutdown and startup times...the quoted 3 seconds isnt right...more like 27-30 seconds! :) 19.49.50 Join JesusFreak316 [0] (~JesusFrea@pool-173-65-109-252.tampfl.fios.verizon.net) 19.51.25 # piggz: that sounds long 19.51.34 # piggz: what target, which version of rockbox, what settings and did you actually time it? 19.54.11 # ipodvideo 5g 19.54.14 # 64mb 19.54.34 # im not aware of any special settings i have 19.55.20 Quit MethoS- (Remote host closed the connection) 19.56.53 Quit Strife89 (Quit: Let's see what happens when I run from the hard drive.) 19.58.10 # 80GB? 19.58.45 # I know I once measured 7 seconds from pressing the power button to having playing audio on my gigabeat F 19.59.06 # flash targets are a lot faster still 19.59.27 # yes 19.59.56 # IIRC there are some unexplained slowdowns with that disk 20.01.17 # probably why apple invented sleep mode ;) 20.02.46 # do you have things like dircache enabled or "load to RAM" or "auto-update" with the database? 20.03.13 Join Strife89 [0] (a80dbf52@gateway/web/freenode/ip.168.13.191.82) 20.05.11 # pixelma: maybe, what should i disable 20.06.37 # Try enabling dircache 20.07.25 # i will when i find it :) 20.07.47 # depends on your way of using it. I just remember reports about slowdown when all three is enabled (not sure if this is still the case). Some of these could also help decreasing boot time when enabled (as gevaerts mentioned) 20.08.04 # pixelma: that one *should* be fixed 20.08.14 # piggz: we have a manual which probably helps you finding these options... ;) 20.08.17 # it already is enabled 20.08.27 # piggz: is it a recent version of rockbox? 20.08.45 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 20.09.39 # manuals are for wimps :) 20.09.42 # 3.7 20.10.17 # Is anyone here with a Fuze v1/v2 and Rockbox 3.7 that's not seeing this?: http://www.rockbox.org/tracker/task/11655 20.11.55 # phanboy4: fuzev1 here, i can insert several albums with no problem, more recent build than 3.7 tho 20.12.21 # Hrm. 20.12.26 # I'll try todays build 20.12.32 Join freddyb [0] (~chatzilla@rrcs-24-123-234-112.central.biz.rr.com) 20.13.06 # Does we have a datasheet for the FuzeV2? 20.15.43 # hi RB devs, are some of you planned to improve Fuzev1 battery duration? 20.16.36 # n1s, Aha, seems to have fixed it, works now 20.17.20 # krabador, yes I think there are some ideas for that 20.18.06 Quit casainho (Remote host closed the connection) 20.22.27 # piggz: no, manuals are for us to point people to it so we don't have to answer the same questions again and again... 20.22.56 # bertrik, great, i've fear that developers are thinking to discontinue fuzev1 rockbox development 20.23.54 # krabador: so what you're saying is that someone should decide to get a great idea on how to improve fuzev1 battery life tomorrow at 17:45 or something like that? 20.24.38 # phanboy4: any chance of finding out which commit fixed it? 20.24.56 # If it's broken in 3.7, we might want to fix that in 3.7.1 20.26.50 # gevaerts, certainly not :) i'm only asking if fuzev1 developer are continuing 20.27.25 # krabador: well, you keep asking this every few days, so I thought you had something specific in mind 20.29.30 Join aevin [0] (eivindsy@unaffiliated/aevin) 20.30.04 Quit freddyb (Ping timeout: 264 seconds) 20.30.10 Quit KiwiCam (Ping timeout: 245 seconds) 20.31.07 Join stoffel [0] (~quassel@91.137.68.177) 20.31.38 # gevaerts, rockbox totally captured my interest in portable music, and by the day i rockboxed my fuzev1 , i'm only really interested with deveopment on it. I really would contribute, but i'm not a developer 20.32.15 # So what you're asking is that people drop everything and concentrate on the fuzev1 at the expense of all other targets? 20.32.38 # gevaerts, certainly not 20.32.58 # rather 20.33.38 # many new ports and ideas i look, are really great 20.33.55 Join Kupop [0] (~Kupo@cpc2-bsfd7-2-0-cust220.5-3.cable.virginmedia.com) 20.34.24 # gevaerts, I'll look 20.35.00 Quit Strife89 (Quit: Heading home.) 20.36.31 # is the Fuze V1 RB batt life really that much different than the OF batt life? 20.37.15 # eWill, yes, RB battery life are almost the half of OF 20.42.15 Quit chattr (Ping timeout: 245 seconds) 20.44.16 # freddyb: no datasheet, but its pretty similar to the as3525 20.44.25 # with some stuff from the as3543 20.46.06 Join chattr [0] (~mike@244.87.189.72.cfl.res.rr.com) 20.49.39 Join Nerdy3_14159265 [0] (~chatzilla@m20677151209.austincc.edu) 20.50.37 # Hey guys, I'm having trouble with Rockbox on my Sansa Fuze v2 20.51.44 # you need to be a bit more descriptive ;) 20.53.04 # I have to do some bisecting. Can I just make a copy of my RB development dir, and do it all in there? I'm trying, but "svn status" result is ---- svn: warning: '.' is not a working copy 20.53.16 # I was just waiting to see someone respond to continue 20.53.56 # I was outside one day so I cranked the brightness on the Fuze, ever since when it starts it shows the rockbox logo then goes to a black screen and won't display anything 20.54.02 # 13:25:02 < gevaerts> krabador: so what you're saying is that someone should decide to get a great idea on how to improve fuzev1 battery life tomorrow at 17:45 or something like that? 20.54.06 # gevaerts: you know what? I like that idea 20.54.09 # gevaerts: someone should go ahead and do that 20.54.19 # alexbobP: don't let me stop you 20.54.39 *** Saving seen data "./dancer.seen" 20.54.52 # gevaerts: meh, my fix is to carry a laptop and charge my mp3 player with it 20.55.06 # charging the player's whole battery is a drop in the bucket to a sleeping laptop 20.55.06 # Nerdy3_14159265: is it possible you set the brightness to the lowest setting (wrapped around the list)? 20.55.31 # Nerdy3_14159265: you could try resetting your settings or have a look at it from the PC 20.55.54 # gevaerts: also, on Thursday someone should go ahead and make rockbox give the clip+ a color screen, because I miss the days when sandisk made color mp3 players 20.56.31 # krabador: you should become a developer! 20.56.46 # pixelma: It shouldn't be that it looped around because I played on it for a bit before the screen started just going to black, also I have no idea how to reset the settings without being able to see the screen and I have no cord atm to hook it to my pc 20.59.06 # some players let you reset settings during boot by holding a specific button. I'm not sure if this is implemented on the Fuze and which button it would be if it is, you could search around in our manual 21.00.36 Quit Jerom (Quit: Leaving.) 21.01.50 # pixelma: I'm pretty sure that it's the brightness at max, I think I managed to navigate to brightness but changing it didn't affecct anything, I was using the rockboxed fuze simulator 21.02.00 # pixelma: as a reference 21.02.01 Join freddyb [0] (~chatzilla@216.8.239.112.etczone.com) 21.02.25 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 21.02.31 # that's the only idea I could contribute as I don't have a Fuze I don't know what else could be going on. If you stick around for a bit maybe someone else could help you 21.02.42 Quit freddyb (Remote host closed the connection) 21.02.49 # pixelma: BTW where would that reset button be listed in the manual 21.03.20 Quit jae (Ping timeout: 276 seconds) 21.05.56 Join freddyb [0] (~chatzilla@216.8.239.112.etczone.com) 21.06.54 # hmm, I need to look it up myself 21.13.06 # it's not in the Fuze (v2) manual where it would be (in "Advanced Settings > Managing Settings", a not under the description of the "Reset Settings" menu item). So it's either not implemented yet or an oversight in the manual source 21.15.17 Quit krabador (Read error: Connection reset by peer) 21.15.34 # I meant a note 21.17.16 # Saratoga, thanks. 21.28.38 Join edboyer93 [0] (eboyer93@pool-71-185-65-59.phlapa.fios.verizon.net) 21.29.05 # pixelma: Well I think this max brightness must be a glitch then freaking out the display. I'll have to attempt resetting when I get home 21.32.04 Quit Nerdy3_14159265 (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630]) 21.43.31 # I think I've read of other people having problems with the fuze v2 on max brightness 21.50.40 # * pixelma is reminded of the c200v1's contrast settings :\\ 21.53.14 # Is there a longer commit list than http://www.rockbox.org/since-4weeks.html ? 21.53.55 # pixelma, what's wrong with it? 21.54.19 # I only know the bug that the screen goes off under some circumstances when changing the brightness 21.54.38 Join krabador [0] (~krabador@host84-29-dynamic.251-95-r.retail.telecomitalia.it) 21.54.58 # Nerdy3_14159265: did this happen in rockbox or the OF? 21.55.59 # bertrik: it goes from 0 (total black) to 255 (total white) but on mine at least it should actually only be 0 to 127 (127 is total white too and 128 is total black again), It is as if the range is there twice but I remember someone looking into some datasheet and saying 256 steps would be correct... 21.56.02 # eWill, you could check out the source and use svn... 21.56.30 # pixelma, I just tried that and it behaves the same for me (looks like a wrap at 128) 21.56.39 # yeah 21.57.10 # I'll try to check the datasheet again 21.57.11 # bertrik: That's what I'm doing, but in between builds, I could be manually searching the list (now that I'm under 100 possible commits) 21.57.15 # eWill: he left 21.57.42 # but I think (hope) he was talking about Rockbox 21.57.46 # pixelma: I just ordered a Fuze v2. Do you know if he screwed it up in RB mode or in the OF? 21.58.00 # pixelma, have you ever heard of people where 0-255 worked as described in the datasheet? 21.58.47 # not that I remember but I doubt anyone using settings coming close or changing it so much (despite testing as I do) 21.59.11 Join mirak [0] (~mirak@81-64-223-104.rev.numericable.fr) 22.01.48 Quit krabador (Quit: Sto andando via) 22.03.09 # hm, the datasheet has some confusing statements about the contrast setting 22.03.33 # * TheSeven wonders at which point he should start to port rockbox to the ipod classic 22.04.50 # TheSeven: can you access the storage and display? 22.05.00 # display: yes, storage: no 22.05.03 # usb: yes 22.05.10 # NOR flash: yes 22.05.19 # clickwheel: no 22.05.31 # i imagine rockbox will be painfull untill it can read the storage 22.05.44 # ramdisk :P 22.05.59 # ;) 22.06.06 # and rockbox boots fine without a storage driver 22.06.25 # oh, didn't think it would 22.06.37 # it will fall back to the compiled-in versions of everything 22.06.44 # just make each storage call return -1 22.07.20 # Probably a really stupid question, but can the simulator simulate the OF on any targets? 22.07.41 Quit freddyb (Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100723085406]) 22.07.51 # pixelma, 255 (or even 127) seems like a slightly ridiculous number of steps anyway 22.07.54 # eWill: it's not an emulator 22.08.24 # TheSeven: then i don't see why not start at porting rockbox straight away 22.08.43 # bertrik: I agree but maybe fine-grained adjustment doesn't hurt on this display ;) 22.08.46 # it's mainly a question of when it becomes useful 22.09.18 Join jae [0] (~jae@jaerhard.com) 22.09.21 # i'd say whaen you have at least storage and display 22.10.19 Quit GeekShad0w (Ping timeout: 272 seconds) 22.14.49 # bertrik: the most annoying fact of this is the wrap from "black" to "white" in the middle of this to me 22.15.08 Quit mystica555_ (Ping timeout: 245 seconds) 22.15.29 Quit Llorean (Quit: Leaving.) 22.16.26 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 22.18.33 # pixelma, I'm trying to figure out if the full range is perhaps possible by configuring some other part of the display. There is a note in the ds that says that under some circumstances the range is less. If that's not possible, I'm inclined to just reduce the range to 0-127 to avoid the wrap at 128 22.23.14 # ranmachan, do you see the same effect w.r.t. contrast on the c200v2? 22.24.14 # I'd be fine with 128 22.24.43 Quit jae (Ping timeout: 245 seconds) 22.24.51 Quit piggz (Remote host closed the connection) 22.25.34 Quit mirak (Quit: Ex-Chat) 22.30.08 # OK I've found the commit that broke a function for me (perhaps it's a "fix"?). The way it used to work on my e200v1: Location: WPS > Context Menu > Playlist Menu > Playlist > View Current Playlist. Function: Press Play/Pause button ("up" button) returned you to WPS. Since r28139 or r28140 (same author/file) this button now does nothing. Anyone care to take a look? http://svn.rockbo 22.30.10 # x.org/viewvc.cgi?view=rev&revision=28139 22.30.15 Join mirak [0] (~mirak@81-64-223-104.rev.numericable.fr) 22.30.18 # http://svn.rockbox.org/viewvc.cgi?view=rev&revision=28139 22.32.33 Join jae [0] (~jae@jaerhard.com) 22.32.47 # eWill: the logs don't say anything about an intended change in behaviour there 22.32.57 # Maybe submit a bug report? 22.33.36 Join MethoS- [0] (~clemens@134.102.106.250) 22.34.14 # r28138 works, r28139 won't compile, r28140 broke me. Ok, bug report. My first one. 22.35.08 Quit liar (Quit: Leaving) 22.36.08 Join bmbl [0] (~bmbl@dsl-217-167-45.pool.bitel.net) 22.36.08 Quit bmbl (Changing host) 22.36.08 Join bmbl [0] (~bmbl@unaffiliated/bmbl) 22.36.46 Quit chattr (Ping timeout: 240 seconds) 22.37.45 # saratoga: you there? 22.38.00 # Buschel: yeah 22.38.20 # bertrik: Yeah, it wraps around, 0-127 alone is enough... 22.38.58 # just came by the fact that r28549 broke atrac3 playback of a testfile 22.39.03 # in sim 22.39.26 # GoodbyeCaroline.rm 22.39.33 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 22.40.06 # Buschel: do you have a link to that file? 22.40.10 # I am also wondering how atrac3_iqmf_dewindowing() is defined for ARM 22.40.15 # ranmachan, ok thanks for confirming 22.40.22 Join chattr [0] (~mike@244.87.189.72.cfl.res.rr.com) 22.40.33 Join GeekShadow [0] (~Antoine@ree79-1-78-237-225-34.fbx.proxad.net) 22.40.33 Quit GeekShadow (Changing host) 22.40.33 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 22.41.42 Quit esperegu (Read error: Connection reset by peer) 22.41.51 # saratoga: http://samples.mplayerhq.hu/real/AC-atrc/ 22.43.41 # saratoga: atrac3_iqmf_dewindowing_armv5e() is declared, but not used for AMR_ARCH>=5 22.44.16 Quit edboyer93 () 22.44.26 # Buschel: ? 22.44.38 # line 137: atrac3_iqmf_dewindowing_armv5e(out, in, win, nIn); 22.44.59 # love sound of atrac in the morning 22.45.05 # the sound 22.45.13 # saratoga: atrac3_iqmf_dewindowing() uses int16_t *win for ARM_ARCH<4. shouldn't this still be using int32_t? 22.45.16 # did you port atrac1 yet ? 22.45.24 # Buschel: is that an atrac3 file? 22.45.37 # the bitrate is very high, i thought atrac3 only support 132k and lower 22.45.44 # no atrac1 yet 22.46.10 # not much interest since theres almost no PC accessible atrac1 files 22.46.10 # saratoga: check with ffmpeg -i to be sure 22.46.17 Quit factor (Read error: Connection reset by peer) 22.46.25 # saratoga: but there is 22.46.34 Join anewuser [0] (anewuser@unaffiliated/anewuser) 22.46.36 # you have to rip them from a player right? 22.47.39 # saratoga: damn, forgt to sync to r28550. forget about the iqmf functions 22.47.50 # :) 22.47.58 # my bad for committing the commented out version 22.48.04 # was benchmarking and forgot to fix it 22.48.17 # well, it was faster on ARMv5e and aboce :) 22.48.25 # *above 22.48.30 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 22.50.04 Join Xerion_ [0] (~xerion@54194281.cm-5-2b.dynamic.ziggo.nl) 22.50.25 # saratoga: yes, but that is no excuse for not supporting it 22.50.33 # well you're welcome to port it :) 22.50.38 # i'll optimize it 22.50.47 # that Goodbye track plays for a second for me, then crashes 22.50.53 # or gives codec failure 22.51.06 # the bitrate is 176k which isn't valid for atrac3 afaik 22.51.09 # so i don't know what it is 22.51.09 # saratoga: that's somehow appropriate in a twisted way :) 22.51.17 # so it's not enough for me to have written a ffmpeg decoder for it ? 22.51.18 # ha 22.51.27 # I should write a rockbox version also 22.51.40 # write an atrac3plus decoder and i'll port that 22.51.51 # saratoga: yes. it plays before r28549 22.51.56 # weird 22.53.22 # "The freely downloadable RealSystem Producer Basic (available for Linux, Mac and PC) can encode ATRAC3 audio at 352, 264, 176, 132, 105, 96, 64, 44, 32 and 20kbps. " 22.53.43 # i guess thats where this 176k file came from 22.54.01 Quit Xerion (Ping timeout: 272 seconds) 22.54.01 Nick Xerion_ is now known as Xerion (~xerion@54194281.cm-5-2b.dynamic.ziggo.nl) 22.54.40 *** Saving seen data "./dancer.seen" 22.55.23 # Buschel: it breaks on armv4 for me and I didn't change anything for that 22.55.26 # saratoga: interesting. if I revert atrac3.h only, it works again. seems to be connected to the memory layout. some boundary stuff? 22.55.30 # are you sure it was my commit that broke it? 22.55.36 # hmm 22.56.02 # moving back outSamples[] to its former position within ATRAC3Context 22.57.09 # Buschel: sounds like a buffler overflow 22.57.12 # buffer 22.57.23 # merbanan: are you working on rockbox? 22.57.36 # no 22.57.49 # i wonder if this real encoder uses some combination the other encoders do not 22.58.11 # saratoga: hahaha, you know we have an atrac3+ decoder in the works 22.58.38 # merbanan: awesome 22.58.42 # i've been curious how that thing works 22.59.02 # the atrac decoders have been ... interesting to look at 22.59.21 # have you figured out the filterbank for it? 23.01.05 # http://wiki.multimedia.cx/index.php?title=ATRAC3plus 23.01.11 # short version 23.01.12 # Buschel: making that buffer bigger fixes the crash 23.01.14 # it's a bitch 23.01.23 # so its an overflow bug . . . 23.01.32 Quit komputes (Remote host closed the connection) 23.01.35 # oh wow, didn't notice that had been updated 23.01.40 # need to watch ffmpeg more closely 23.02.14 # saratoga: just did the same :o) yes, it fixes the bug 23.02.22 # saratoga: yes the real encoder uses higher bitrates then the sony one 23.02.26 # going to try it with just 32 extra bytes 23.02.42 # saratoga: I just doubled it 23.03.04 # saratoga: rockbox port is going to be alot of work 23.03.33 # ha 23.03.42 # but we've got an efficient iQMF now!!! 23.03.54 # "The sample-frame size is 2048 samples per channe" 23.04.08 # oh i had heard it used 4096, was interested to see how that would work 23.04.09 Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 23.04.27 # "gain control for reducing pre-echo artifacts" 23.04.35 # haha anything sony can do to avoid having different mdct block sizes 23.05.00 # the mpeg people must have patented that in conjunction with iqmf or something 23.08.55 # Buschel: just adding 32 bytes "fixes" the crash 23.08.59 Quit Buschel (Ping timeout: 255 seconds) 23.10.14 # Buschel: adding 4 bytes fixes the crash 23.10.19 # so its an off by one error somewhere 23.10.32 # Anyone remember the bug I told you guys about 20 minutes ago? (Play/Pause button doesn't return to WPS from Playlist) Would the Flyspray catagory for that be "User Interface"? 23.10.46 Join Buschel [0] (~chatzilla@p54A39F59.dip.t-dialin.net) 23.10.54 # bah, ubuntu nautilus crashes when unmounting the c200 23.10.55 # eWill: that would work I think 23.11.09 # saratoga: iQMF isn't used any more 23.11.23 # IIRC, they use something else 23.11.23 # eWill: pretty sure there is already a bug and a patch for that 23.11.50 # * eWill is looking again 23.11.52 # "Finally the QMF synthesis filter will be applied in order to sum all subbands together and reconstruct the encoded audio signal" 23.11.58 # sounds like atrac3? 23.12.20 # i hope its iQMF, i just spent an afternoon writing an optimal one in armv5 assembly 23.12.57 Quit n1s (Quit: Lämnar) 23.13.49 # merbanan: do you know if anyone has looked at wma lossless? i'd like to complete our wma support some day 23.16.55 # saratoga: +1 byte fixes the crash, but the audio is broken (as if the bitstream is broken) 23.17.04 # saratoga: same for +4 byte 23.17.20 # oh 4 bytes sounded ok to me 23.18.16 # pixelma, is there a flyspray entry for the c200 contrast issue? 23.18.38 # not that I know of 23.19.08 # ffmpeg plays it fine, so its something we broke 23.19.41 # I looked a bit more into it, but can't make it work for 0-255. 23.20.17 # although i suppose they could just get lucky like we did 23.20.26 # but i'm so lazy and don't want to figure out how to compile ffmpeg 23.23.25 # array size +4 => +16 bytes seems fine 23.23.47 Quit Llorean (Ping timeout: 272 seconds) 23.23.52 Join Llorean [0] (~DarkkOne@ppp-70-250-173-17.dsl.hstntx.swbell.net) 23.23.58 Quit Llorean (Changing host) 23.23.58 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 23.24.18 # bertrik: I changed my mind, elftosb2 does something strange with elf files. It modifies them, or reorder the sections, I don't really know what but it does something ! 23.24.56 Quit mirak (Quit: Ex-Chat) 23.27.01 # perhaps it goes from elf to plain binary or put instructions about how to write things in memory 23.28.57 # JdGordon: You said you think there is already a patch for the Play/Pause button not returning to WPS from "View Current Playlist". I can't find it. Were you here ~45 minutes ago when I was talking about the revision that broke me? (r28139 or 28140) Those were committed on Sept. 22, so the bug/patch you were thinking of -- is it that young? 23.29.56 # * eWill also searched bugs 23.30.41 # Buschel: ffmpeg sounds ok to me even with the moved around buffers, so we probably screwed up something 23.33.00 # hmm, will now check where it is screwed 23.39.36 Quit bmbl (Quit: Verlassend) 23.46.18 # urgh! they only allow NOR bootloader images that are either encrypted with a device-dependent key, or digitally signed 23.46.39 Quit evilnick_B (Quit: Page closed) 23.48.02 Quit stoffel (Remote host closed the connection) 23.49.18 # saratoga: it seems like decodeChannelSoundUnit() is sometimes writing beyond outSamples[] in the case of normal stereo mode or mono 23.49.37 Quit kevku (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/) 23.49.55 # * TheSeven just spun up the HDD of his ipod classic :) 23.50.14 # Buschel: do you have those benchmarks of libmad that you pastebin'ed the other day? 23.50.45 # saratoga: the profiling? 23.51.10 # yeah 23.51.17 # i can't remember how fast the dct32 was 23.51.33 # http://pastie.org/1318675 23.51.42 # S5L870x 23.51.53 Quit Kupop (Ping timeout: 255 seconds) 23.54.20 Quit bertrik (Ping timeout: 250 seconds) 23.57.01 # changing the MUL macro in the dct32 to use SMMUL instead of SMULL and a shift would speed up the dct32 a good bit on arm11 23.57.37 # saratoga: overwrite happens somewhere in gainCompensateAndOverlap()