--- Log for 07.01.111 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 7 days and 19 hours ago 00.04.17 Quit GeekShadow (Ping timeout: 240 seconds) 00.05.16 # * TheSeven wonders why nobody seems to ever call audiohw_set_master_vol 00.08.14 # * TheSeven glares at firmware/sound.c line 252 and falls off his chair 00.09.45 # kugel: care to elaborate? 00.09.55 # n1s: download fails 00.10.14 # what are you building? 00.10.15 # I executed it and selected "s m e i", and the download fails 00.10.39 # which download? 00.11.32 # hmm, yes atypo seems to have crept in 00.12.07 # or something 00.13.26 Quit benedikt93|AFK (Quit: Bye ;)) 00.13.41 Quit Judas_PhD (Quit: This is a quitting message) 00.15.03 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 00.15.09 Join Rob2222 [0] (~Miranda@p4FFF361A.dip.t-dialin.net) 00.15.51 # oh, the geolocated mirror's seem to have different dir layout 00.19.24 Join JdGordon1 [0] (~jonno@vl10.gw.ok-labs.com) 00.20.45 # kugel: if you set GNU_MIRROR=ftp://gcc.gnu.org/pub/ when running the script it works 00.21.02 # i wonder why they can't use the same dir structure :( 00.21.26 Quit Judas_PhD (Quit: This is a quitting message) 00.21.33 # the nice thing with the mirrors on the gcc site is that they have all the things we need 00.24.23 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 00.24.23 Quit lc0806607 (Read error: Connection reset by peer) 00.25.38 # so we either hardcode one of the gcc mirrors, or hardcode the url only for mpc 00.26.02 Quit Judas_PhD (Client Quit) 00.26.05 *** Saving seen data "./dancer.seen" 00.26.17 # since there appears to be no nice generic geolocation aware url for gcc mirrors and the regular gnu mirrors don't have mpc 00.26.48 # New commit by 03theseven (r28980): Fix volume control on iPod Classic 00.28.10 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 00.29.27 # r28980 build result: All green 00.31.10 # * TheSeven wonders how to figure out why playback needs so much processing power 00.32.59 # how much does it need? 00.33.19 # it doesn't even play back WAV files (containing cd-quality PCM) without stuttering 00.33.33 # FLAC, however, works nicely (but seems to need almost 200MHz) 00.33.52 # WAV is faster then flac so its probably not the codec itself 00.33.57 # disk driver maybe? 00.34.19 # that fun goes on after it completes buffering, so it can't be the disk driver 00.34.33 # MP3 stutters as well 00.34.36 # how big is your audio buffer? 00.34.42 # ~500KB 00.34.48 # compressed audio? 00.35.01 # and do you have cache enabled? 00.35.11 Quit Rob2222 (Quit: Rob2222) 00.35.21 # the PCM buffer is ~500KB, the compressed audio buffer ~60MB 00.35.27 # and yes, the caches are enabled 00.35.35 # the test_codec results look sane 00.35.43 # how fast for MP3? 00.35.48 # (WAV needing 2.5MHz, FLAC like 20MHz, MP3 like 45MHz) 00.36.03 # this is on arm9E? 00.36.14 # yes, running at 216 MHz as far as i can tell 00.36.25 # thats quite slow compared to AMS 00.36.34 # (some quick measurements showed ~190MHz, so that should be right) 00.36.49 # memory bandwidth is >100MB/s, so that's not an issue either 00.36.58 # * TheSeven thinks the only thing left is the PCM buffer 00.37.22 # PCM driver* 00.37.30 # test_codec doesn't yeild IIRC 00.37.36 # playback does 00.37.59 # maybe some issue with scheduling? 00.38.35 # buffering seems to be over-yielding (in the ATA driver), but apart from that I can't see what might be going on 00.38.41 # if you open up mpa.c or some similar codec and make it yield less often does the stuttering get better? 00.38.49 # isn't it basically only the codec thread that's eating CPU power once buffering has finished? 00.39.06 # assuming the screen is off i think so 00.39.16 Quit mystica555 (Ping timeout: 240 seconds) 00.39.35 # although i guess its possible you could have something busy waiting in a driver or something by mistake 00.39.35 # WPS or sitting in the main menu (cabbiev2) doesn't make a difference 00.39.42 # is there any reason why volume control on the fuze seems to take a while to initiate? The new volume that the person sets doesn't seem to take effect till a couple seconds after you change it 00.39.49 # the UI is almost unresponsive 00.39.56 # (except for FLAC) 00.40.08 # yeah that'll happen if the PCM buffer gets low 00.40.20 # it'll starve the GUI first 00.40.22 Quit Strife89 (Read error: Connection reset by peer) 00.41.11 Join Strife89 [0] (~Strife89@adsl-80-148-184.mcn.bellsouth.net) 00.41.59 # test codec fakes most of the playback and buffering APIs, so its not unreasonable that it could be different, but i'm not sure how this could be a hardware specific issue 00.42.50 # for FLAC, the PCM buffer is always around half full full 00.42.57 # if you disable the audio driver (just have it discard samples) does that improve things? 00.43.14 # and buffering and the codec seem to be fighting badly while buffering is still active 00.43.24 # buffering almost can't keep up with playback 00.43.24 # i wonder if you're just getting spammed with interrupt requests 00.43.54 # but why does FLAC work if WAV doesn't? 00.44.05 # are the PCM chunks insanely small for WAV? 00.44.28 # i can't remember how libpcm does it 00.44.33 # but they may be smaller 00.44.41 # a lot of codecs force larger PCM chunks then we'd like 00.44.44 # the PCM driver can handle up to ~9000 samples (which is the highest number i've seen so far in a single chunk) with a single IRQ 00.44.45 # since we want to yield often 00.45.29 # most codecs generate about 2048 samples at a time 00.45.36 # * TheSeven means 9000 samples per channel, so 18000 samples or 36KB total 00.45.42 # which codec? 00.46.04 # i think that was MP3 (which was the first one i was testing with) 00.46.27 # ok then thats the DSP engine combining multiple frames 00.49.50 Join Rob2222 [0] (~Miranda@p4FFF361A.dip.t-dialin.net) 00.51.03 # must be some weird bug in my pcm driver... 00.51.19 # New commit by 03nls (r28981): rockboxdev.sh: Hardcode gcc mirror for now as the gnu mirrors have a different dir layout and are missing the infrastructure dir which was the whole ... 00.53.53 # r28981 build result: All green 00.55.16 Quit factor (Ping timeout: 240 seconds) 00.55.41 # n1s: at what point should we start transitioning build clients? 00.56.18 Join notdavid [0] (~david@pool-71-100-202-46.tampfl.dsl-w.verizon.net) 00.56.39 Join factor [0] (~factor@75.108.68.114) 00.56.46 # gevaerts: i don't know how the build clients stuff work really so how would we do that? 00.56.53 Quit chattr (Quit: gone) 00.57.11 # It's a bit annoying that the tools have exactly the same name 00.57.26 Quit TheLemonMan (Quit: free(me)) 00.57.28 Quit panni_ (Ping timeout: 246 seconds) 00.58.11 # gevaerts: does the build master have a way to determine if the client uses the correct version of something? 00.58.50 # No 00.58.52 # we just need a toolchain test which is a little more sophisticated than which 00.59.01 # It just checks if it finds the compilers 01.00.07 # TheSeven: my wav files generate about 100 samples at a time, which is significantly less then most other formats I suspect 01.00.21 # I don't think we need to worry though 01.00.44 # New commit by 03theseven (r28982): iPod Classic: Unmute amplifiers when setting volume (fixes resuming paused playback) 01.00.46 # unless we need it to be super smooth i'd say 1) commit configure/rockboxdev.sh changes and send mail to client owners 2) disable all cf builds 3) reenable for people who have updated 01.01.02 # 2) isn't really needed 01.01.10 # we would probably add a new m68k-elf-gcc452 target (instead of only m68k) and trust people that have it in their runclient.sh 01.01.13 # We can do a different architecture string in the clients 01.01.22 # (as kugel said) 01.01.52 # wouldn't the only difference be a different error? 01.01.53 # r28982 build result: All green 01.01.57 # And yes, as far as I remember the plan is to do that 01.02.51 # n1s: no. If a build client announces "m68k", it won't get builds that require "m68k-elf-gcc452" 01.03.47 # The *only* problem is that this list of announced architectures is hand-built by the build client maintainers, so there's some room for human error there 01.04.22 # ok, so should we keep the option to build the old toolchain in rockboxdev.sh ? 01.05.57 # I think we should somehow have the clients report compiler (and binutils?) versions to the server automatically 01.06.17 # yes, that would be good 01.06.29 # So when the client admin specifies "m68k-elf-gcc", the script expands that to m68k-elf-gcc452 or m68k-elf-gcc346 01.07.02 # and the server should be able to decide on version requirements per-build as a sim build for example doesn't have such stric requirements 01.07.27 # right 01.07.31 Join panni_ [0] (hannes@ip-178-203-85-85.unitymediagroup.de) 01.07.32 # anyway, i'll look into adding the suffix to the script tomorrow 01.07.35 # That does complicate things a bit... 01.07.48 # then we can probably start the transition 01.07.52 # isnt the sim a completly different beast in the build system? 01.08.04 # hm, yes, it is 01.08.14 # Well, yes and no 01.08.25 # n1s: I meant doing that in the build client script 01.08.33 # Not necessarily in rockboxdev.sh 01.08.55 # gevaerts: ok, then i'm not really following :) 01.09.00 # n1s: i don't think we need the old toolchain around 01.09.03 # what do i need to do? 01.09.13 # not if it's so complicated anyway 01.09.49 Join madalu [0] (~user@unaffiliated/madalu) 01.09.52 # n1s: can you handle perl? 01.10.03 Quit MethoS- (Remote host closed the connection) 01.10.19 # kugel: i'd like to get rid of it too, only someone should keep one to do an eventual 3.7.2 release 01.10.26 # we only kept the old arm toolchain because it was a) easy and b) not all targets where tested when the transition happened 01.10.46 # gevaerts: well, i'm not very used to it but have hacked a few of our lang scripts 01.10.47 # right. We don't want to change toolchains for the stable branch 01.11.25 # But the stable branch will still have its own rockboxdev.sh, so it's always easy to build a toolchain for it 01.11.48 # indeed 01.11.54 # n1s: I think we should wait for Zagor to appear before doing this. He knows how these scripts work :) 01.12.17 # yeah, any idea when he'll be back? 01.12.31 # no idea. Maybe B4gder knows? 01.12.35 Join MethoS- [0] (~clemens@134.102.106.250) 01.14.03 Quit pamaury (Remote host closed the connection) 01.15.09 Join eRivas [0] (~be960063@giant.haxx.se) 01.15.20 # n1s: anyway, the rbclient.pl script has a bit where it checks that every arch specified with -archlist has a matching compiler. That check could presumably expand the arch string to append versions 01.16.16 # hm, actually... 01.17.36 # It now does "which m68k-elf-gcc", but somehow the gcc build also produces "m68k-elf-gcc-3.4.6" (and similar for the others). That means that the client script could check for the right compiler version (not binutils unfortunately, but that's probably minor) 01.17.51 # So all we have to do is update rbclient.pl and push a new version 01.18.21 # Pushing a new version has to be done by a server admin, so we need one of the (other :) Swedes for that 01.19.30 # yes, clever. While i might be able to do that i'm not comfortable coding things i can't test :) 01.20.16 # At the same time, when we transition to 4.5, we change the announced string to also have the version (like it's done for eabi). That way (as long as there's only one toolchain in the path), there's a cross-check between what the client admin configures and what's actually there 01.20.27 Join krazykit [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) 01.21.49 # very simple, i like 01.22.11 Join kkit|sh [0] (krazykit@silenceisdefeat.com) 01.22.17 Quit kkit|sh (Client Quit) 01.22.31 Join kkit|sh [0] (krazykit@silenceisdefeat.com) 01.24.21 # ok. So we wait for Zagor, and then we should be able to switch within a day or so 01.24.42 # It might take longer before all build clients are updated, but that's not a huge problem 01.25.23 # sounds great 01.25.29 # As long as we have a few when we switch (but not all yet, otherwise unexpected commits from just before the switch wouldn't build), we're fine 01.28.06 Quit liar (Quit: Leaving) 01.30.18 Join chattr [0] (~mike@244.87.189.72.cfl.res.rr.com) 01.33.42 Quit kugel (Remote host closed the connection) 01.37.49 # is it possible to have a windows and a linux uisim sharing the same simdisk? 01.41.34 Quit FBI_Guy (Quit: I'm outta here) 01.42.41 Quit kadoban (Ping timeout: 240 seconds) 01.43.34 Quit Keripo (Quit: Leaving.) 01.46.26 Quit eRivas (Quit: CGI:IRC) 01.46.52 Join eRivas [0] (~je@190.150.0.99) 01.52.03 # <[Saint]> eRivas: Probably. 01.52.10 # <[Saint]> Why not just try it and see? 01.52.30 Join Str89|dormbox [0] (~Strife89@adsl-80-148-184.mcn.bellsouth.net) 01.53.04 # I did copy the .rockbox from my windows install and couldnt play songs in ubuntu, said missing codec or something like that 01.53.46 # <[Saint]> well, of course that won't work. 01.54.00 # <[Saint]> I thought you only meant for testing themes or something. 01.54.04 # no, codecs and plugins are still binaries built for whatever system 01.55.05 Quit n1s (Quit: Lämnar) 01.56.19 # its just I wont be able to take screenshots of the wps with the message popping up, but yeah, menus and stuff work fine 01.56.34 Quit saratoga (Quit: Page closed) 01.56.55 # <[Saint]> why do you *need* to take screenshots of it? 01.58.11 # <[Saint]> I don't understand what it is you're trying to do. 01.59.37 # no, right now its just for fun and convinience, since that would keep both sims 'synced', just wanted to get all the functionality 02.00.19 # and screenshots are for when I want to upload themes, but thats only happens once in the theme development, so really no that critical 02.00.41 # <[Saint]> what functionality are you missing? 02.01.05 # <[Saint]> And, I believe I have already told you how to capture screenshots on the device. 02.01.50 # yeah, screen dumping or f5 on the sim 02.02.11 # <[Saint]> I'm still curious about "just wanted to get all the functionality" 02.02.35 # <[Saint]> doesn't trying to run a windows binary in *nix give you *less* functionality ") 02.02.44 # <[Saint]> * :) 02.03.12 # oh, the linux one was built from svn, not a 'wined' version 02.04.57 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 02.05.34 Join barrientos [0] (~barriento@190.150.0.99) 02.19.43 Join Strife1989 [0] (~Strife89@adsl-80-148-184.mcn.bellsouth.net) 02.22.10 Quit Str89|dormbox (Ping timeout: 246 seconds) 02.23.30 Join Str89|dormbox [0] (~Strife89@adsl-80-148-184.mcn.bellsouth.net) 02.24.19 Quit simon_ (Quit: leaving) 02.25.30 Quit Strife1989 (Ping timeout: 250 seconds) 02.26.06 *** Saving seen data "./dancer.seen" 02.27.20 Join designate72 [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 02.29.03 Quit JesusFreak316 (Read error: Connection reset by peer) 02.30.55 # i just installed 3.7.1 on a nano 2g and have an issue where i must press one of the 5way navigation buttons before the scrollwheel is activated 02.31.15 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 02.31.19 # very annoying. are there any workarounds? 02.31.59 Join Strife1989 [0] (~Strife89@adsl-80-148-184.mcn.bellsouth.net) 02.32.31 # <[Saint]> You don't mean "all the time", do you? 02.32.48 # <[Saint]> I have that issue occasionally, and it is a known bug. 02.32.59 # yes, i mean ALL the time 02.33.17 # well... if i keep it spinning it doesnt happen. 02.33.25 # <[Saint]> something must be wrong with your hardware. 02.34.16 Quit Str89|dormbox (Ping timeout: 240 seconds) 02.34.24 # <[Saint]> I have two Nano 2Nd Gens in front of me now running 3.7.1 (I just rolled back) with default settings, and I am not experiencing this. 02.34.58 Join simonrvn_ [0] (simon@70.35.168.51) 02.34.59 # <[Saint]> Could you try backing up your config.cfg and restoring the default setting state? 02.35.04 # <[Saint]> Please. 02.35.06 # i did just do a "repair" on it so maybe youre right 02.35.23 # i was just about to do this and reinstall the whole thing just incase 02.37.06 # <[Saint]> I would like to verify first that it is not an issue with your configuration file, if you'd like to back it up (you can just drag it off your player onto the desktop or something for this test) and try with default settings on the player it would help us to know if it is an issue with the hardware or not. 02.37.55 Quit simonrvn (Ping timeout: 240 seconds) 02.37.56 Nick simonrvn_ is now known as simonrvn (simon@70.35.168.51) 02.38.17 Quit barrientos (Quit: Saliendo) 02.40.07 # <[Saint]> notdavid: ^ ? 02.42.03 Quit Strife1989 (Quit: Leaving) 02.43.14 # i deleted the cfg an still persists. 02.43.37 # where is the option in rb to dump settings? 02.47.23 Join Strife89DM [0] (~Strife89@adsl-80-148-184.mcn.bellsouth.net) 02.47.31 # <[Saint]> Settings --> Manage Settings --> Save .cfg File 02.47.37 # <[Saint]> na: ^ 02.47.53 # <[Saint]> *notdavid: ^ 02.48.20 # ty 02.48.52 # <[Saint]> notdavid: Can you test please, if the clickwheel behaves normally in the original Apple firmware? 02.48.53 Quit Judas_PhD (Quit: This is a quitting message) 02.49.21 # <[Saint]> If it does not function correctly there, it is definitely a hardware problem. 02.51.03 # [Saint]: yup, wheel worked fine before i loaded rb onto it 02.51.48 # <[Saint]> can you please test the Apple firmware though to see if it still functions correctly. 02.53.16 # <[Saint]> I have 6 Nano 2nd gens, and I only ever see this bug every once in a while and it is known. ALL the time though very strongly points to something else. 02.53.25 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 02.53.56 # will do. give me a lil while though 02.56.35 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 02.59.15 Join Strife1989 [0] (~Strife89@adsl-80-148-184.mcn.bellsouth.net) 03.01.30 # [Saint]: rbutil refuses to uninstall the bootloader 03.01.37 # ;_; 03.02.08 # <[Saint]> this sounds like disk corruption, possibly. 03.02.18 # indeed 03.02.20 Quit Strife89DM (Ping timeout: 250 seconds) 03.02.23 # <[Saint]> restoring with iTunes will uninstall the bootloader. 03.03.40 # any other way besides itunes? wine still doesnt have proper usb support 03.03.53 # <[Saint]> boot the player into disk mode, and iTunes should have no problems recognising it if you want to try using your operating system to check for disk corruption. 03.04.08 # <[Saint]> dammit, why did I say iTunes there. 03.04.37 # <[Saint]> I'm not familiar with *nix disk utilities sorry. 03.06.42 # <[Saint]> notdavid: There is this: http://www.rockbox.org/wiki/Main/IpodManualRestore 03.07.07 # <[Saint]> that's all the documentation I know of for restoring an iPod without iTunes 03.12.26 # [Saint]: the ipod shows a white screen of death telling me to use itune. i should have consulted the wiki first. on the plus side, i removed rb :) 03.13.50 # <[Saint]> On a side note, I should mention that if you have access to a windows based PC it is highly reccommended that you use iTunes to restore the player. 03.15.38 # <[Saint]> If you have any questions about the iPod Manual Restore, *ask them!*, if you're unsure about anything with dd, don't blindly proceed. Incorrect use of dd can seriously harm your system. 03.22.43 Join simonrvn_ [0] (simon@211.156-ppp.3menatwork.com) 03.24.55 Quit simonrvn (Disconnected by services) 03.24.56 Nick simonrvn_ is now known as simonrvn (simon@211.156-ppp.3menatwork.com) 03.42.11 # oh to hell with this. ill just install react os and use itunes 03.42.47 # there's the manual method on the IpodManualRestore wiki page (i think the name is) 03.44.54 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 03.48.09 Quit BHSPitMonkey (Ping timeout: 264 seconds) 03.48.40 # krazykit: i tried that but i still have the white screen of death 03.51.23 Quit madalu (Read error: Operation timed out) 03.53.41 # <[Saint]> iTunes is really the preferred method, as it "just works". 03.53.58 # <[Saint]> the only downside to it is, ....using iTunes. ;) 03.56.10 # im setting up react os in qemu right now so i can run itunes and have usb support 03.57.21 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 04.03.21 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 04.04.42 Quit designate72 (Ping timeout: 265 seconds) 04.14.19 Join Barahir_ [0] (~jonathan@frnk-590fd17e.pool.mediaWays.net) 04.17.39 Quit Barahir (Ping timeout: 250 seconds) 04.17.51 Quit notdavid (Quit: quit) 04.24.06 Quit DerPapst (Quit: Leaving.) 04.26.09 *** Saving seen data "./dancer.seen" 04.31.36 Quit Judas_PhD (Quit: This is a quitting message) 04.34.25 Quit tchan (Read error: Connection reset by peer) 04.34.49 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 04.35.15 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 04.35.33 Join Keripo1 [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 04.35.48 Quit Keripo (Ping timeout: 246 seconds) 04.40.05 Join Strife89DM [0] (~Strife89@adsl-80-148-184.mcn.bellsouth.net) 04.40.53 Quit Strife89DM (Client Quit) 04.41.58 Quit Strife1989 (Ping timeout: 260 seconds) 04.43.10 Quit pixelma (Disconnected by services) 04.43.12 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.43.14 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.44.25 Quit amiconn (Disconnected by services) 04.44.25 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.44.43 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.48.39 Quit MethoS- (Remote host closed the connection) 04.55.58 Quit TheSeven (Ping timeout: 260 seconds) 04.59.35 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 05.10.37 Quit Rob2222 (Ping timeout: 260 seconds) 05.10.38 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 05.29.56 Quit Horscht (Quit: Verlassend) 05.30.12 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 05.33.49 Quit JdGordon1 (Ping timeout: 240 seconds) 05.33.56 Join JdGordon1 [0] (~jonno@vl10.gw.ok-labs.com) 05.51.45 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 05.54.18 # New commit by 03rmenes (r28983): Reword the blind description for the MPIO HD200 manual ... 05.56.33 # r28983 build result: All green 06.01.57 Quit eRivas (Quit: Saliendo) 06.05.27 Quit parafin (Ping timeout: 260 seconds) 06.06.31 Join parafin [0] (parafin@paraf.in) 06.17.31 # New commit by 03jethead71 (r28984): MPEGPlyaer: A bit of audio mutation. Remove a useless thread state. Take some control over the buffer away from the audio thread itself. Some ... 06.18.37 Quit kadoban (Ping timeout: 255 seconds) 06.20.06 # r28984 build result: All green 06.26.13 *** Saving seen data "./dancer.seen" 06.30.24 # New commit by 03jethead71 (r28985): Put illustrative switch case back, because it clarifies intention...maybe ;). 06.32.45 # r28985 build result: All green 07.02.02 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 07.06.11 Quit JdGordon1 (Quit: leaving) 07.07.45 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 07.08.41 Quit factor (Ping timeout: 272 seconds) 07.15.47 Quit mikroflops (Quit: "foo") 07.16.07 Quit Keripo1 (Quit: Leaving.) 07.19.26 Quit rvvs89 (Ping timeout: 255 seconds) 07.20.08 Join rvvs89 [0] (rvvs89@mussel.ucc.gu.uwa.edu.au) 07.27.56 Quit pjm0616 (Quit: pjm0616) 07.29.33 Join T44 [0] (~Topy44@f048141136.adsl.alicedsl.de) 07.31.21 Join mikroflops [0] (~yogurt@h-34-71.A238.priv.bahnhof.se) 07.33.02 Quit Topy (Ping timeout: 240 seconds) 07.42.11 Join kugel [0] (~kugel@2.210.240.117) 07.42.12 Quit kugel (Changing host) 07.42.12 Join kugel [0] (~kugel@rockbox/developer/kugel) 08.00.04 Quit BHSPitMonkey (Remote host closed the connection) 08.00.40 Quit rvvs89 (Remote host closed the connection) 08.21.20 Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) 08.21.45 Join Buschel [0] (~chatzilla@p54B67359.dip.t-dialin.net) 08.26.01 Quit Buschel (Client Quit) 08.26.14 *** Saving seen data "./dancer.seen" 08.27.42 Quit t0rc (Ping timeout: 250 seconds) 08.28.54 Quit kugel (Ping timeout: 260 seconds) 08.29.02 Join Topy [0] (~Topy44@f048064109.adsl.alicedsl.de) 08.31.50 Quit T44 (Ping timeout: 240 seconds) 08.48.46 Join JuanArg [0] (~be0b617a@giant.haxx.se) 08.50.30 # Hello, I'm looking for help using tcctool with a Sansa c140, would anyone be willing to help? 08.53.58 Join kugel [0] (~kugel@rockbox/developer/kugel) 08.54.56 # I already installed the driver to boot the device from USB and I read on the Cowon community that you need to add the device name to the command line, and I don't know how should I write it 08.55.52 # I mean, should I write c100, c140, Sansa...? (Not spamming, just writing my question) 08.59.31 Quit JuanArg (Quit: CGI:IRC (EOF)) 08.59.37 Join JuanArgPt2 [0] (~be0b617a@giant.haxx.se) 09.00.38 Nick JuanArgPt2 is now known as JuanArg (~be0b617a@giant.haxx.se) 09.01.22 # May I have forgotten any other piece of info? 09.04.05 Join pjm0616 [0] (~user@114.200.203.243) 09.04.42 Quit JdGordon| (Quit: leaving) 09.06.24 # <[Saint]> AlexP: Ping? 09.06.32 Join ender` [0] (krneki@foo.eternallybored.org) 09.06.45 # <[Saint]> argh...nevermind. 09.06.51 # pong 09.07.35 # <[Saint]> last time I checked JuanArg, you weren't AlexP :D 09.08.09 # JuanArg: If you run tcctool without any parameters, it displays the list of device names. 09.08.49 # Saint: Sorry, I missed the username you had typed before. 09.09.37 # <[Saint]> No problem, sorry I said "argh"...but I meant "Oh crap!", it's a coincidence it slightly matches your nick. 09.09.39 # <[Saint]> sorry ;) 09.09.41 # linuxstb: thank you very much. I'll try that. 09.10.19 # Saint: It's alright, no problem at all :) 09.14.46 # linuxstb: I got it. Thank you very much again. 09.23.42 Join kevku [0] (~kevku@2001:7d0:0:f000::135d) 09.24.10 Join stoffel [0] (~quassel@p57B4CDC2.dip.t-dialin.net) 09.26.18 Quit JuanArg (Quit: CGI:IRC) 09.29.37 Quit Judas_PhD (Quit: This is a quitting message) 09.29.40 Join petur [0] (d408b802@rockbox/developer/petur) 09.33.31 Quit [Saint] (Quit: I'm only going to Heaven if it feels like Hell, I'm only going to Heaven if it tastes like caramel...) 09.37.50 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 09.39.16 Quit kevku (Read error: Operation timed out) 09.39.43 Join kevku [0] (~kevku@arch.tunnel.ipv6.estpak.ee) 09.47.08 Join Saij [0] (~Saij@cpe-24-93-30-86.rochester.res.rr.com) 10.08.17 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 10.21.34 Join [Saint] [0] (S_a_i_n_t@203.184.0.253) 10.26.09 Quit sasquatch (Quit: translocating) 10.26.17 *** Saving seen data "./dancer.seen" 10.31.02 Join tails__ [0] (~tails@host-94-251-111-208.bbcustomer.zsttk.net) 10.32.52 Quit Saij (Read error: Connection reset by peer) 11.05.55 Join DerPapst [0] (~Alexander@91-66-226-46-dynip.superkabel.de) 11.08.32 Quit Judas_PhD (Quit: This is a quitting message) 11.09.33 Quit kevku (Remote host closed the connection) 11.14.39 Join Saij [0] (~Saij@cpe-24-93-30-86.rochester.res.rr.com) 11.14.41 Part Saij 11.14.49 Join alex121997 [0] (~alex12199@p5DDB243B.dip.t-dialin.net) 11.15.33 # how to get MIDI playing on rockbox? 11.16.16 # Or better said, how to get MID files playing on rockbox? 11.16.27 # Thank you. 11.18.26 Join n1s [0] (~n1s@90-230-78-242-no134.tbcn.telia.com) 11.18.34 Quit n1s (Changing host) 11.18.34 Join n1s [0] (~n1s@rockbox/developer/n1s) 11.19.00 # which player do you own and what's our manual telling you? 11.19.47 # I own an iPod touch 5g (video) 30 gb. 11.20.10 # I gonna read the manual... 11.20.19 # sec please. 11.21.03 Join Saij [0] (~Saij@cpe-24-93-30-86.rochester.res.rr.com) 11.21.10 # http://download.rockbox.org/daily/manual/rockbox-ipodvideo/rockbox-buildch11.html#x14-25100011.3.6 11.21.22 # thx. 11.21.27 # :) 11.21.40 Quit kadoban (Ping timeout: 265 seconds) 11.23.56 Quit kugel (Ping timeout: 272 seconds) 11.27.53 Join kevku [0] (~kevku@2001:7d0:0:f000::135d) 11.31.32 Quit stoffel (Ping timeout: 272 seconds) 11.36.35 Part Saij 11.39.50 Quit efyx (Quit: Quitte) 11.41.14 Quit alex121997 (Ping timeout: 240 seconds) 11.42.14 Join Saij [0] (~Saij@cpe-24-93-30-86.rochester.res.rr.com) 11.47.38 Quit Saij (Read error: Connection reset by peer) 12.00.49 Join max131 [0] (~c3cf6570@giant.haxx.se) 12.01.48 Quit petur (Quit: Page closed) 12.02.13 # damnit, i've got a file system corruption again on the fuze-v1. I'm running r28979 now, but i had a 'delayed write failed' error in windows xp. So the USB stack is not as solid as i expected?? 12.03.09 # this time around i was moving nearly 1G of files from the hard disk to the internal memory of the fuze, _not_ to the uSD 12.04.35 # after the delayed write failed, the fuze locks up entirely, the only thing i can do is a 'hard reset', i.e. keeping the slider on the right of the fuze up for more than 10 seconds 12.05.04 # that sounds just like the recent sd issues 12.05.43 # the revert in r28925 made them go away for me at least 12.06.06 # max131: did it ever work right and can you reproduce this error? 12.06.12 # yeah, i thought that too 12.06.38 # reproducability is not that easy 12.07.03 # i thought things got solved with r28295, that's why i did some stress tests during past days 12.07.31 # which all passed, where i did about 4 tests writing large amounts of data 12.07.53 # it just happens, sometimes ... 12.08.12 # if i find a way to reproduce, i'll let you peeps now 12.08.23 # r28925 only reverted r28834 so if it didn't work before that there's no reason for it to work now 12.08.56 Join kugel [0] (~kugel@rockbox/developer/kugel) 12.09.06 # well, i thought the fs-corruptions started with r28834 12.09.44 # that's what i was trying to ask you before, did it ever work as in before that commit? 12.11.16 # i don't think i ever had fs-corruptions with pre-r28834 builds 12.13.03 Join stoffel [0] (~quassel@p57B4CDC2.dip.t-dialin.net) 12.13.26 # and these fs-corruptions do occur on the internal storage 12.18.04 Join wodz [0] (~5f303f8a@giant.haxx.se) 12.18.45 # n1s: Have you conducted battery_bench tests gcc 3.4.6 vs. 4.5.2? 12.19.26 # back to work now, i'll keep you posted ... 12.19.57 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 12.20.06 Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) 12.20.12 Quit max131 (Quit: CGI:IRC (EOF)) 12.21.20 # wodz: no 12.21.51 # It would be interesting 12.23.54 # they take forever and unless you use a codec that got significantly faster i wouldn't expect any notable change 12.25.18 # If you point me once more to the hd300 build with new gcc I may run battery_bench anyway 12.26.18 *** Saving seen data "./dancer.seen" 12.26.55 # wodz: http://dl.dropbox.com/u/17484767/rockbox-hd300.zip 12.27.36 # if you are interested in the codec speed changes, http://dl.dropbox.com/u/17484767/h300_test_codec_gcc4.5.2_vs_svn.ods 12.27.38 # thx 12.28.32 # what is final plan for switch? Post on ML and 'away we go'? 12.30.04 # well, i had a discussion with gevaerts last night about how to do the distributed build system switch and he had a clever idea but we wanted to talk to Zagor about it first so we'll probably wait for him but after that is set up we are pretty much ready to go 12.30.32 # i need to retest one thing on cygwin 12.31.03 # nice 12.31.26 # B4gder: any idea when Zagor will be back? 12.33.49 # n1s: not just *wanted*. We need Zagor (or possibly B4gder, but he usually points to Zagor for these things) for the server-side work 12.40.03 # New commit by 03rmenes (r28986): Add iPod Classic to the "Unusable" category. Also ... 12.40.21 Join LambdaCalculus37 [0] (~rmenes@c-68-36-232-73.hsd1.nj.comcast.net) 12.40.21 Quit LambdaCalculus37 (Changing host) 12.40.21 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) 12.41.15 # Zagor, Bagder: (for the logs) Just made an update to index.t; can one of you guys update the front page? 12.42.50 Join bmbl [0] (~bmbl@unaffiliated/bmbl) 12.59.17 # gevaerts: ah 13.02.08 Quit LambdaCalculus37 (Quit: Fwump) 13.03.37 # * TheSeven realizes that the µsec timer on the ipod classic is broken 13.04.48 # TheSeven: is that brokeness the source of your problems? 13.04.58 # no idea... 13.05.16 # i don't think anything besides the clickwheel acceleration (and the profiling code i just added) uses it 13.06.10 # ah, so another timer is used for ticks? 13.07.16 # What about system ticks? Are you sure it works as advertised? I had various strange effects on HD200 when tick was much longer due to bug in timer configuration 13.08.34 # current_tick seems to advance properly at least 13.09.56 # New commit by 03theseven (r28987): Fix iPod Classic USEC_TIMER 13.10.30 # hm, if anything, the tick is too fast 13.10.56 # at least my splashf(HZ, whatever) calls are only on the lcd for about half a second 13.11.34 # so I guess this is the root of the problems with playback 13.12.12 # r28987 build result: All green 13.12.51 # hm, it's ticking ~60% too fast 13.15.54 # * kugel asked if the timer tick is correct a few days ago :) 13.18.38 Join Stephenc___ [0] (~5347c520@giant.haxx.se) 13.20.12 Join MethoS- [0] (~clemens@134.102.106.250) 13.21.03 Quit kugel (Remote host closed the connection) 13.23.12 # anyone able to read todays irc log ? 13.24.21 # "Pressing the rocker in functions as..." - am I the only one who had to read this sentence a few times before understanding that the "in" belongs to the "pressing"? I think that the section got better overall but I had a bit of trouble with this tiny thing 13.25.34 # Stephenc___: I am (even the live reader) in firefox. Which browser do you use? 13.26.27 # New commit by 03theseven (r28988): Fix iPod Classic tick timer (still not 100% calibrated, but close enough for now) 13.26.42 # I usually prefer the current.txt anyway even if it means that I have to update the page manually from time to time 13.26.56 # and no, it didn't fix playback 13.27.34 # i did some IRQ load profiling which ended up at 5 milliseconds of time in the PCM IRQ handler over like a minute of playback 13.27.38 # so that's not the cause either 13.27.47 # where else might it get stuck? 13.27.57 # should i try to figure out tick timer IRQ load? 13.28.14 # pixelma using firefox here too, must try IE 13.28.28 # it's a shame that the rockbox scheduler doesn't do some basic thread and kernel load profiling at least 13.28.38 # (roughly like what embios does) 13.28.40 # TheSeven i guess it didn't fiz the Thick 160gb models either ;o) haha 13.28.54 # r28988 build result: All green 13.29.07 # s/fiz/fix 13.29.34 # what else might be causing this playback trouble? 13.29.53 # pixelma working in IE must be my old version of firefox, strange tho coz the other days it worked. 13.30.12 # i'd really like to know who's eating all that CPU time... 13.32.11 Join dfkt [0] (dfkt@unaffiliated/dfkt) 13.35.40 Join TheLemonMan [0] (~lem0n@ppp-86-135.98-62.inwind.it) 13.38.03 Quit Stephenc___ (Quit: CGI:IRC) 13.38.53 Join bluebrother [0] (~dom@g226070071.adsl.alicedsl.de) 13.38.53 Quit bluebrother (Changing host) 13.38.53 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 13.42.00 Quit kevku (Ping timeout: 272 seconds) 13.42.11 Quit bluebroth3r (Ping timeout: 276 seconds) 13.44.10 Join petur [0] (~petur@rockbox/developer/petur) 13.46.28 # TheSeven: I'm reading http://www.freemyipod.org/wiki/IPod_Classic_iLoader_Installation - does it really destroy all your data? What exactly is happening when you follow those instructions - is iloader being written to NOR? 13.46.38 # yes 13.46.52 # yes to which question? 13.46.57 # both 13.47.14 # it will be flashed to NOR and the HDD will be reformatted, as apple seems to be doing something funky that's preventing us from mounting it 13.47.32 # Well, that's nice of them... 13.47.55 # might be related to them hiding away the firmware partition and thus offsetting things 13.48.13 # i haven't inspected that in detail yet, i just wanted to get around it for now 13.48.37 # also it doesn't really hurt much as we don't have dualboot yet 13.48.50 Join kevku [0] (~kevku@2001:7d0:0:f000::135d) 13.49.25 # (the cause for dualboot failing seems to be the OF locking up waiting for an I2C bus access to finish - and I have absolutely no clue why) 13.49.55 # Do you keep the Apple code in NOR? 13.51.34 Quit parafin (Ping timeout: 260 seconds) 13.52.33 # no, it will be written to norflash.bak and then wiped 13.55.27 Nick Guinness` is now known as Guinness (Slayer@c-68-55-111-159.hsd1.va.comcast.net) 13.55.34 Join parafin [0] (parafin@paraf.in) 13.56.01 Join Buschel [0] (~chatzilla@p54A3AC77.dip.t-dialin.net) 14.10.03 Quit benedikt93 (Quit: Bye ;)) 14.13.33 # TheSeven: did you try with a dummy pcm driver (that doesn't actually do the transfers to the codec)? 14.14.00 # my guess would still be too many interrupts but from what= 14.14.06 # s/=/?/ 14.14.50 # no, i didn't try that yet. 14.14.58 # how should such a thing behave? 14.15.12 # register a tick function that calls the PCM get more callback? 14.15.24 # i don't know exactly 14.18.04 # hm, might pcm_get_bytes_waiting returning very funky values be the cause? 14.20.45 # wow 14.20.54 # it actually seems to be pcm_get_bytes_waiting that's eating the cpu cycles 14.20.59 # fixed it? ;) 14.22.18 # no, i have absolutely no clue why it happens, but i have proof that this function is going nuts 14.23.05 # the codec thread seems to use that function to determine the elapsed time so i'd guess wrong values would confuse it 14.23.19 # well, the implementation for S5L8702 is the only that has a while-loop inside 14.23.42 # http://pastie.org/1437143 (what you just looked at) 14.23.57 # the splash shows like 300000 iterations sometimes 14.24.17 # *facepalm* 14.24.27 # :) 14.24.38 # hm, that's not trivial to fix 14.24.39 # this sounds like you've got it 14.25.08 # yeah, i know what it's doing and why, but it won't be easy to change that 14.25.13 # * TheSeven heads off for lunch 14.26.21 *** Saving seen data "./dancer.seen" 14.27.26 Join WonTu [0] (~WonTu@p57B52BE2.dip.t-dialin.net) 14.27.40 Part WonTu 14.30.52 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 14.36.00 Join sideral [0] (~sideral@unaffiliated/sideral) 14.47.24 # oh yeah 14.47.35 # that function only ever terminates if the pcm buffer is empty 14.47.37 # <[Saint]> yeah? 14.47.43 # that explains the stuttering very well 14.48.00 # <[Saint]> awesome...is it an easy fix, though? 14.48.13 # however it doesn't explain how flac can ever have worked 14.48.18 # would "return remaining + (DMAC0C0LLI.control & 0xfff) * 2;" fix it? 14.48.22 # <[Saint]> I've been looking for a cheap Classic, btw ;) 14.48.37 # * [Saint] wants in on this port. 14.48.38 # that would fix it, but return wrong results 14.48.57 # actually i need to figure out where the end of that ring buffer is :) 14.49.39 # nowhere, it's a ring. ;) 14.51.38 # the functions return value is used to check the playback latency. what would go wrong if this would results in a too small number? 14.52.03 # baaah, typos, typos, typos... 14.53.21 # would it really be an issue? 14.54.26 Join mgue [0] (~mgue@pD95E6679.dip.t-dialin.net) 14.55.38 # New commit by 03theseven (r28989): Fix iPod Classic playback slowness 14.55.53 # playback still isn't clean though 14.56.03 # sometimes wrong chunks seem to slip in 14.58.02 # * TheSeven starts to consider the ipod classic port usable :) 14.58.08 # r28989 build result: 0 errors, 1 warnings (theseven committed) 14.58.18 # (not meant in terms of our tiers, but "ready for everyday use by myself) 14.58.58 # now where does that warning come from 15.00.02 # * TheSeven needs to pun away the volatile 15.00.38 # New commit by 03theseven (r28990): Fix yellow 15.02.01 Join komputes [0] (~komputes@ubuntu/member/komputes) 15.02.02 # * TheSeven spots some GPIO issues 15.03.21 # r28990 build result: All green 15.03.47 # and that annoying "playing garbage after plugging usb in charging mode" bug is back :/ 15.04.45 # * TheSeven wonders where those periodic glitches are coming from 15.05.44 # a periodic glitch every three seconds 15.05.53 # (sounds like some small chunk being played twice) 15.07.48 # hm, three seconds is the length of the PCM buffer 15.09.57 # Buschel: it would cause the playback progessbar to jump around, and the only reason why it wouldn't cause playback corruption is the lacking support for pcm double buffering in the pcmbuf code 15.10.40 # TheSeven: after your changes to the us timer -> what do the mem and codec tests say? 15.11.06 # you mean the tick timer? 15.12.32 # DRAM: 170.6MB/s read, 345.9MB/s write, 355.5MB/s memset, 216.9MB/s memcpy 15.12.55 # IRAM: 206.4MB/s read, 290.9MB/s write, 290.9MB/s memset, 246.1MB/s memcpy 15.14.39 # this is a far more than the 8700/8701 reaches... 15.16.10 Quit anewuser () 15.16.32 # a factor of ~10 IIRC? 15.16.43 # IRAM: rd 2x, wr 4x DRAM: rd 3x, wr 9x 15.16.52 # about this... 15.17.18 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 15.17.21 # mDDR seems to pay off :) 15.18.00 # test codec results should also reach wuit 15.18.07 # oops... 15.18.20 # test codec results should also reach quite interesting numbers 15.19.10 # hm, now why does the pcmbuf wrapping cause glitches? weird chunk sizes? 15.22.03 # wow. splashf works from an IRQ handler o.0 15.23.17 Quit wodz (Quit: CGI:IRC) 15.23.25 # heh as long as it doesn't sleep, right? also IIUC it's not guaranteed to work though, the ui thread could draw over it at any time 15.27.39 Quit Buschel (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]) 15.28.34 Quit stoffel (Ping timeout: 240 seconds) 15.31.06 # yes, the UI thread starts throwing things into the top left corner sometimes, but it works well enough for debugging :) 15.34.06 Join sasquatch [0] (~username@p4FF2D808.dip.t-dialin.net) 15.36.55 Quit Keripo (Quit: Leaving.) 15.42.57 Quit petur (Quit: *plop*) 15.51.21 Join anewuser [0] (anewuser@unaffiliated/anewuser) 15.53.11 Join webguest67 [0] (~ce82d31d@giant.haxx.se) 15.53.21 # Hi, I need some help 15.54.01 # anyone? 15.54.22 # webguest67: if you tell us what your problem is it's a lot easier to help 15.55.51 # Ok, i got rockbox for ipod video, but when i go to use the ipod patch thing, it says there is no ipod connected 15.55.57 # Ok, i got rockbox for ipod video, but when i go to use the ipod patch thing, it says there is no ipod connected 15.56.04 DBUG Enqueued KICK webguest67 15.56.04 # Ok, i got rockbox for ipod video, but when i go to use the ipod patch thing, it says there is no ipod connected 15.56.51 # which "ipod patch thing" ? 15.57.01 # ok, the ipod patch says there is no ipod connected. 15.57.10 # . 15.57.11 # jwkuhnekr 15.57.15 Quit webguest67 (Client Quit) 15.57.24 Join webguest11 [0] (~ce82d31d@giant.haxx.se) 15.57.44 # ipod patch says there is no ipod connected 15.57.53 Part part ("ugh - repeats") 15.58.13 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 15.58.37 # webguest11: is that "ipod patch thing" ipod patcher or rbutil? Are you *sure* it's an ipod video and not a "classic"? 15.59.05 # oh and have you installed ipod linux or done anything else funky to the partition table? 15.59.19 # no, this is all i want to do 16.00.03 # and i got the patch off the online manual.... 16.00.13 # and i have windows 16.00.20 # and it is an ipod video 16.02.22 # I'm trying again as we speak 16.03.06 # What capacity? 16.03.39 # 8 gb 16.03.57 # That's not an iPod Video. 16.04.02 # no? 16.04.05 # Are you perhaps referring to the "iPod Nano Video"? 16.04.10 # possibly 16.04.28 # It's important to know exactly which player you have before you start. 16.04.34 # it may be an ipod nano 3rd gen 16.04.40 # The iPod Video came in 30, 60, and 80GB capacities. 16.04.45 # Rockbox does not work on the iPod Nano 3rd gen. 16.04.48 # in fact, i'm sure it is now 16.04.50 # <[Saint]> There's an "iPod Nano Video"?!? 16.04.56 # [Saint]: no 16.05.07 # <[Saint]> what naming scheme is that pulled from...? 16.05.11 # [Saint]: That's what some people call certain iPod Nanos, though it's an unofficial name. 16.05.13 # ther are nanos that can play videos thpo 16.05.25 # <[Saint]> n1s: Errr...wrong. 16.05.31 # the same as classic color etc :) 16.05.33 # web going funky, brb 16.05.35 # <[Saint]> dammit, sorry. 16.05.36 Quit webguest11 (Quit: CGI:IRC) 16.05.44 Join webguest17 [0] (~ce82d31d@giant.haxx.se) 16.05.46 # <[Saint]> I read an imaginary "no" in there :P 16.06.12 # so, is there no rockbox for ipod nano 3rd gen? 16.06.18 # <[Saint]> No. 16.06.27 # damn 16.06.47 Quit Keripo (Quit: Leaving.) 16.07.06 # ok, so this is a no go 16.07.58 # so, if i were to ty the 2nd gen, could it possibly work? 16.08.11 # <[Saint]> Try some reading. 16.08.19 # ... 16.08.22 # <[Saint]> rockbox.org lists our supported devices. 16.08.30 Quit webguest17 (Client Quit) 16.10.14 Quit sasquatch (Ping timeout: 240 seconds) 16.11.18 Join sasquatch [0] (~username@p4FF2CAD8.dip.t-dialin.net) 16.16.19 # New commit by 03theseven (r28991): iPod Classic: Fix remaining PCM issues and add DMA information to the HW debug screen 16.16.31 # finally glitch-free playback... 16.16.35 Join sideral1 [0] (~sideral@unaffiliated/sideral) 16.18.49 # r28991 build result: All green 16.19.28 Quit sideral (Ping timeout: 240 seconds) 16.26.25 *** Saving seen data "./dancer.seen" 16.26.26 Quit sideral1 (Remote host closed the connection) 16.27.10 Join sideral [0] (~sideral@unaffiliated/sideral) 16.30.33 # New commit by 03theseven (r28992): Add LCD type to iPod Classic HW debug screen 16.33.14 # r28992 build result: All green 16.36.41 Quit sideral (Remote host closed the connection) 16.37.36 Join sideral [0] (~sideral@unaffiliated/sideral) 16.46.58 Quit sideral (Ping timeout: 240 seconds) 16.47.42 Join sideral [0] (~sideral@unaffiliated/sideral) 16.47.52 Quit guymann (Quit: new kernel) 16.48.43 Quit MethoS- (Remote host closed the connection) 16.50.48 Join Horscht [0] (~Horscht@xbmc/user/horscht) 16.57.11 Quit sideral (Remote host closed the connection) 16.58.12 Join sideral [0] (~sideral@unaffiliated/sideral) 16.59.17 # No Classic on the front page? 16.59.40 Join guymann [0] (~charles@66-159-148-95.adsl.snet.net) 17.00.08 # <[Saint]> rasher: IIRC the change was pushed to SVN, but the page needs updating. 17.00.54 Join MethoS- [0] (~clemens@134.102.106.250) 17.01.37 Quit MethoS- (Remote host closed the connection) 17.03.01 Join kugel [0] (~kugel@46.114.114.218) 17.03.02 Quit kugel (Changing host) 17.03.02 Join kugel [0] (~kugel@rockbox/developer/kugel) 17.03.22 Join MethoS- [0] (~clemens@134.102.106.250) 17.04.10 Quit MethoS- (Remote host closed the connection) 17.06.36 Join factor [0] (~factor@75.108.68.114) 17.07.03 Join MethoS- [0] (~clemens@134.102.106.250) 17.07.19 Quit MethoS- (Remote host closed the connection) 17.07.26 Quit sideral (Remote host closed the connection) 17.08.17 Join sideral [0] (~sideral@unaffiliated/sideral) 17.08.22 Quit kugel (Read error: Connection reset by peer) 17.09.39 Join panni_ [0] (hannes@ip-178-203-85-85.unitymediagroup.de) 17.09.46 Join kugel [0] (~kugel@46.114.114.218) 17.09.48 Quit kugel (Changing host) 17.09.48 Join kugel [0] (~kugel@rockbox/developer/kugel) 17.12.56 Join MethoS- [0] (~clemens@134.102.106.250) 17.13.47 Quit MethoS- (Remote host closed the connection) 17.17.29 Join MethoS- [0] (~clemens@134.102.106.250) 17.17.50 Quit MethoS- (Remote host closed the connection) 17.21.20 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 17.21.48 Join MethoS- [0] (~clemens@134.102.106.250) 17.24.27 Quit sideral (Ping timeout: 246 seconds) 17.26.31 Join stoffel [0] (~quassel@p57B4CDC2.dip.t-dialin.net) 17.27.54 Join sideral [0] (~sideral@unaffiliated/sideral) 17.32.07 Join captainkewll [0] (2669ecc2@gateway/web/freenode/ip.38.105.236.194) 17.33.05 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 17.33.05 Quit bertrik (Changing host) 17.33.05 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 17.33.29 Join {phoenix} [0] (~dirk@p57AA343E.dip.t-dialin.net) 17.37.54 Join {-phoenix-} [0] (~dirk@p57AA6C22.dip.t-dialin.net) 17.37.56 Quit sideral (Remote host closed the connection) 17.38.43 Join sideral [0] (~sideral@unaffiliated/sideral) 17.39.38 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 17.40.55 Quit guymann (Ping timeout: 264 seconds) 17.41.40 Quit FOAD (Quit: I'll be back) 17.42.07 Quit {phoenix} (Ping timeout: 264 seconds) 17.44.55 Quit sideral (Ping timeout: 240 seconds) 17.46.00 Join FOAD [0] (~dok@83.161.135.61) 17.52.39 Quit elcan (Read error: Connection reset by peer) 18.02.39 Quit TheLemonMan (Quit: free(me)) 18.04.28 Quit mgue (Quit: Lost terminal) 18.09.36 Quit tails__ (Ping timeout: 246 seconds) 18.14.58 Join krabador [0] (~krabador@host149-176-dynamic.47-79-r.retail.telecomitalia.it) 18.15.51 # hi people, by sometimes i'm trying rockbox on android, i'm trying the svn version available on rockbox site 18.16.31 # my lead use is music playback 18.16.44 # for flac files is the best way at the moment 18.17.33 # by the way when i'm using a file browser, i can't chose rockbox on "open with " option 18.17.49 Join elcan [0] (user36@pr0.us) 18.17.57 # isn't yet implemented, or it's a problem of mine? 18.19.42 Join Guinness` [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) 18.20.14 # rockbox isn't very integrated into android as an app yet 18.20.23 # so that kind of functionality is not implemented 18.20.35 Quit Guinness` (Read error: Connection reset by peer) 18.22.55 Quit Guinness (Ping timeout: 240 seconds) 18.24.31 Join Guinness [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) 18.26.26 *** Saving seen data "./dancer.seen" 18.28.50 Quit B4gder (Ping timeout: 240 seconds) 18.30.58 Join cormon [0] (~chatzilla@ip68-230-164-146.mc.at.cox.net) 18.31.48 # Is .m4a supported in rockbox 18.31.59 # ? 18.32.17 Join B4gder [0] (~daniel@rockbox/developer/bagder) 18.32.27 # cormon: yes 18.32.43 # (as a container for aac or alac IIRC) 18.32.58 # it does not seem to work on my cowon D2. 18.33.53 # are the files DRM'ed/protected/encrypted? 18.34.22 # Rockbox also can't play very long ones. 18.34.27 # And depends o 18.34.41 # depends on the metadata being organized properly (at the start of the file?) 18.35.42 Join LambdaCalculus37 [0] (~3f74f70d@rockbox/staff/LambdaCalculus37) 18.36.05 # the files are not DRMed. They are just over two hours long. 18.36.23 # B4gder: Ping 18.36.45 Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 18.36.54 # that could be my problem. 18.38.01 # is there any solution to playing long m4a files on rockbox or will i have to split the file? 18.39.30 # Split, or convert to another format. 18.39.39 # I don't believe any other supported format has a length restriction. 18.39.58 # if you have foobar2k there's some feature to "optimize" the layout of the files that might help 18.40.26 # Yes, that will solve the problem if the issue is the metadata location. 18.41.20 Join sbmull [0] (~a6434206@giant.haxx.se) 18.42.42 # I have written a LUA Flash Card program for my Sansa Clip+. Please see FS#11864 - Working LUA Flashcard Program 18.44.46 # It uses export files from the popular ANKI (http://ankisrs.net/). I have posted code, a card file and screenshots. 18.45.08 # I use it for studying Russian. Unicode works great! 18.45.23 Quit FlynDice (Remote host closed the connection) 18.45.41 Quit sbmull (Client Quit) 18.46.13 Join sbmull [0] (~a6434206@giant.haxx.se) 18.47.48 # does the Application target compile again? 18.48.03 # sbmull: if you want sqlite, it may be possible to integrate FS#8852 in lua 18.48.09 # i don't remember who, but someone was making modifications to it yesterday that resulted in compile errors 18.49.39 # amee2k: no fix has been committed yet. Reverting the two commits that broke this is still the best you can do 18.49.57 Quit shai (Quit: Leaving) 18.50.32 # TheSeven: Ping, can you send me a build for the iPod Classic built on the most recent SVN? 18.51.07 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 18.51.07 # * TheSeven just updated the one on files.freemyipod.org, if you mean an installer build 18.51.21 # TheSeven: Just a Rockbox build. 18.51.32 # that has already been added to the build system :) 18.51.41 # http://build.rockbox.org/data/rockbox-ipodclassic.zip 18.52.20 # TheSeven: Thanks. :) 18.53.58 # [Saint]: Wassup? 18.54.08 # anyone? 18.54.59 # <[Saint]> AlexP: Sorry, nevermind...I thought I found a tag missing in the manual but it was just in a place I didn't expect it to be at the time. 18.55.13 # <[Saint]> and, unfortunately you can't "un-ping" someone. 18.55.24 # heh, no worries :) 18.55.42 # which tag was it? 18.56.34 Join guymann [0] (~charles@66-159-148-95.adsl.snet.net) 18.57.01 # TheSeven: Help my bleeding ears here... you said that you had gotten volume control working on the Classic before, right? 18.57.43 Quit kugel (Ping timeout: 264 seconds) 18.58.12 # yep 18.58.22 # <[Saint]> pixelma: %cc "has RTC?" 18.58.48 # <[Saint]> I was looking in Time & Date, but I forgot about the Hardware Capabilities section. 18.58.52 # isn't it in the hardware present section? 18.59.25 # TheSeven: Adjusting the sound controls affects the output volume. I'm trying to raise up the bass on my Classic in the sound setting menu and it nearly blew my brains out. 18.59.26 # LambdaCalculus37: it was a matter of adjusting some rather insane ifdef 19.00.06 # hm, interesting 19.00.24 # apparently enabling the DSP increases the volume 19.00.59 # hm, or it's just some reg mixup 19.01.01 # [Saint]: Time & Date was a bit silly for the targets that do not have an RTC - this section was only enabled for this one tag and I guess that was confusing too 19.01.01 # let me check 19.01.04 # TheSeven: Same behavior applies when I try adjusting the treble settings. 19.01.05 Quit cormon (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]) 19.01.17 # <[Saint]> How would you get around that? Pre-cut when a DSP is enabled? 19.01.44 # i'm pretty sure it's just a bug somewhere 19.01.46 # [Saint]: IIRC that's the way to do it. 19.02.11 Quit pjm0616 (Read error: Connection reset by peer) 19.04.17 # <[Saint]> pixelma: Yes, it was just my train of thought - "%cc - is there an RTC? - clock - time - time & date - why isn't it there? - it's not there!" 19.04.23 # TheSeven: But on the bright side, great work on speeding up audio decoding. :) 19.04.31 # <[Saint]> and then I found the Hardware Capabilities section :P 19.06.41 Join saratoga [0] (9803c6dd@gateway/web/freenode/ip.152.3.198.221) 19.07.06 # LambdaCalculus37: it's still a mystery how FLAC could work before that fix 19.07.19 # Llorean, n1s: (catching up on logs) IIRC the foobar optimize function shouldn't be needed anymore for M4A files 19.07.41 # although theres basically no chance of a 2 hour AAC file playing anyway 19.07.43 # that bug made that "get remaining bytes" function loop until the pcm buffer was almost empty 19.08.01 # ah, makes sense why testcodec worked fine then! 19.08.17 # i'm curious though, i saw you fixed the timer, does that mean your test_codec results were inaccurate? 19.08.34 # if they depend on the tick timer, probably yes 19.08.43 # saratoga: Is there some reason we can handle arbitrary lengths of most formats, but not AAC? 19.08.47 # divide the MHz numbers by ~1.6 in that case :) 19.08.53 Quit Topy (Read error: Connection reset by peer) 19.08.54 # Is it a format limitation, or just something "not finished yet" in Rockbox? 19.08.58 # i expect them to be wrong, but i'm not sure about the timmer 19.09.13 # * TheSeven might do a full codec test tonight 19.09.26 # Llorean: yeah because the mp4 spec is a mess and the spec isn't free either, so i'm not sure what the "right" fix is to long files 19.09.33 # it would be nice if test_codec would use the usec timer for that 19.09.54 # i can hack it up so that long files play (at least from apple) but i have no idea if the parser is even correct at that point 19.10.34 # right now we use a look up table to keep track of where individual mp4 frames are in the bit stream, but if the file is more then 45 minutes long you run out of ram to store the lookup table 19.11.19 # TheSeven: if those memory results are right then I expect you to be quite a bit faster then AMSv2, which could do flac in under 10MHz 19.12.15 # <[Saint]> sheesh. 19.12.32 # gevaerts: looks like FS#8852 has been closed. 19.12.34 # saratoga: Might it make sense to take your "hacked up"version and put it in the 'official test builds' section and see if anyone can find files it doesn't like? 19.12.38 Quit bmbl (Quit: Verlassend) 19.12.45 # * TheSeven would really like to know how fast the nano4g would be 19.12.55 # sbmull: yes, because we don't plan to commit that without any code that uses it 19.13.14 # these little things might well outperform the beast 19.13.17 # yes, thats on my todo list, just pretty far back since no one uses aac all that much 19.14.18 # AAC-HE seems to be pretty popular for audiobooks performing pretty well at low bitrates. 19.14.31 # * LambdaCalculus37 sees that the nano3G and the Classic1G are not quite as similar hardware-wise as he was initially thinking 19.15.11 # LambdaCalculus37: different PMU, different codec, different RAM 19.15.20 # apart from that, they should be fairly similar 19.15.24 # TheSeven: Yup. 19.15.40 # yeah, i'm just really hesitant to create yet another 'almost but not quite right' mpeg implementation 19.17.02 Join DerPapst1 [0] (~Alexander@91-66-226-46-dynip.superkabel.de) 19.17.04 Join towolf [0] (~towolf@f051180146.adsl.alicedsl.de) 19.17.22 # TheSeven: And I also know that emBIOS doesn't work on the nano3G as well. 19.17.36 # which is due to the PMU and RAM 19.17.57 # and some differences in the GPIO setup 19.18.04 Join LambdaCalculus38 [0] (~3f74f70d@giant.haxx.se) 19.18.28 # don't know if anyone else found this or not yet, but my rockbox article in Linux Journal is now publically available : http://www.linuxjournal.com/article/10835 19.18.38 Quit LambdaCalculus38 (Client Quit) 19.18.43 # increasingly inaccurate as time passes of course ;) 19.18.55 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 19.19.11 # GodEater: this means you should update the wiki :) 19.19.11 # GodEater: nice 19.19.19 # which page gevaerts ? 19.19.22 # GodEater: But still an excellent article all the same. :) 19.19.29 # i might be missing something, recording from mic on sansa clipv2. i cranked the gain up to the maximum, and the audio clips like crazy, but the sample values in the written wave only go up to 0.25 of the full range. 19.19.30 # GodEater: ArticlesAboutRockbox 19.19.45 # ah 19.19.48 # I'll go do that 19.19.50 # i was thinking something like that for the IEEE student magazine might be nice, they've done them in the past on open source firmware for cameras, and IEEE readers are quite likely to be interested in firmware hacking verses normal people 19.20.14 # towolf: 14 bit ADC would be my guess 19.21.01 # saratoga, so 2 bits of headroom are lost? is this normal? 19.21.23 # towolf: you mean compared to a 16 bit ADC? 19.21.48 # ... that these little devices don't record at full level 19.21.55 # TheSeven: The only other DAP I saw in this store was a nano5G, but I know that's totally out of the loop right now. Not a shred of custom code for it. 19.21.56 # s/level/bit depth 19.23.18 # towolf: we should probably automatically increase the volume of the output file by 2 bits, but otherwise yes thats normal 19.24.00 # * GodEater updates said page. 19.24.26 # saratoga, ok, thank you. i was wondering about this. who knew that lower bit depth would manifest in lower volume. but it makes sense. once normalized it will have reduces resolution. 19.25.02 # * LambdaCalculus37 has LCD type 1 on his Classic according to the View HW Info screen 19.25.04 Join Topy44 [0] (~Topy44@f048064109.adsl.alicedsl.de) 19.25.32 # LambdaCalculus37: so it works right? 19.25.42 Join Buschel [0] (~chatzilla@p54A3AA92.dip.t-dialin.net) 19.25.42 # TheSeven: Like a charm. 19.26.00 Quit MethoS- (Remote host closed the connection) 19.26.21 # TheSeven: CPU freq is always at 216MHz and is stuck at 100% boost at all times. 19.26.37 # yes, there is no clock scaling driver yet 19.29.37 # saratoga: you saw my comment in FS#11858? 19.29.43 Quit LambdaCalculus37 (Quit: back to work) 19.29.51 # gevaerts: What would be involved to make the sql api open to lua 19.30.22 # sbmull: no idea. I've never done any lua work... 19.31.02 # linuxstb: turns out that the actual /lib/cpp symlink isn't needed and the g++ package doesn't create it on cygwin it was just that the error message was a bit unhelpful 19.31.44 # g++ (or some other c++) compiler seems to be required though 19.32.35 # gevaerts: This was my first lua work. 19.33.41 # gevaerts: I was suprised how easy it was. Faster to test and bug than c too. 19.34.51 # hm, one issue with the tone control is probably the corner frequencies for bass/treble 19.35.02 # bass is at 50Hz, treble at 5kHz, which is probably both too low 19.35.43 Join Rob2222 [0] (~Miranda@p4FFF150C.dip.t-dialin.net) 19.36.53 Join kugel [0] (~kugel@rockbox/developer/kugel) 19.37.52 Quit towolf (Quit: Ex-Chat) 19.38.45 Quit sbmull (Quit: CGI:IRC) 19.42.43 # for the record, if you want to get in touch with Zagor and he's not here, he's generally available by email 19.45.40 # New commit by 03gevaerts (r28993): Add some app_*() wrappers for file IO functions to make app_ work the same as sim_, thereby fixing application builds 19.45.55 # kugel: can you check if I didn't break android (more)? 19.47.27 Quit AlexP (Remote host closed the connection) 19.47.44 # you broke android? 19.47.54 # like, the whole thing? 19.47.57 Quit krabador (Ping timeout: 260 seconds) 19.47.58 # * GodEater is impressed 19.48.07 # :) 19.48.09 # r28993 build result: All green 19.48.28 # I know you're not a huge fan of it - but that seems an extreme reaction 19.49.19 # I just want to make sure I *didn't* break it! 19.49.38 # you said "(more)" - which I took to me, I broke it a bit already 19.49.44 # s/me,/mean 19.50.39 # * GodEater fears that with the ambiguousness of this statement, he may have just opened a semantic can of worms with gevaerts 19.50.59 # * TheSeven shoves that discussion to #rockbox-community 19.51.04 Join AlexP [0] (~alex@rockbox/staff/AlexP) 19.51.40 # thanks TheSeven ;) 19.53.37 # can we use aliases (instead of wrappers) for library functions? 19.54.28 # hm, yes 19.55.39 # soap: you experienced the playback/buffer issue again? 19.56.18 # soap: ...or even found a way to reproduce it? 19.58.40 # kugel: the only problem is that I keep getting confused by function pointer syntax 20.00.14 # :? 20.00.58 # kugel: feel free to have a go 20.01.25 Join krabador [0] (~krabador@host185-20-dynamic.251-95-r.retail.telecomitalia.it) 20.01.57 # Buschel: i did but was a little confused, has anything even changed between those revisions? 20.02.53 # amee2k: you should be able to build again 20.03.25 # saratoga: yes, r28937 changed some error handling in apps/metadat/rm.c 20.04.15 Quit factor (Read error: Connection reset by peer) 20.04.36 # saratoga: rolling back this change does not seem to be the best solution as this change was made to fix a ticket (by you) regarding a crash in the database parser 20.06.16 Join factor [0] (~factor@75.108.68.114) 20.06.24 # <[Saint]> gevaerts: Does the claim of App-fixedness extend to CygWin? 20.06.47 # [Saint]: there shouldn't have been anything cygwin-specific about this 20.06.55 # <[Saint]> awesome. 20.06.58 # <[Saint]> thanks. 20.08.15 # [Saint]: sorry to bother you again -> was the tearing on you iPod color LCD introduced by my latest changes? or was it the same before? 20.14.34 Join towolf [0] (~towolf@f051180146.adsl.alicedsl.de) 20.14.36 Quit AlexP (Remote host closed the connection) 20.15.00 # <[Saint]> I will find the time to go through the revisions and check which (if any) patch introduces the tearing this afternoon. 20.15.07 Quit stoffel (Ping timeout: 264 seconds) 20.15.27 # <[Saint]> I have a fairly busy day, but I can get this done for you...I know you're wanting to commit these things. 20.15.31 # <[Saint]> Buschel: ^ 20.16.09 # [Saint]: it has been committed already. you've mentioned this tearing some days ago (when CPU is boosted) 20.16.10 # saratoga, regarding the 14-bit to 16-bit issue. do i understand right that i just need to bit-shift by 2? are you aware of any tools that do this? 20.16.59 # <[Saint]> Buschel: Um...what has been committed already? 20.17.05 # <[Saint]> and, when? 20.17.37 # [Saint]: all available LCD optimizations (except some YUV stuff which is not relevant for the tearing you described) 20.17.53 # i further assume that a standard normalization would achieve almost the same thing but would introduce minor rounding errors? so a bit-shift would be simpler and cleaner? 20.18.55 # * [Saint] wonders why he didn't get any conflicts when he updated his SVN checkout. 20.19.11 # [Saint]: maybe because the changes were identical 20.19.23 # <[Saint]> Ah, possibly. 20.19.30 # towolf: is the quality of that microphone really good enough for these possible rounding errors to matter? 20.20.54 # gevaerts, not really, but in normalization it maximizes according to the single maximum peak sample 20.21.42 # that is probably the main issue. i just need to multiply the sample values by 4. as far as i understood things correctly. right? 20.22.07 # Buschel: i don't see how that change breaks anything though? 20.22.21 # yes 20.22.30 Quit t0rc (Remote host closed the connection) 20.22.47 # any linux tools that do this? 20.23.24 # * TheSeven wonders what the hell is going on with tone control 20.25.14 # saratoga: I have build a simulation with rm.c at r28936 and at r28937. it made the difference 20.25.42 # saratoga: you have seen mt lately? 20.26.29 *** Saving seen data "./dancer.seen" 20.27.15 # i'll IM him 20.27.26 # ok 20.28.14 # which corner frequencies would you recommend? 20.28.20 # bass: 50/100/200/250Hz 20.28.33 # treble: 5/6/10/15kHz 20.28.43 # er, 5/7/10/15 20.28.47 # Buschel: i don't have the sim handy right now, but if you want you could try changin gthe line to "if(temp < 0 || skipped < 0)" instead of "if(temp < 0)" 20.28.49 Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) 20.29.01 # thats the only thing i see that might make a difference 20.29.18 # actually i'd like this to be configurable but I don't think we have settingss for that right now 20.29.21 # settings* 20.29.41 # what order of magnitude of values are we using on other targets? 20.30.08 # [Saint], gevaerts: the app build on cygwin or mingw had a different problem before, so I guess it's back to that one now (haven't tried yet though) 20.30.23 # What program would you recommend to inspect metadata in mp3? And BTW. how is replaygain handled from the point of mp3 file? Should the file have some special tags? 20.30.43 # wodz: it has an id3v2 tag for replaygain 20.30.59 # to look at metadata i usually just use foobar2000 on windows or ffmpeg on linux 20.31.11 # <[Saint]> pixelma: I'm building now...fingers crossed. 20.31.24 # saratoga, thx 20.31.29 # <[Saint]> I'll have to leave before it finished though, so results will be delayed somewhat. 20.31.49 # [Saint]: the error appeared when building the exe, so near the end 20.32.01 # saratoga: will do in a few minutes 20.32.02 # <[Saint]> yes, I remember this also. 20.32.27 # <[Saint]> pixelma: I guess I'll just hope that it magically fixes itself. 20.32.33 # TheSeven: why not make it configurable? 20.32.44 # Buschel: actually i can test on device, i'll look and see if anything is obviously wrong 20.32.53 # I'll try cross-compiling in my VM now 20.33.00 Quit towolf (Quit: Ex-Chat) 20.33.03 # n1s: do we have the framework for that? 20.33.12 # TheSeven: oh, missed you said that, the beast has a hw eq 20.33.12 # i don't really want to dig into the settings engine right now 20.33.52 # the beast hw eq menu is in menus/audiohw_eq_menu.c 20.33.58 # saratoga: could you give me some hint? ffmpeg man page is rather big and video oriented 20.34.48 # hmm, not a great fit if i understand the capablities of your codec 20.35.48 # i can basically set the corner frequency and gain of a bass and a treble shelving filter 20.35.48 # TheSeven: are those frequencies cutoff freqs for bass and treble filters? 20.35.58 # ah, ok 20.36.22 # so just popping in 2 extra settings for that would be simpler i think 20.36.23 # the gain is handled in a sensible way already, just not the corner frequency 20.36.46 # the problem with this is that those settings have non-linearly distributed target-dependent values 20.37.02 # yes 20.37.13 # what would you recommend as default values for them? 20.37.15 # wodz: i think it prints the metadata if you do ffmpeg -i file.mp3 out.wav 20.37.31 # thats all i ever do with it, if you need something more then that i'm not sure 20.37.33 # i would just hardwire that for now until someone thinks about a way to add a setting for it 20.38.53 Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) 20.39.19 # saratoga, http://www.pastie.org/1438102 <- I don't see any meta data in this output 20.39.36 # TheSeven: the sw eq uses 80Hz and 5.3kHz as defaults so something close to them maybe 20.40.10 Join sideral [0] (~sideral@unaffiliated/sideral) 20.43.09 # wodz: for me it prints below "Stream #0.0: Audio:" 20.43.18 # maybe the file has no valid metadata? 20.43.57 # it has 20.44.04 # then i'm not sure 20.44.22 # Buschel: trying those tracks they don't even hit the code path 20.44.26 # http://www.pastie.org/1438122 20.45.13 # saratoga: seems we're somehow not on the same page... 20.45.30 # i used cook 64 mono and stereo 20.45.34 # is that the right files? 20.46.01 # saratoga: commenting line 382 (="return -1;") does the trick. 20.46.36 # do you use the same revision of rm.c? 20.48.24 # no its an older check out, but its the one i used to commit the rm.c changes int he first place, so it should be fine i think 20.48.26 # i can try updating 20.48.51 # hmm actually i probably shouldn't since this check out has all my libmad work in it 20.49.39 # saratoga: mt submitted a fix after yours. the patch to fix the svn issue is this -> http://pastie.org/1438143 20.49.39 # what i don't understand is that the only way that -1 can ever be hit is if the file doesn't have a recognized FOURCC or if the extradata length is negative 20.49.47 # (which is more or less reverting mt's change) 20.49.56 Quit factor (Ping timeout: 264 seconds) 20.50.29 # what is the "Unknown header signature " it prints? 20.50.39 # "" 20.50.48 # huh 20.50.53 # so the file has no fourcc 20.51.07 # i would assume that means its corrupt, but evidently not if we used to play it 20.51.57 Join thegeek_ [0] (~nnscript@132.108.34.95.customer.cdi.no) 20.52.10 Join afk [0] (~Dre@92.30.156.129) 20.52.31 Quit scorche (Disconnected by services) 20.52.41 Join scorche` [0] (~scorche@rockbox/administrator/scorche) 20.52.59 Join AlexP [0] (~alex@rockbox/staff/AlexP) 20.53.42 Join factor [0] (~factor@75.108.68.114) 20.55.15 Quit Dreamxtreme (Ping timeout: 255 seconds) 20.55.43 Quit thegeek (Ping timeout: 255 seconds) 21.00.10 # hmm, in fact the "" comes from the (buggy) fourcc2str-conversion. 21.00.33 Join TheLemonMan [0] (~lem0n@ppp-86-135.98-62.inwind.it) 21.01.07 Nick AlexP is now known as AlexP_ (~alex@rockbox/staff/AlexP) 21.01.10 Nick AlexP_ is now known as AlexP (~alex@rockbox/staff/AlexP) 21.02.39 # so, the "make" for a cross-compiled app build seems to work now and I thought that I need to do a "make install" then, or do I miss something? 21.03.39 # "make install" failed for me because it uses a wrong dir it seems 21.05.02 # * Buschel 's iPod Video again hung up during playback using plain r28992 21.06.21 # <[Saint]> pixelma: "make && make install" should be all that is needed IIUC 21.08.51 Join skx [0] (~skx@unaffiliated/skx) 21.08.59 # hello 21.09.18 # <[Saint]> pixelma: What OS are you building in atm? 21.09.26 # make install wants to install the build in my "/usr/local" dir which it isn't allowed to and I think it won't find the things needed 21.09.49 # [Saint]: linux VM but I chose to cross-compile for Windows 21.10.32 # <[Saint]> pixelma: I'm getting failuers with speex on CygWin...if you can, it would be nice if you could check out building voice with speex on CygWin. 21.10.42 # <[Saint]> No rush, but, I would appreciate it. 21.11.45 # I already told you that it works for me, despite a warning that it couldn't find some package (would need to look it up which exactly it was but you could find it in the logs here) 21.13.01 # <[Saint]> I'm getting a bunch of: librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x453): undefined reference to `_speex_nb_mode' etc. 21.13.04 Part jhMikeS 21.13.04 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 21.13.21 Join LambdaCalculus37 [0] (~3f74f70d@rockbox/staff/LambdaCalculus37) 21.13.34 # <[Saint]> No idea why, it's quite annoying. But at least I know it's a problem on my end. 21.13.39 # B4gder: Can you update the front page? 21.13.42 # I successfully built an M5 voice 21.13.46 Quit jhMikeS () 21.13.54 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 21.14.59 Quit LambdaCalculus37 (Client Quit) 21.16.46 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 21.17.34 # pixelma: I think I've mentioned it before but the sdl app most likely won't work on windows without further work 21.18.33 # I'm using the Rockbox Utility on Ubuntu 10.10 and the autodetect doesn't work, I have provided it both with the mountpoint (/media/SANSA CLIP) and the device (/dev/sdb) and it doesn't detect my player, shoudl I be worried? 21.18.44 # how reliable is autodetect usually? 21.19.07 # kugel: I remember you saying "no-one tried", so I wanted to 21.19.25 # <[Saint]> that's all I remember also 21.19.39 # still curious what the cross-compile want to do with the "usr/local" dir 21.19.43 # <[Saint]> I wouldn't have bothered had I known there was no point... 21.20.48 # it might work under cygwin 21.20.51 # skx: I remember having seen the same behavior for my ClipV2. Just manually select the right Clip version. 21.20.59 # sideral, ok, thanks 21.21.13 # Perhaps the autodetect code cannot discern between a Clip and a ClipV2 and so defaults to detect nothing? 21.21.33 # (just a wild guess, I haven't looked at the code) 21.21.36 # it's v02 for sure (according to the system info on the player) 21.21.39 # New commit by 03alle (r28994): pitch_detector: the menu function already returns a bool, so use the return value directly 21.22.10 # saratoga: hmm, in fact the parser detects "FOURCC('M','D','P','R')" 2 times in the stream. the first time a correct ".ra" is recognized, the second time not -> abort 21.22.40 # that makes more sense then 21.22.44 # i guess we need to ask mt what to do 21.23.37 # New commit by 03alle (r28995): pitch_detector: remove a double 'break' 21.23.45 Join factor_ [0] (~factor@75.108.68.114) 21.23.52 # r28994 build result: All green 21.24.15 # The Clipv1 and the Clipv2 have different USB ids, so it should be possible to distinguish them by that 21.24.19 Quit factor (Read error: Connection reset by peer) 21.24.21 # sideral, skx: the Rockbox Utility uses the USB PIDs and VIDs as listed on http://www.rockbox.org/wiki/DeviceDetection#USB_IDs - the page doesn't list ones for the Clipv2 so maybe this is not prepared for the Utility yet? 21.24.48 # according to the manual for Clip v2 automatic installation should work 21.24.57 # That would explain it. But I did install Rockbox with the utility 21.25.03 # it's the recommended path 21.25.40 # I'll check in the code 21.26.40 # r28995 build result: All green 21.28.14 Join perfectdrug [0] (~marko@p54B3EB11.dip.t-dialin.net) 21.29.48 # the usb ids for both the clipv1 and the clipv2 have been in the code since SVN r25324 (March 24, 2010) 21.31.02 Quit Buschel (Read error: Connection reset by peer) 21.32.38 Join Buschel [0] (~chatzilla@p54A3AA92.dip.t-dialin.net) 21.33.58 # wow, that was a breeze, I mean... it just worked 21.34.39 # <[Saint]> what did you expect? ;) 21.34.53 # [Saint], 2 hours of configuration 21.34.55 # tbh L:) 21.36.23 # it's excellent, thanks for this and for the rockbox utility 21.36.28 Part skx 21.40.38 Quit saratoga (Quit: Page closed) 21.40.39 # New commit by 03jethead71 (r28996): Gigabeat S/i.MX31: Take care of an interrupt priority inversion that can happen during PCM callback lockout when DVFS switches frequecies during the ... 21.42.57 # r28996 build result: All green 21.47.15 Join skx [0] (~skx@unaffiliated/skx) 21.51.19 Part skx 21.53.38 # New commit by 03alle (r28997): Rockbox Utility: update the Russian translation (FS#11861 by Simon Zhukovsky with minor tweaks by me) 21.53.44 # what the hell. 21.54.29 # even if i make the audiohw_set_bass/treble functions do nothing, the volume increases greatly when increasing the bass/treble value in the sound settings menu above 0dB 21.54.54 # <[Saint]> ?!? 21.55.31 # saratoga: updated FS#11858 21.55.32 # sounds logical 21.55.44 # why on earth? 21.55.59 # r28997 build result: All green 21.56.00 # <[Saint]> One word: "Apple" 21.56.39 # TheSeven: is the software bass/treble running? 21.56.45 # no idea 21.57.05 # even if it would be, that kind of thing certainly shouldn't happen 21.57.45 # near 0db it works by making all other frequencies quiter, to avoid clipping 21.57.51 # TheSeven: I'd expect it to get quieter or not change at all 21.57.57 # can r28877 lead to lockups on dual core engines? 21.58.24 # (if you raise bass/treble, that is) 21.59.12 # oh, I think I know what might be going on 21.59.33 # i have 1.5dB gain steps for that 21.59.35 # Buschel: I would be very surprised it it would 21.59.59 # and if i go to +1.5dB, it sounds like the volume went up by 15dB 22.00.07 # aha 22.00.08 # ?? 22.00.09 # is there something ignoring num_decimals? 22.00.25 # and thus over-compensating by a factor of 9? 22.00.25 Join leavittx [0] (~lev@ip-83-149-1-210.nwgsm.ru) 22.01.40 # you need the unscaled current_bass, current_treble 22.02.11 # if you're modelling this after gigabeat F's way 22.02.18 # how does this work with hardware bass/treble? 22.02.35 # are things attenuated in software to prevent clipping in the codec's DSP? 22.02.54 # it's in tenth-db's already, so the anti-clipping attenuation doesn't need the "*10" 22.03.05 # TheSeven: indeed 22.03.18 # sort of 22.03.45 # if the hardware can prescale the volume somehow, the hw does it. if it's SW tone controls, the DSP does it 22.03.52 # hm, i should probably implement hardware pre-cut then 22.04.47 # it scales the volume down by the band with the highest posive gain, or else leaves it alone if none have + gain 22.05.05 # jhMikeS: any idea what could cause FS#11863 ? this definately came in before the ATA changes 22.06.13 # jhMikeS: so it basically scales it down in pre-cut, then applies bass/treble, and then scales it up again in the amp 22.06.36 # (and scales it up by an order of magnitude too much on the classic) 22.06.46 # is that upscaling also effective for lineout? 22.07.28 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 22.08.09 # TheSeven: it should be effective but I suppose that depends on the codec itself and its setup 22.08.42 # i've seen a bunch of hardwared 0dB's for lineout in sound.c, which will probably interfere with that 22.08.44 # Buschel: I haven't seen any issues myself on my targets. 22.09.37 # TheSeven: on the targets I implemented, I used DAC volume as a precut which doesn't affect any analog stuff. I don't know if you can do that there. 22.10.08 # i can actually do that in two places 22.10.25 Join max131 [0] (~51f01a14@giant.haxx.se) 22.10.27 # Buschel: I'll think about it but nothing obvious strikes me 22.10.37 # there's a prescaler in the dsp, and another one after the mixer, before the tone control 22.10.54 # http://www.cirrus.com/en/pubs/proDatasheet/CS42L55_F1.pdf page 26 22.11.13 # jhMikeS: that would be helpful. maybe you get an idea... 22.11.45 # Buschel: They mention mpegplayer which shouldn't be affected by priority changes by the pcm buffer that don't happen when it's running 22.11.51 # i'll probably use MSTxVOL for that, so that one can apply a pre-cut even if the DSP is powered off 22.13.23 # jhMikeS: also test_codec did not load today when I experienced this. there is no clear image about what is happening in detail... 22.15.02 # so i suffered from an fs-corruption again during past day, and i'm running r28979 now 22.15.09 # jhMikeS: for now it did only happen for soap (iPod nano 1g) and me (iPod Video). I did not happen on my iPod nano 2g yet. that's why I am guessing it might be connected to dualcore. or maybe some ATA DMA stuff 22.15.34 # that's on a fuze-v1, anybody else seeing this issue occasionally? 22.16.26 # front page updated 22.16.47 # TheSeven: PMIXxVOL? 22.18.27 # i'd like to help and pinpoint where the problem is, but i'm not a coder, and i would like to get the fuze more stable 22.18.33 # that's only available if the DSP is powered on and has a smaller range 22.18.46 # and from a clipping point of view MSTxVOL is early enough 22.19.19 # and, as the tone controls are effective for all signal sources, i'd say the precut should be as well 22.19.59 # i thought the whole issue started with r28834, but apparently the fs-corruption re-occured this morning, after having the storage formatted using the original firmware 22.20.35 # Buschel: I've played my H10, e200 and 3g without issues 22.21.37 # jhMikeS: it happens randomly. just let the devices play and leave them alone for a while 22.22.24 # hmmm...I was listening to e200 last night for several hours...I'll try though. Which one do you prefer of those I test? 22.22.53 # interesting. which build did you use? 22.25.20 # so i guess there still must be a problem in the USB or block layer in rockbox, or what else could cause a 'delayed write failed'? 22.26.33 *** Saving seen data "./dancer.seen" 22.26.38 # jhMikeS: btw, I would prefer if you take the H10. the issue might be connected to ATA DMA stuff which is not enabled on e200 and 3g 22.26.45 # max131: I'd say the sd driver 22.27.05 # Although usb isn't impossible 22.27.49 # Buschel: r28976 22.28.16 # pretty up-to-date 22.28.24 # is there maybe an easy way to trace back and see when the last change to the sd driver was made? 22.28.34 Join fml [0] (~chatzilla@manz-590f1010.pool.mediaWays.net) 22.28.35 # sound.c:199 looks like an apparent bug 22.29.16 # gevaerts: many kudos for fixing plugins.c. You did it in a much simpler and elegant way than I would have done it! 22.29.55 Quit factor_ (Read error: Connection reset by peer) 22.30.01 # fml: I'm still thinking the whole thing ought to be done in a simpler way, but this was the simplest change on its own I think 22.30.14 Join factor [0] (~factor@75.108.68.114) 22.30.52 # gevaerts: yes, if all would be done correctly and consistently from the beginning, the fix wouldn't be needed at all 22.31.05 # gevaerts: is it sd-as3525.c that you are talking about? 22.31.28 # * TheSeven considers sound.c an awful unflexible ifdef hell 22.31.35 # max131: probably. I personally never worked on the AMS players though, so I can't really help much 22.31.51 # TheSeven: That's line is certainly odd to look at 22.31.58 # gevaerts: who should i try and contact then? 22.32.22 # jhMikeS: i missed a set of parantheses when looking at it for the first time 22.32.26 # max131: svn log on that file should tell you :) 22.32.33 # didn't wodz work on sound.c cleanup? 22.32.58 Quit fml (Client Quit) 22.33.09 # New commit by 03wodz (r28998): HD300 - calibrate discharge curve 22.33.25 # "The codecs listed use HW tone controls but don't have suitable prescaler functionality, so we let the prescaler stay at 0 for these, unless SW tone controls are in use. This is to avoid needing the SW DSP just for the prescaling." - now what the hell is that meant to tell me? 22.34.12 # it doesn't seem to match the code on the first glance, as it's an exclusion, not inclusion, list 22.34.40 # gevaerts: ok, thanks 22.35.08 # do codecs that use hardware tone controls define HAVE_SW_TONE_CONTROLS? 22.35.19 # apparently they do, judging from that code 22.35.25 # r28998 build result: All green 22.37.15 # TheSeven: I'm not sure what this "suitable prescaler functionality" is. Sometimes it needs to be manually calculated but the hw can still prescale. 22.40.06 # ex: if wm8721 has tone controls off, then it shouldn't call prescaler code, since it doesn't need it without tone controls 22.40.23 # it doesn't have it's own anyway 22.41.55 Quit advcomp2019_ (Quit: IRC is just multiplayer notepad) 22.42.33 # sound.c is messy :\ 22.44.15 # hi! i run a simulator of cowon d2 (also tried x5 - same thing) and get segfault when i choose for example plugins->games->xobox and then Properties. this is strace output: http://ompldr.org/vNnZ6ag 22.48.50 # wodz: you may be interested in http://www.rockbox.org/tracker/task/11796 22.49.42 Quit krabador (Quit: Sto andando via) 22.50.40 # perfectdrug: awesome 22.51.12 # :) 22.51.57 # the hard work was already done otherwise I wouldn't have had the time for it 22.54.35 # anyone familiar with perl and rbclient.pl can have a look at http://pastebin.com/eg1rkwjW? 22.54.51 # what generally could be a reason of simulator segfault? 22.55.23 # gdb will tell you :) 22.57.16 # what could cause this? 22.57.19 # /data/rockbox-trunk/apps/settings_list.c:1423: error: âLANG_BASS_CUTOFFâ undeclared here (not in a function) 22.57.27 # New commit by 03wodz (r28999): Add thumbnail for HD300 22.58.14 # TheSeven: this string is not defined in lang file for this target 22.58.23 # yeah, but why? 22.59.15 # * bluebrother wonders if he should just commit this. But: do I need to update the revision number? 22.59.32 # B4gder: ping 22.59.39 # That string might not be using features properly 22.59.50 # TheSeven: i don't believe that only i have this segfault... at least my friend have it too 22.59.53 # I'm here 23.00.41 # nope, only defined for ipodvideo 23.00.44 # B4gder: May I ask for www update? 23.00.45 # bluebrother: that's probably best 23.00.53 # jhMikeS: where do i need to change that? 23.00.57 # B4gder: do I need to change the revision number when changing rbclient.pl to fix cpu core number detection on OS X? 23.01.01 # apps/lang/english.lang 23.01.10 # B4gder: do you happen to know where Zagor is hiding or when he'll be back? 23.01.13 # wodz: sure, done! 23.01.17 # B4gder: I just commited thumbnail for HD300 (thanks to perfectdrug's work) 23.01.21 # (see http://pastebin.com/eg1rkwjW -- any comments on that? I'm not that much familiar with perl, but it works for me :) 23.01.27 # bluebrother: if you don't change it, existing clients can't be told to upgrade 23.01.31 # bluebrother: if you want all clients to upgrade, then yes 23.01.56 # B4gder: thx 23.01.56 Quit max131 (Quit: CGI:IRC (EOF)) 23.02.13 # gevaerts: sure, but do I want that? It's only relevant for OS X, and since the number of cores gets reported as 0 right now on OS X it doesn't work anyway. 23.02.19 # TheSeven: yes I do know where he is physically but I can't tell when he'll be around in here 23.02.44 # TheSeven: or apps/features.txt if you want fix the feature part 23.02.48 # hmm, maybe it's best to bump the revision number, wait for clients to update and see if I brok the build system :) 23.02.55 # s/or/and 23.03.00 # wodz: thanks ( B4gder too) do you commit the manual part aswell? 23.03.39 # perfectdrug: When I start work on manual for HD300 I'll commit this 23.03.55 Quit factor (Read error: Connection reset by peer) 23.04.08 # great 23.04.24 Join factor [0] (~factor@75.108.68.114) 23.04.26 # B4gder: any concerns about the rbclient.pl change? 23.04.43 # I haven't looked at it, I'm a bit busy elsewhere atm 23.04.46 Quit Xerion (Quit: ) 23.05.39 # jhMikeS: should I just duplicate that line? 23.08.40 Quit captainkewll (Quit: Page closed) 23.12.28 # hmm, if I want the build clients to update I also need to bump $minimumversion in rbmaster.pl, right? 23.13.38 # Yes. I'm not sure if it's a good idea for anyone but a server admin to actually do that though 23.14.09 # hmm. I guess I'll keep the current revision number then. 23.14.50 # since that change isn't required by any client running on linux. And anyone setting up a client on OS X should (hopefully) get the most recent scripts from SVN anyway. 23.16.48 # jhMikeS: a question -> what happens if the codec thread gets higher priority as the buffering thread, if rebuffering is occuring? 23.18.31 Quit Keripo (Quit: Leaving.) 23.18.37 # Buschel: It would cause codec to be preferred over buffering if both have to run, but if the codec is waiting for buffering, the buffering thread will run 23.21.15 Quit perfectdrug (Quit: Leaving.) 23.22.00 # it would only be a problem if the codec can't regain ground and fill the PCM buffer. if it can't, then CPU resources are being overtapped 23.22.24 Quit wodz (Quit: Leaving) 23.23.03 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 23.25.22 Quit komputes (Remote host closed the connection) 23.26.22 # New commit by 03bluebrother (r29000): Make probecores work on OS X. ... 23.31.47 Join simonrvn_ [0] (simon@72.0.216.72) 23.32.35 Quit simonrvn (Ping timeout: 240 seconds) 23.32.35 Nick simonrvn_ is now known as simonrvn (simon@72.0.216.72) 23.45.12 # jhMikeS: hm, the prescaler thing doesn't seem to work quite right 23.45.21 # starting at bass +3dB i get quite noticable clipping 23.45.39 # the overall volume is constant now though 23.49.19 # if i don't offer a hw prescaler, things seem to be a bit better, but there's still noticable clipping at +6dB 23.51.41 # I'd be hard pressed to know why for your codec, I've only integrated that for wolfons. double-check scaling of db units? 23.52.29 Quit kugel (Remote host closed the connection) 23.52.46 Quit Buschel (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]) 23.57.31 # jhMikeS: is my assumption correct, that it *will* use the software DSP, even if it needs it just for precut gain? (in contrast to the comment, which seems to be referring to compiling it in, not using it) 23.58.58 Quit kadoban (Read error: Operation timed out)