--- Log for 25.04.110 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 27 days and 5 hours ago 00.01.26 Quit DerPapst (Quit: Leaving.) 00.01.48 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 00.03.43 Join archivator [0] (~archivato@stu0279.keble.ox.ac.uk) 00.04.49 Quit anewuser (Quit: http://xrl.us/NitroQueer What do you know...THE WORLD'S first NTRQ (that's for NES/FAMICOM) tracking compo. Have powerpak? Try it out! Otherwise ROM IMAGE.) 00.08.30 Quit xavieran (Ping timeout: 258 seconds) 00.21.35 Quit merbanan (Ping timeout: 240 seconds) 00.28.08 Quit pamaury (Quit: Page closed) 00.32.50 Quit archivator (Quit: Leaving) 00.33.07 Quit ved (Quit: Changing server) 00.44.52 Join __arbingordon [0] (~w@c-68-44-148-113.hsd1.pa.comcast.net) 00.45.39 Join ved [0] (ved@ddsbox.co.cc) 00.46.04 Nick __arbingordon is now known as arbingordon (~w@c-68-44-148-113.hsd1.pa.comcast.net) 00.46.11 Quit arbingordon (Changing host) 00.46.11 Join arbingordon [0] (~w@unaffiliated/arbingordon) 00.47.05 Quit _arbingordon (Ping timeout: 240 seconds) 00.54.32 Quit n17ikh (Ping timeout: 245 seconds) 01.00.36 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 01.13.10 *** Saving seen data "./dancer.seen" 01.15.39 Quit ender` (Quit: I don't see what C++ has to do with keeping people from shooting themselves in the foot. C++ will happily load the gun, offer you a drink to steady your nerves, and help you aim. -- Peter da Silva) 01.28.56 Quit antaw (Quit: Verlassend) 01.37.20 Quit mirak_ (Quit: Ex-Chat) 01.38.05 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 01.51.56 Join saratoga [0] (~463f90ed@gateway/web/freenode/x-dcnfolmzumtgomru) 01.53.01 Quit DataGhost (Ping timeout: 264 seconds) 01.54.29 # Unhelpful: (for the logs) you might be interested in FS#11216 01.55.20 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 01.55.54 # great timing 02.06.42 # Unhelpful: i skimmed FS#11216 but don't really know enough to have an opinion 02.20.39 Quit bertrik (Quit: De groeten) 02.25.52 # * Strife89 will test on his devices. 02.35.01 # Doesn't look like it was made right, though. 02.35.10 Quit kadoban (Remote host closed the connection) 02.35.14 # That or a recent change messed up a file location. 02.45.42 Join kugel [0] (~kugel@rockbox/developer/kugel) 02.46.21 # My Fuze's battery is dead. :/ 02.50.24 # saratoga: it's not the right way if you ask me# 02.51.07 # I mean, I only looked at the patch quickly (not throughoutly) but it seems it could be done better 02.51.41 # holy crow, what did they do to my loader?! (and i've only looked at the diffstat thus far) 02.52.49 # what's this stuff in codec_get_buffer? why should anything in codec_thread need to be touched? 02.53.46 # Unhelpful: please bear with him, at times some of your optimisations are strange to look at for others 02.53.48 # i think he puts the image on the codec buffer 02.54.20 # kugel: i'm just not clear on why this should need *huge* changes in the loader. 02.54.40 # you should be able to do this with a very *small* change by hooking the getc implementation. 02.54.42 # right, that's most definitely happening, which seems strange as the actual image is already loaded as part of buffering the whole file 02.55.03 # saratoga: ^ 02.55.50 # isn't because of the stupid desynchronization stuff in ID3v2? 02.55.58 # I also find the memcmp's strange (i.e. I would use str*cmp) but that's probably minor given the scope of the patch 02.56.32 # unless id3 tags aren't \0-terminated 02.57.21 # kugel: the one i'm looking at appears to be against *part* of a string... is there a str*cmp for substrings? 02.58.06 Join anewuser [0] (anewuser@unaffiliated/anewuser) 02.58.25 # I think we should have a talk with uchida about the patch, once we get to catch him in irc... 02.59.53 # as of now, I'm *pretty* happy with how rb handles albumart which is perfectly reasonable for embedded devices as long as suitable tools exist, so I'm not really happy with accepting a hacked together solution 03.00.32 # otoh I cannot really determine how hacky it really is, but it seems hacky in some places (especially the codec buffer thing) 03.01.03 # saratoga: my idea for handling tag images was something along the lines of passing the loader an alternate getc implementation - this could read in the data and do whatever transformation needs to be done, seeking past non-image data, desync, base64 decode (for some tag types) 03.01.49 # this would load it into the audio buffer? 03.01.53 # or perhaps we could make this more optimal by hooking *below* getc with a read function... make the buffer big enough, and the cost of the call-via-pointer on read gets tiny. 03.02.17 # imo it ought to load as-needed into a small chunk of buffer, as the current reader does. 03.02.35 # the call-via-pointer thing is really overestimated 03.03.21 # we really should focus on clean and understandable code instead, otherwise we'll dig our own graveyard 03.03.25 # kugel: probably is, there is a *huge* amount of stuff going on here besides getc 03.04.49 # even if your function consists of 10 or more instructions, the pro- and epilog is already neglible 03.05.00 # most of the time 03.05.32 # the other option is increasing our bus factor 03.06.05 # (which is high enough in some areas if you ask me) 03.06.18 # i'm also *pretty* sure that getc is inlined right now. and that a read hook would not need to be so much worse. it would take a uintptr_t opaque argument in place of the file handle, and otherwise look like a "real" read. 03.07.47 # but the hook version would need to fill the buffer, and then transform it as needed. to my knowledge the transforms done on image data in tags are all expanding, so you should always be able to fit the decoded image data into the same space 03.09.34 # I'm pretty sure we can optimize later 03.10.34 Join Strife1989 [0] (~michael@adsl-80-185-188.mcn.bellsouth.net) 03.10.56 Quit Strife89 (Disconnected by services) 03.10.57 # we always can 03.11.01 Nick Strife1989 is now known as Strife89 (~michael@adsl-80-185-188.mcn.bellsouth.net) 03.11.46 # kugel: i also think this might be easier to implement. hooking at getc means that the hook also has to implement stuff that's in getc now - checking available buffer and advancing the pointer if not empty. also hooking read means that we don't have to worry at all about how getc changes impact ungetc. 03.13.13 *** Saving seen data "./dancer.seen" 03.13.31 # what about the general idea of reserving space for image loaders? it strikes me a bit that png is not supported 03.15.16 # ie 03.15.33 # i.e. handle them like codecs 03.15.40 # kugel: right now all image-loader code is hardcoded. i'm not sure how many image loaders we need before a loader loader becomes a good idea? 03.16.15 # well, there are two plugin image viewers not supported in the core 03.16.48 # png and ppm? i wouldn't worry about supporting ppm in core ;) 03.17.01 # I think it would be a better idea to invest a bit of ram usage for supporting them in the core, loading the decoders when needed 03.17.13 # *but* i can see some nice bonuses for loadable image codecs 03.18.15 # png is major enough to justify that idea IMO, but there's also gif potentially (or svg in an imagination) 03.18.30 # con: only one image load (via the core loader) can run at a time, image load always needs a disk spinup (shouldn't be a problem now, core only loads from disk) 03.19.01 # pros: image loader can have dedicated buffers, including iram on targets where that matters - big win on coldfire, probably 03.19.15 # I also cannot understand why we still only support bmp for .wps/.sbs, png would be a so much better choice 03.19.56 # Unhelpful: if you load an image, the disk spins up anyway, the actual decoder is neglible in that case 03.20.21 # Wouldn't png drastically increase the WPS load time? 03.20.32 # Especially on slower targets? 03.21.11 # I'm not sure about that. the major time for loading skins is spent in the storage drivers IIRC 03.21.32 # kugel: i addressed that, didn't i? ;) 03.22.44 # png decodes pretty fast, judging by the plugin. I'm sure that if we remove the (up/down)scaling it would be even faster for skins 03.23.22 # I'm just disputing the "so much better choice" aspect of it. 03.23.29 # It seems subjective, at best. 03.24.00 # until we messure it, it's pretty objective as I see it 03.24.07 # No, that's not how it works. 03.24.14 # Until we measure it, it's definitely subjective. 03.24.24 # Measurement is what creates an objective outcome. 03.24.29 # * Unhelpful can't really imagine that png would save so much for wps. 03.25.18 # issues with png for AA: antialiased PNG can't be scaled (reasonably) without decoding the whole image into memory 03.25.27 # s/anti//g ;) 03.25.29 # until we messure it we can only assume it's worse or the same w.r.t. to loading times. but we can only *assume*. the disk space saving is a fact though 03.26.17 # kugel: it's also fact that *some* more time will be spent decoding the images, the question is how much. 03.26.22 # And how badly it will affect what targets. 03.26.48 # but we cannot determine that until we messured 03.26.49 # So, as I said, currently anything is subjectivity. 03.26.59 # urgh. actually i mean, um, interlaced. i fail at language tonight. ;) 03.27.45 # "some" could very well mean *free* because the time is spend in the storage driver 03.27.47 # kugel: This may be a language issue - "objective" means based only on observable phenomenon - as long as you're assuming that the time won't be noticeable but haven't measured it yet, it's still subjective. 03.27.59 Quit StickleBricks (Quit: This now concludes our broadcast day.) 03.29.49 # anyway, if we support PNG loading, we have to also think about how often interlaced PNGs are going to come up, how hard it's going to be to explain to users why their AA won't load and how to fix it, and how much they'll still complain even though they can now load *some* PNGs instead of *none*. 03.30.06 # Unhelpful: Don't we have that problem with .jpg now anyway? 03.30.12 # don't we already support only 1 type of jpeg? 03.30.44 # Or are interlaced pngs more common? 03.31.07 # either we say only non-interlaced "for jpeg" or non-interlaced "for all", it doesn't seem to matter 03.31.34 # right, unless the standard png is interlaced 03.32.03 # kugel: that's correct. the question is how *common* the unloadable files are going to be by format. conveniently progressive jpeg is useless with IE. ;) 03.33.32 # I still think saying "we generally support png for AA but the same limitations apply as for jpeg" is better than "we don't actually support png at all" 03.34.04 # We don't seem to get nearly as many calls for .png album art as we did for .jpeg. 03.34.43 # Is .png album art all that common in the first place? 03.34.58 # Might anyone know what's up with the file paths in that patch? 03.35.25 # I'd rather not manually point to the files again when I patch my VM sources. 03.35.26 # * kugel guesses git, and hence patch -p1 03.36.19 # Anyway, at the moment I have four DAPs to test it on. 03.36.26 # Two of them are redundant, though. 03.36.27 # Strife89: make a copy of your sources, and anyway "svn revert" does a good job in most cases 03.36.47 Join TillW [0] (~Till@h92-net09.simres.netcampus.ca) 03.38.23 Join Rondom [0] (~quassel@dslb-084-057-206-008.pools.arcor-ip.net) 03.38.33 Join n1s [0] (~n1s@rockbox/developer/n1s) 03.43.55 Quit Unhelpful (Remote host closed the connection) 03.45.36 Join bgs100 [0] (57o9@unaffiliated/bgs100) 03.53.41 Join Unhelpful [0] (~quassel@71.173.205.32) 03.53.47 Quit Unhelpful (Changing host) 03.53.47 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 03.57.38 Quit GeekShadow (Quit: The cake is a lie !) 03.58.46 # PNG is quite rare for album art I think 04.03.56 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 04.09.07 # * Unhelpful doesn't, and won't, use embedded AA... but doesn't *terribly* mind tossing some pointers re: implementation, and perhaps dropping that patch into a branch in his git and looking at what could improve. 04.10.31 # if we're supporting compressed formats *to save space* why would we ever want a copy of the AA inside each file? :/ 04.11.23 # I think embedded jpeg might be added to improve compatibility, since it's apparently bloody common. But I really would see an alternative of making a tool available on a wiki that'll go through a collection with embedded AA and extract it to Rockbox usable AA. 04.12.16 Join Barahir_ [0] (~jonathan@gssn-5f7540a1.pool.mediaWays.net) 04.14.34 # Llorean: bonus points if it strips the embedded AA from the tracks, too, ;) 04.15.31 Quit Barahir (Ping timeout: 245 seconds) 04.15.40 # Unhelpful: Extra ones if it compares all album art in a folder, and if they're identical, uses cover.jpeg instead of individual track jpegs. 04.17.58 # hrm, right now the buffering code figures out whether to call the jpeg or the bmp loader itself, right? what if we wrapped individual filetype loaders in a frontend that *also* understands embedded AA (and does what is needed to get it). if the metadata code is then capable of reporting whether a file contains embedded art and how to load it, this also makes it easy on other things that want to use the current AA (i'm thinking of sliding 04.17.58 # puzzle here) 04.18.32 # ie, metadata reports that the track has AA in , you ask the loader to load the image in , it figures out what it is and loads it. 04.19.32 Join xavieran [0] (~xavieran@ppp118-209-61-181.lns20.mel4.internode.on.net) 04.20.23 # sounds clever 04.20.36 # maybe i should start using AA sometime :) 04.23.15 # and when somebody wants to make image loaders pluggable, they have a nice *start* in that all code loading images is calling the same function. 04.24.40 Quit Rondom (Disconnected by services) 04.24.56 Join Rondom_ [0] (~quassel@dslb-084-057-174-013.pools.arcor-ip.net) 04.30.19 # i think pluggable image loaders is a bit overkill since we are not likely to ever have more than bmp,jpeg and possibly png 04.32.00 # * Unhelpful simply doesn't want to write the image loader loader, or any link scripts for anything at all 04.37.18 # reading the log abit... I also thought the codec buffer stuff was wierd 04.37.38 # why isnt it decoded stright into a new buffer like disk AA? 04.39.51 # jhMikeS: well, its not doing anything here... 04.44.54 # JdGordon: it might have to do with the problem of embedded AA almost never being "raw" image file data 04.45.32 # isnt the aa blog jpeg data? 04.46.40 # in id3, it may or may not have been filtered first to remove anything that looks like an mp3 sync string - this needs to be reversed to get the jpeg data 04.47.47 # vorbis comments are required by the spec to be valid utf-8, iirc, and so image data needs to be encoded, probably with base64, to be a valid comment 04.52.46 # so embedded AA is a p[retty nasty hack? 04.54.17 Quit n1s (Ping timeout: 240 seconds) 04.54.41 # depends on the format. vorbis comments were *always* meant to be text-only. id3v2 has specific tags for images, and others for other binary data, but is designed to allow that it might be played by a player that knows mp3 but not id3 04.55.58 Quit TheSeven (Ping timeout: 246 seconds) 04.56.59 Join Rob2222 [0] (~Miranda@p4FDCBC10.dip.t-dialin.net) 05.00.15 Quit n17ikh (Read error: Connection reset by peer) 05.00.32 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 05.00.52 Quit Rob2223 (Ping timeout: 265 seconds) 05.08.19 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 05.08.38 Quit n17ikh (Remote host closed the connection) 05.10.12 Quit saratoga (Quit: Page closed) 05.10.56 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 05.13.14 *** Saving seen data "./dancer.seen" 05.19.16 # Is there a reason bmp album art is still supported? Won't save much to remove it, but wasn't it always a compromise? 05.20.47 # No artifacts, and it's nearly free? 05.21.11 # Would bmp albumart be _added_ if jpg album art existed first? 05.21.23 # We also don't generally remove existing features very often. 05.21.39 # There'd be a lot of people with broken AA if .bmp were removed. 05.21.55 # both of those are poor reasons IMHO. 05.22.36 # * Llorean doesn't like the idea of adding things "to be removed later" 05.22.39 # I think my question is a more valid way of looking at the situation than either of those. 05.23.21 # soap: I often ask when a feature is going in "would we be adding this if (future feature) was done" so I understand the sentiment. 05.23.49 # But I really think it's a bad idea to start stripping features that users may be using unless we *need* to reclaim the space. 05.23.55 # We should just be very careful about adding things in the first place. 05.24.20 # Do we gain something *right now* from removing .bmp that's worth making users convert their images? If not, we should wait until we need that space back. 05.24.39 # Whoa, where's the battery life argument? ;) 05.25.37 # The people who receive the gift of broken album art are the people who were forced to kludge their (presumably) jpg album art into bitmaps already. ;) 05.25.51 # Yes, so we force them to repeat the conversion process again? 05.26.28 # Not to be pedantic, but it wouldn't be a repeated conversion, it would be a sync. 05.26.29 # As for the battery life argument, I don't *know* by any means, but I'd imagine removal of bitmap album art would be just about the smallest binary size difference possible. 05.26.59 # soap: Depends entirely on whether they have the original jpeg art around. For example, I acquired art specifically for my player, so the only existence of it in my collection is .bmp 05.27.08 # For I think it is safe to assume few, if any, individuals deleted their jpegs when creating bmp copies. 05.27.15 # * Llorean never had jpegs. 05.27.29 # But the point still stands - it invalidates previously supported files on their player. 05.28.25 # I'm also worried about removing features in general - "we can remove it later" shouldn't really be an argument for adding things. 05.28.57 # That appears to be "all or nothing" vs evolution. 05.29.22 # Evolution isn't the same, really. 05.29.34 # A feature can improve and expand, but it shouldn't go in in the first place if it can't stand on its own. 05.29.42 # The album art feature as evolved into the common practice. 05.30.10 # Removal is an option, I just think it should, generally, be one that is considered very, very carefully. 05.30.12 # So any existing feature gets a free pass and is considered "standing on its own" by virtue of existing? 05.30.22 # Something should be removed if it has a measurable negative impact, and no effective gain. 05.30.52 # That's a very high bar, but nonetheless different than what you said before. 05.31.02 # No, it's not different from what I said before. 05.31.07 # I didn't deny you had reasons to remove the feature. 05.31.30 # I just stated my opinion that they don't outweigh the impact it would have on the users, given that I think it seems likely the cost for the feature is about as minimal as costs for features get. 05.34.52 # I think if we had jpeg only right now, and someone said "Hey, it's basically free to enable .bmp album art" it would basically come down to seeing how much it actually cost in binsize. 05.35.02 # So we should see how much that is. 05.39.17 # probably a KB or two for the code for deciding which loader to call for album art, and for the code to search for both formats. and the scaler could possibly be more tightly bound to the loader if it was only going to be used by one loader... maybe it could even be inlined and the compiler could reduce/specialize it bit. 06.00.30 Nick bgs100 is now known as bgs000 (57o9@unaffiliated/bgs100) 06.04.59 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 06.05.52 Quit Strife89|PalmTX (Quit: Bed.) 06.11.17 Quit bluebrother (Disconnected by services) 06.11.21 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 06.42.17 Quit anewuser (Quit: http://xrl.us/NitroQueer What do you know...THE WORLD'S first NTRQ (that's for NES/FAMICOM) tracking compo. Have powerpak? Try it out! Otherwise ROM IMAGE.) 06.43.09 Join FlynDice [0] (~FlynDice@ptp-westmark-cr1.fai.acsalaska.net) 07.00.13 Part S_a_i_n_t_ 07.00.41 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.2.117) 07.06.45 Join Strife1989 [0] (~michael@adsl-80-185-188.mcn.bellsouth.net) 07.10.24 Quit Strife89 (Ping timeout: 260 seconds) 07.13.16 *** Saving seen data "./dancer.seen" 07.21.41 # soap: I dont see any point in removing .bmp AA... it is bassically free 07.21.52 # I would like to change the search order though 07.38.04 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 07.43.55 Quit Horschti (Ping timeout: 240 seconds) 07.48.35 Join ucchan [0] (~ucchan@pd37bf2.ykhmac00.ap.so-net.ne.jp) 07.49.09 Join Horschti [0] (~Horscht2@xbmc/user/horscht) 07.50.23 # There are various comments in IRC for FS#11216, and I reading now. 07.52.46 # It is not possible to comment in real time always, please comments in this task. 07.55.15 Quit CGL (Quit: Saliendo) 07.56.16 # When having done for a while, I quit IRC sorry. Then I will write the answer in this task. 07.57.33 Quit ucchan (Quit: Leaving...) 08.07.54 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 08.30.21 # New commit by 03amiconn (r25708): Charcell: Fix spurious letter appearing between board and score display. 08.39.59 Quit liar (Ping timeout: 258 seconds) 08.55.57 # FS#11216 <--Errrr...nice ;) 08.56.25 # * S_a_i_n_t puts this on his list of things to test in the near future. 09.01.35 Join stoffel [0] (~quassel@p57B4D53D.dip.t-dialin.net) 09.13.17 *** Saving seen data "./dancer.seen" 09.13.56 # [04:10:31] if we're supporting compressed formats *to save space* why would we ever want a copy of the AA inside each file? :/ 09.14.33 # I once saw an .mp3 with the very same AA image attached 100 times 09.14.51 # The total size of these exceeded the size of the actual mp3 data... 09.15.12 # Personally, I don;t really think saving space is a particularly good argument...but ease of use certainly is. 09.15.24 # The current system is a bit of an ass when it comes to AA 09.15.44 # Imo separate files for AA are much more convenient than embedded aa 09.16.45 # "new users" would appreciate this...the "mess-around" (or percieved mess-around) with AA is offputting at best. 09.16.54 # Just taking a cover.jpg and throwing it into the folder is certainly less work than firing up the tagging software and attaching it to every track 09.17.47 # *and* it needs less space at the same time 09.17.49 # Some/most of the time, whichever media player they use has probably added the AA in embedded form anyway though. 09.18.47 # I *do* agree with you...but being able to read embedded AA had been *begged* for in the ZForums 09.18.51 # MANY times. 09.19.02 # *Forums 09.19.45 # The fact that the current system doesn't "just work" seems to get a few new users a little steamed. 09.19.59 # * amiconn wouldn't use a media player that touches his files' tags without him knowing 09.20.18 # Well, that's you...many people do however. 09.20.48 # WMP is a pretty good example of that. 09.21.08 # A media player should play media files, as flexibly as possible, but nothing else 09.21.18 # *should* ;) 09.21.37 # WMP doesn't touch tags unless you let it 09.22.48 # I've actually met a few people that *thought* RB did embedded AA because they used WMP and didn;t realise that it saves a hidden/system "Filder.jpg" in the albums directory...and they'd just been drag & dropping from the WMP library 09.23.05 # *Folder 09.24.21 Join wodz [0] (~wodz@chello087206240004.chello.pl) 09.24.58 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 09.25.31 # Was there any disscussion about hw supported DSP functions vs. software DSP and how to organize UI for that? 09.37.02 # rr 09.41.09 # rawr? 09.47.57 Join n1s [0] (~n1s@rockbox/developer/n1s) 09.48.16 Join ender` [0] (krneki@foo.eternallybored.org) 09.52.05 Quit stoffel (Read error: Operation timed out) 09.52.57 Join stoffel [0] (~quassel@p57B4C627.dip.t-dialin.net) 09.54.02 # soap: I much prefer folder album art over embedded too 09.59.00 # That's from the POV of someone with a sanely managed media library though. 09.59.18 # "Mr.Everyday User" may not agree with that... 09.59.58 # I prefer the current AA system, but I see the merits of reading embedded AA also 10.00.30 # * amiconn thinks that embedded "album" art is even named wrong 10.00.49 # It should be called track art 10.00.50 # It is? 10.00.59 Quit phanboy4 (Ping timeout: 265 seconds) 10.01.32 # "Album Art" very rarely differs (if at all...) between different tracks on an album though 10.01.59 # Some albums have a different image for each disk, but not each track. 10.02.10 # *not that I've seen anyway 10.02.11 # yes, that's why there is no need to put it on every track in the album 10.02.32 # wodz: i think the only suggestion is for a separate "Hardware EQ" screen that lets users adjust a hw eq as flexibly as possible while keeping the regular sw eq screen, and having settings for any other dsp present in the dac 10.02.42 # I'm not referring to the actual content, but to the fact that it is attached to the track 10.02.45 # If you want it to "just work" though...without any extra pissing around. 10.02.56 # +then its a huge bonus 10.04.00 # while it might confuse the users a bit, i like the flexibility 10.04.31 # To someone switching from an OF that manages the AA itself, switching to Rockbox and having to create an image foe every album in the library (although this can be automated) is a daunting task. 10.04.50 # And if it could be avoided, I'm sure a LOT of people would appreciate it. 10.05.08 # s/foe/for/ 10.05.17 # I'd also like to insert into the earlier discussion that i personally don't think that that a feature is already in is a good reason to keep it, (not saying we should drop bmp aa) 10.08.55 Quit Lynx_ (Ping timeout: 276 seconds) 10.09.04 # n1s: but there is more DSP settings then simple EQ in some of the codecs 10.09.13 # s/is/are/ 10.09.53 # i think just introducing settings for them is fine, we have that for a lot of the dsp stuff in the mas codecs 10.10.27 # n1s: Yes but there is not distinguish between hw DSP and software DSP now 10.10.35 Join Lynx_ [0] (~bayer@86.51.114.198) 10.11.46 # true, but i don't think that matters a lot, except for the eq, since we'd have two eq's then 10.12.26 # it matters from the clearity point of view 10.12.47 # we have bass/treble in hw on some targets and sw on others 10.13.19 # in my opinion we should provide all features of the particular codec in HW menu and standard rockbox DSP in other 10.13.59 Quit bluebroth3r (Read error: Connection reset by peer) 10.14.35 # current mix is missleading 10.14.48 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 10.15.09 # it is? 10.15.43 Join Lynx__ [0] (~bayer@86.51.114.198) 10.15.59 # kugel: setting EQ do You know if this is hardware supported or not? 10.16.03 # I see no point of offering a feature in SW if the hardware can do it on it's own 10.16.06 Join bimbel [0] (~Miranda@unaffiliated/bmbl) 10.16.07 Quit bluebrother (Read error: Connection reset by peer) 10.16.14 Quit Lynx_ (Ping timeout: 240 seconds) 10.16.25 Quit bmbl (Disconnected by services) 10.16.29 Nick bimbel is now known as bmbl (~Miranda@unaffiliated/bmbl) 10.16.35 # in usage, it doesn't matter where it comes from 10.16.57 # kugel: it matter - software DSP reduce runtime 10.17.15 # is it important that you can see whether the hardware supports it in the settings menus? 10.18.28 # I preffer to see if particular setting will have impact on runtime 10.18.59 # s/impact/negative impact/ 10.19.15 Join merbanan [0] (~banan@c-94-255-217-199.cust.bredband2.com) 10.19.50 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 10.20.02 Quit Lynx__ (Ping timeout: 246 seconds) 10.20.45 Join Lynx_ [0] (~bayer@86.51.114.198) 10.21.20 # the dsp functions supported in HW are very basic (until now?) and very cheap to do in SW, I don't think the impact on battery life is messurable or even existent 10.21.45 # wodz: if you'd like to change this i suggest discussing it on the malinglist, i personally disagree though 10.21.45 Quit bluebrother (Read error: Connection reset by peer) 10.22.28 # kugel: the beast's dac can do a 5 band eq that is a bit less flexible than the sw one in hw 10.22.55 # iirc wodz's target has some 3d dsp thing 10.22.57 # we don't use it, do we? 10.24.11 # 3d thing in wm8750 is very similart to stereo width setting in rb but can only increase channel separation 10.24.19 # not yet, but we want to and i think having the option to use either one (or both) is best 10.25.24 # n1s: thats my point also to provide option to use both hw and sw dsp 10.25.40 # basically the flow sw dsp -> hw dsp 10.26.15 # preprocess signal in sw if requested and than process in hw if requested 10.27.35 # wodz: whatÄs the difference between the rb setting and the hw 3d thing exactly? 10.27.51 # I thought the setting also only increases the separation 10.27.58 Quit Lynx_ (Ping timeout: 245 seconds) 10.28.11 # wodz: but having f.e. bass/treble both in sw and hw makes little sense to me since they do the same thing and the sw is only there if the hw can't do it 10.28.40 Quit merbanan (Ping timeout: 252 seconds) 10.28.43 # kugel: you can also reduce stereo width (seperation) 10.28.43 # wodz: you mean a single interface, but use the best one for a given effect behind the scenes? 10.29.32 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 10.29.35 # hobbs: no, that's what's being currently 10.29.40 # hobbs: This is arbitrary decision which is the best isn't it? 10.29.56 # not really 10.31.08 # hey, hobbs, you got a real name so i can commit your png fix? 10.31.26 # n1s: sure. Andrew Rodland 10.31.34 # sweet 10.32.17 # I have no obejctions to use hw instead sw if both provide the same functionality but how to treate situation where hw support is not exactly the same as sw? 10.32.44 # hobbs: this channel is logged, I wouldn't put the plaintext email address here 10.32.58 # bit late for that... 10.33.01 # you're a bit late ;) 10.33.09 # snap! 10.33.36 # oh well, I've got some high-quality spam filtering ;) 10.34.00 # but I appreciate the thought 10.34.01 # if you are lucky someone who has access to it could edit it (maybe Bagder) 10.35.32 # New commit by 03nls (r25709): Fix for some bogus code in png by Andrew Rodland, fixing a warning when compiling with gcc 4.5 10.35.52 # as a note to the png discussion - the png viewer is still colour screens only. And even if there was a greyscale "port" it could use the greyscale library in a plugin, not in the core (bmp in the core vs. the plugin does the same btw.). And I also can't see the benefit of png for e.g WPS graphics, the file size difference is probably not big for most of them with the exception of the backdrop maybe and bmp decoding is super simple and png is not 10.36.21 # in comparison 10.36.49 # for WPS graphics much more interesting would be svg support 10.37.00 # pixelma: i agree about the wps graphics 10.37.05 # I don't think so 10.37.36 # wodz: making SVGs that render nicely at really low res is way harder than it sounds 10.37.42 # it's easier just to remake the pixel art ;) 10.38.15 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 10.38.46 # does SVG really makes sense for such low resolution ? There would probably be no gain for complicated backdrops 10.39.56 # Probbably - I'am not graphic expert. My point is only that reusing scalable graphics will be much easier between targets with different screen sizes. 10.41.38 # yes that's true. My point is that a the SVG file will also be big relatively the bmp ones because the resolution is quite low. And so does it makes sense to keep in SVG rather than generating a bmp from it for each target ? I don't know the answer either :) 10.44.08 # Does the size of theme file really matter much? We are speaking about size in range of tenth to hundreds of kB max 10.44.22 # an image that has to be scaled very much for the slow resolutions and colour depths won't look good anyways, I'm pretty sure 10.44.33 # err... low resolutions 10.45.10 # yeah, that's what I was saying 10.45.20 # what hobbs said (should have read compl...) 10.45.42 # * kugel wonders why r25706 is for SWCODEC only 10.46.30 Quit scorche (Disconnected by services) 10.46.36 # so maybe ask themers to include vector version of theme as a separate package? 10.46.41 Join scorche` [0] (~scorche@rockbox/administrator/scorche) 10.47.16 # If they have one ! 10.48.07 # Such ask may promote habbit to have one 10.48.38 # That would over-complicate the thems IMO 10.48.43 # *themes 10.49.46 # S_a_i_n_t, I am not speaking to include this in 'uploadable to the device' theme package. I would see this as a sort of 'source code' for theme rather 10.50.14 # I think some do 10.50.26 # Hmmm, I see your point. But is there any *need* to switch from .bmp? 10.50.35 # .bmp is fast...and easy. 10.51.55 Join JdGordon_ [0] (~jd@rockbox/developer/JdGordon) 10.51.58 # S_a_i_n_t: As I said on device bmp is fine but providing vector version as a sort of 'source code' will make porting theme to other screen resolution easier 10.52.02 # my "original source" isn't vector anyway, it's a GIMP file :) 10.52.21 # ok I giveup 10.53.12 Join M3DLG [0] (~M3DLG@212.183.140.0) 10.54.08 # S_a_i_n_t: nobody suggested removing .bmpt 10.54.14 # .bmp* 10.59.00 Nick scorche` is now known as scorche (~scorche@rockbox/administrator/scorche) 11.01.20 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 11.08.43 Join Highlander [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) 11.13.18 *** Saving seen data "./dancer.seen" 11.17.55 Join DerPapst [0] (~Alexander@p4FE8FECA.dip.t-dialin.net) 11.20.48 Join kifo [0] (~47d08723@giant.haxx.se) 11.20.58 Quit mc2739 (Ping timeout: 258 seconds) 11.23.49 Quit JdGordon_ (Quit: Bye) 11.25.10 Join Luca_s [0] (~5711b744@giant.haxx.se) 11.25.48 Quit kifo (Quit: CGI:IRC (Ping timeout)) 11.29.17 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 11.32.35 Quit Highlander (Quit: Quitte) 11.36.04 Join mikroflops_ [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) 11.37.23 Join Highlander [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) 11.39.39 Quit mikroflops (Ping timeout: 260 seconds) 11.47.23 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 11.52.00 Join dfkt [0] (dfkt@unaffiliated/dfkt) 11.52.14 Quit Strife1989 (Quit: Thunderstorm.) 12.04.26 Join ender [0] (krneki@foo.eternallybored.org) 12.06.55 Quit ender` (Ping timeout: 264 seconds) 12.07.27 Join flydutch [0] (~flydutch@host24-146-dynamic.15-87-r.retail.telecomitalia.it) 12.09.18 Join ender` [0] (krneki@foo.eternallybored.org) 12.10.41 Join jnss_ [0] (janes@gateway/shell/sign.io/x-vwlduembtdtjdmud) 12.11.57 Quit ender (Ping timeout: 258 seconds) 12.12.11 Quit jnss (Ping timeout: 240 seconds) 12.19.25 Quit n1s (Ping timeout: 246 seconds) 12.23.49 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 12.25.09 Quit stoffel (Remote host closed the connection) 12.25.35 Join {phoenix} [0] (~dirk@p57AA5763.dip.t-dialin.net) 12.31.53 Quit kugel (Ping timeout: 240 seconds) 12.32.36 Join n1s [0] (~n1s@rockbox/developer/n1s) 12.33.10 Join kugel [0] (~kugel@rockbox/developer/kugel) 12.45.17 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 12.46.35 Join stoffel [0] (~quassel@p57B4C627.dip.t-dialin.net) 12.48.30 Quit S_a_i_n_t () 12.49.11 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.2.117) 13.13.23 *** Saving seen data "./dancer.seen" 13.14.27 Quit stoffel (Ping timeout: 276 seconds) 13.14.54 # pixelma: I havnt heard otherwise so I'm assuing you arnt having issues with %pv inside conditionals anym,ore? 13.20.07 Quit Luca_s (Quit: CGI:IRC (EOF)) 13.21.25 # n1s: how's gcc 4.5? 13.24.46 Quit S_a_i_n_t (Ping timeout: 240 seconds) 13.26.00 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.156) 13.27.38 # why the hell isnt my battery level bar working :'( 13.30.17 # bah 13.31.51 Join Jaykay [0] (~chatzilla@p5DC57A39.dip.t-dialin.net) 13.32.19 Quit chaos (Ping timeout: 260 seconds) 13.32.39 # wodz: I don't know how important it is, but docs/COMMITTERS was in alphabetical order before you added yourself. 13.32.53 # New commit by 03jdgordon (r25710): Make battery level (%bl) work with the bmp bars drawer like %pb and %pv 13.40.25 Join Xerion_ [0] (~xerion@84.25.7.202) 13.41.57 Quit Xerion (Ping timeout: 264 seconds) 13.41.58 Nick Xerion_ is now known as Xerion (~xerion@84.25.7.202) 13.46.24 # linuxstb: ups I didn't noticed this. I'll fix this later 13.48.18 Quit M3DLG (Ping timeout: 264 seconds) 13.49.07 Join M3DLG [0] (~M3DLG@212.183.140.0) 13.56.58 # New commit by 03wodz (r25711): Fix alphabetical order of COMMITERS file 13.57.18 Join Xerion_ [0] (~xerion@84.25.7.202) 13.59.18 Quit Xerion (Ping timeout: 276 seconds) 13.59.18 Nick Xerion_ is now known as Xerion (~xerion@84.25.7.202) 14.01.12 Quit {phoenix} (Remote host closed the connection) 14.01.27 # New commit by 03jdgordon (r25712): Make the buffering screen use the multiscreen API (FS#11143) 14.01.34 Quit liar (Ping timeout: 258 seconds) 14.02.11 Join Xerion_ [0] (~xerion@84.25.7.202) 14.02.50 # is it known/intended that bass/treble settings don't actually do anything in the sim? 14.03.00 # probably 14.04.11 Quit Xerion (Ping timeout: 276 seconds) 14.04.11 Nick Xerion_ is now known as Xerion (~xerion@84.25.7.202) 14.05.02 # I'm currently doing an alsa-lib audio driver for the sim and have to notice that none of the dsp stuff actually works 14.05.59 # re: Bass/Treble...I had noticed it, but whether it's intended or not is an entirely different story I guess. 14.07.14 # I can't imagine it's intended, I think that simply nobody has done the needed work yet 14.07.57 # * JdGordon wonders why that yellow didnt hit every target without a remote lcd 14.11.36 # the others probably have LCD_HEIGHT > 80, so the || part isn't even evaluated 14.12.47 # that makes sense 14.14.15 # also would help if I got the define right :p 14.14.30 # New commit by 03jdgordon (r25713): fix yellow 14.16.06 Join w1ll14m [0] (~w1ll14m@84-104-80-54.cable.quicknet.nl) 14.19.06 Join Xerion_ [0] (~xerion@84.25.7.202) 14.20.02 Quit M3DLG (Ping timeout: 245 seconds) 14.20.51 Quit Xerion (Ping timeout: 260 seconds) 14.20.51 Nick Xerion_ is now known as Xerion (~xerion@84.25.7.202) 14.23.31 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 14.28.10 Quit Highlander (Quit: Quitte) 14.30.26 Nick bgs000 is now known as bgs100 (57o9@unaffiliated/bgs100) 14.37.18 Quit pamaury (Ping timeout: 252 seconds) 14.41.37 # hrm, with minimal changes bass&treble works for the sim 14.45.02 Join Xerion_ [0] (~xerion@84.25.7.202) 14.45.18 Join M3DLG [0] (~M3DLG@212.183.140.0) 14.45.58 Quit Xerion (Read error: Operation timed out) 14.45.58 Nick Xerion_ is now known as Xerion (~xerion@84.25.7.202) 14.51.18 Quit M3DLG (Ping timeout: 276 seconds) 14.51.55 Join M3DLG [0] (~M3DLG@212.183.140.0) 14.55.18 Quit n17ikh (Ping timeout: 265 seconds) 14.56.06 Quit linuxstb (Ping timeout: 264 seconds) 14.56.10 Quit M3DLG (Ping timeout: 246 seconds) 14.59.40 # JdGordon: yes, your last fix made my WPS work again. Is %bl| in a conditional also safe with the latest addition? 15.00.31 Quit mt_ (Ping timeout: 240 seconds) 15.02.34 Quit antil33t (Read error: Connection reset by peer) 15.02.40 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 15.04.29 Quit jordan` (Ping timeout: 265 seconds) 15.10.41 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 15.13.26 *** Saving seen data "./dancer.seen" 15.23.46 Quit kugel (Remote host closed the connection) 15.26.43 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 15.34.47 # kugel: a test compile with gcc4.5 for coldfire went fine, with the only error being the nsf codec not fitting in iram, and a handful of new warnings, haven't been able to try the buid yet thoug so can't say anyting about performance or if it even works :) 15.35.29 # also i would say that at least dsp stuff that is usually done in software should work in the sim 15.35.56 # Treble/bass is hardware on many targets though 15.36.32 Quit FlynDice (Remote host closed the connection) 15.37.05 # yeah, but imo it makes sense to have them in sw in the sim so they consistently work 15.39.51 Quit ps-auxw (Ping timeout: 248 seconds) 15.40.08 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 15.43.08 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 15.51.36 Join liar [0] (~liar@213162066156.public.t-mobile.at) 15.53.33 Quit mt (Read error: Connection reset by peer) 15.58.50 Join stoffel [0] (~quassel@p57B4C627.dip.t-dialin.net) 15.59.25 Join lpereira [0] (~lucien@112.46.70-86.rev.gaoland.net) 16.02.16 Join mt [0] (~mtee@rockbox/developer/mt) 16.04.41 Quit n1s (Ping timeout: 260 seconds) 16.06.01 Join Strife1989 [0] (~michael@adsl-80-137-151.mcn.bellsouth.net) 16.06.16 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 16.09.11 Quit mt (Ping timeout: 240 seconds) 16.09.59 # iTunes and e-music both ship files with embedded album art. For people who don't do as I do and only deal with complete albums embedded appears to not only be common, but to make some sense. Regardless, embedded is /common/, 16.12.52 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 16.15.35 Join Antibuddha [0] (~chatzilla@c-71-59-19-167.hsd1.ga.comcast.net) 16.15.57 # im using h120 rockboxed, what volume do i set it at for the line-out to be normal volume? i think i remember reading something like -14dB 16.18.23 Join n1s [0] (~n1s@rockbox/developer/n1s) 16.18.43 # Antibuddha: 0dB 16.18.56 # are you sure? 16.19.08 # why is it that the iriver h120 has variable line-out? 16.19.57 Join jordan` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net) 16.20.28 # i heard people say they damaged their h120 by going too high volume on lineout 16.21.15 # im about to get a portable headphone amplifier and want to know the best volume to set the lineout at 16.24.58 Quit lpereira (Quit: Leaving.) 16.25.32 Quit DerPapst (Quit: Leaving.) 16.32.54 # 0 = line-out on my iPod's headphone jack and my H340's headphone AND line-out jack. 16.33.29 # Should a line-out be fixed? Yes, It is on much hardware, but not on my H3x0, and therefore I assume not on your H1x0. 16.34.35 # It's a "feature" of the h1x0 that the volume changes the line-out volume - Rockbox can't prevent it. 16.35.53 Quit bertrik (Read error: Connection timed out) 16.36.25 # would i be avoiding distortion by choosing a particular volume for lineout? 16.36.30 # 0 16.36.36 # ok 16.36.50 # higher and you will potentially clip, lower and you decrease the SNR. 16.37.03 # i heard people say that they damaged their h120 or reached distortion by going very low volume on lineout 16.37.30 # is it because they tried driving headphones? 16.38.44 # /though/ FWIW my cassette tape adapter, not Rockbox, distorts @ anything louder than -5. But only that adapter. All my line-in's do fine @ zero. 16.39.25 # so if i set the lineout of h120 to -20dB, it will have much less SNR? 16.39.48 # Going very low volume would expose the native noise of the system due to low signal levels, but anyone who said that causes damage needs to really explain how and why. 16.40.09 # 20db less. You're lowering the signal while noise remains constant. 16.40.20 # soap: i believe they damaged only by using lineout to drive headphones 16.40.35 # not by using it as normal lineout 16.41.20 # Wouldn't lower volumes = less voltage and /decreased/ likelyhood of problems? 16.42.35 # yes 16.42.48 # what i mean is people damaged it at around -7dB if i recall 16.43.06 # using lineout as opposed to headphoneout 16.44.45 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 16.46.31 Quit Antibuddha (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 16.47.25 Quit phanboy4 (Ping timeout: 265 seconds) 16.53.06 # I don't know enough to say said people are wacked in the head - but it is not uncommon practice for H3x0 users who have broken their headphone-out to use their line-out as a headphone out. 16.53.46 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 17.04.30 Quit wodz (Quit: Leaving) 17.04.32 Quit liar (Ping timeout: 276 seconds) 17.11.07 Quit bertrik (Read error: Connection timed out) 17.11.40 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 17.13.19 # n1s: Imo it should depend on the target 17.13.29 *** Saving seen data "./dancer.seen" 17.20.17 # so on targets with hw bass/treble they do nothing in the sim? 17.23.18 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 17.24.11 # soap: i did that, untill the line-out broke :/ 17.24.21 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 17.43.47 Quit stoffel (Ping timeout: 246 seconds) 17.46.24 Quit bertrik (Read error: Connection timed out) 18.00.10 Quit adnyxo (Ping timeout: 252 seconds) 18.00.46 Join chaos [0] (~chaos@gentoo/user/ch4os) 18.01.09 Join kkurbjun [0] (~kkurbjun@c-98-245-170-51.hsd1.co.comcast.net) 18.01.18 Quit kkurbjun (Changing host) 18.01.18 Join kkurbjun [0] (~kkurbjun@rockbox/developer/kkurbjun) 18.01.23 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 18.02.51 Join anewuser [0] (anewuser@unaffiliated/anewuser) 18.04.36 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 18.06.55 Quit Topy44 (Ping timeout: 276 seconds) 18.10.22 # New commit by 03kkurbjun (r25714): M:Robe 500 USB: Go back to OF timings for upcoming clock changes 18.11.51 # New commit by 03kkurbjun (r25715): M:Robe 500 Power: Update battery Curve and simplify calculations. 18.14.03 # New commit by 03kkurbjun (r25716): DM320 UART: Enable clock in UART module since it will not be done in system initialization. 18.14.09 Join stoffel [0] (~quassel@p57B4C627.dip.t-dialin.net) 18.15.01 Join Topy44 [0] (~topy@my.fastsh.it) 18.19.09 Quit tchan (Quit: WeeChat 0.3.1.1) 18.19.55 Quit Topy44 (Ping timeout: 276 seconds) 18.20.50 Nick jnss_ is now known as jnss (janes@gateway/shell/sign.io/x-vwlduembtdtjdmud) 18.23.16 Quit linuxstb (Ping timeout: 260 seconds) 18.26.51 Join Topy44 [0] (~topy@my.fastsh.it) 18.28.28 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 18.29.53 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.30.19 Quit bertrik (Changing host) 18.30.19 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 18.31.37 Quit Topy44 (Ping timeout: 276 seconds) 18.37.58 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 18.38.21 Quit n17ikh (Client Quit) 18.38.36 Quit n1s (Quit: Lämnar) 18.38.52 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 18.39.22 Join Topy44 [0] (~topy@my.fastsh.it) 18.40.59 Join Highlander [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) 18.44.37 Quit Topy44 (Ping timeout: 276 seconds) 18.46.15 Quit adnyxo (Ping timeout: 276 seconds) 18.48.37 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 18.51.04 Join mirak [0] (~mirak@85-171-108-160.rev.numericable.fr) 18.52.59 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 18.59.08 # i have an e10 simulator now that seems to work reasonably well 18.59.30 Join merbanan [0] (~banan@c-94-255-217-199.cust.bredband2.com) 19.00.04 # think i'll upload the patch for the build target today :) 19.01.13 # playback sounds quite good as well :) 19.01.59 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 19.05.12 # should the BMP pic of the player used for the simulator be actual size? 19.05.20 # it isn't. 19.05.52 # I don't see how you can practically have an "actual size" since the displayed size depends on the monitor pixel size. 19.06.13 Join Topy44 [0] (~topy@my.fastsh.it) 19.06.31 # that's true. but should the area used for the LCD have the same resolution as the actual LCD? i think so. 19.06.59 # as of now the simulator only uses part of the "LCD" on the screen 19.07.44 # Yes, it should 'fit' around the virtual LCD. 19.08.15 # is there a way to include a binary file, such as a BMP, in a patch? 19.09.37 Join japper [0] (~4df9ac82@giant.haxx.se) 19.10.53 Quit japper (Client Quit) 19.11.55 Quit Topy44 (Ping timeout: 276 seconds) 19.11.55 Join CGL [0] (~CGL@190.207.195.211) 19.13.31 *** Saving seen data "./dancer.seen" 19.15.21 Quit bertrik (Read error: Connection timed out) 19.16.13 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 19.35.55 Join Topy44 [0] (~topy@my.fastsh.it) 19.36.17 # patch is uploaded, now it's just a matter of patience i guess 19.41.10 Quit Topy44 (Ping timeout: 276 seconds) 19.42.43 Join RoC_MasterMind [0] (~Free@c-76-122-43-188.hsd1.fl.comcast.net) 19.44.01 # ollebe: First question - where did you get the simulator background image from? Do you own the copyright? 19.44.38 # linuxstb: sorry about that. no, i don't own the copyright. 19.44.51 # i'll add a comment about excluding the image. 19.45.16 Quit mirak (Quit: Ex-Chat) 19.45.43 Quit Unhelpful (Remote host closed the connection) 19.47.54 Join saratoga [0] (~463f90ed@gateway/web/freenode/x-dfbqriqwgwmobxas) 19.48.24 # whats the storage like on the e10? another tcc NAND translation layer? 19.48.42 # ollebe: In config/irivere20.h you should choose an unused MODEL_NUMBER value (look in the other config files in that directory to see what is used). Also 19.49.05 # If I'm understanding the patch, it's a standard ATA interface. 19.49.35 # saratoga: IIRC it is a seagate 6 GB HDD with PATA to a PATA interface in the SoC 19.49.47 # oh so ATA? 19.50.13 # should make things a lot easier 19.50.16 # ok linuxstb, i'll fix the model number. 19.51.03 # yeah it simplifies. i think ATA support is pretty much finished already. LCD driver, power handling, etc is missing. 19.51.50 # Ah, a 128x128x16 LCD - same as the H10. Maybe it's the same LCD controller? 19.51.54 # how do load code onto the e10? 19.52.19 # * linuxstb was about to ask that ;) 19.53.51 # * amiconn tries to single-step the elio rom in skyeye 19.53.57 # i don't know that, but someone will figure something out :) 19.54.15 # linuxstb: Btw, I *guess* the lcd controller in the elio is a TL1769 19.55.02 # amiconn: I never managed to find anything that I could identify as the LCD driver... I assume you haven't made it work yet though? 19.56.47 Quit RoC_MasterMind (Quit: Leaving) 19.57.05 Quit antil33t (Read error: Connection reset by peer) 19.57.13 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 19.57.51 # ollebe: maybe figuring out how to run code is more important then the Sim? usually people do that first 19.58.46 # saratoga: well, the simulator wasn't such a challenge so I did that first 19.58.55 # true 19.59.38 # ollebe: So you can't run anything on your E10? 19.59.54 Join Xerion_ [0] (~xerion@84.25.7.202) 20.00.05 # linuxstb: nope. 20.00.43 # Hmm, then I'm not sure if there is a point in committing anything. Finding out how to run your own code is the first thing to be done - if you can't do that, the rest is pointless. 20.01.21 # there's a possibility that we could use irde.c to encrypt the image and do a FW upgrade, but E10's encryption are not consistent with the other ifp-like images. 20.01.43 Quit Xerion (Ping timeout: 252 seconds) 20.01.43 Nick Xerion_ is now known as Xerion (~xerion@84.25.7.202) 20.02.07 # Have you managed to decrypt the original firmware to disassemble it? 20.03.21 # linuxstb: I think the OF is decrypted by ifp_decode or by irde.c, yes. but since what's know about the checksums don't seem to apply to E10, I'm not sure. 20.03.31 # I have written a bit about that on the wiki 20.04.25 # it is being decrypted, but what was thought to be checksum fields are not checksums. applies to a large portion of the OF. 20.04.42 # So the firmware upgrade process is similar to the older irivers? i.e. copy a .hex file to the device and upgrade via the original firmware? 20.05.19 # yeah. 20.05.55 Join mozetti [0] (~60ffd62b@gateway/web/freenode/x-pxbyheadcggapzvs) 20.05.59 # there is also a USB emergency mode, that might be a DFU mode, but it's not clear how to enter. 20.06.02 Quit liar (Quit: Verlassend) 20.06.19 # IIRC i entered that mode when i messed up the formatting of the HDD. 20.07.25 # Where is the info on the wiki? I can just find IriverE10Info which doesn't mention the firmware format. 20.07.34 Nick Strife1989 is now known as Strife89 (~michael@adsl-80-137-151.mcn.bellsouth.net) 20.07.48 # Afternoon - my HDD on my iRiver H340 died. I'm going to do the CF-Mod but my main use will be recording concerts (that permit taping). Should I be overly concerned about the CF card write speeds? Or will they all generally be fast enough for audio recording? Thanks 20.08.08 # there's also some kind of hardware error that happened to some users. might be the connection to the HDD that fails, and it enters emergency mode. 20.08.09 # ollebe: I was just looking at the board scans and they clearly silkscreened the JTAG pins so you should be able to get hardware access to the player through JTAG to test new images and recover. 20.08.38 # i'll add that information to the wiki linuxstb 20.08.41 # (TMS, TDO, TCK, TDI) 20.08.53 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 20.08.57 Join kugel [0] (~kugel@rockbox/developer/kugel) 20.09.00 # thanks kkurbjun 20.09.53 # (TRST) - looks like there's also some UART pins for debugging too (TX0, RX0) 20.09.57 # no problem 20.10.39 # they also have the ISP pins pulled out for that atmel chip if you want to re-program that too on the other side of the board :-D 20.11.08 # yes i know about the Atmega :) 20.11.50 # Is there any NOR? I can't see it in the list of chips, or is it embedded in the SoC? 20.11.59 # it might be for the remote control and button handling, which works even when the system is in off mode. 20.12.07 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 20.12.29 # linuxstb: IIRC there's a 50 kB flash in the SoC 20.12.40 # amiconn: what do you mean by it should be target dependant? 20.12.59 # ollebe: IIRC, that's the boot ROM. I'm wondering where the ".hex" file is written to. 20.13.06 # if a target does bass/treble, no matter of in hw or sw, it should be simulated, IMO 20.13.24 Quit bertrik (Read error: Connection timed out) 20.14.11 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 20.14.33 # ollebe: Have you tried removing your hard disk and reading it in a PC? 20.14.45 # linuxstb: it might be to some hidden area on the HDD. excellent! 20.15.36 # ollebe: How do you know that the "checksum fields" are not checksums? 20.16.07 # linuxstb: i explained that on a wiki page, one second 20.17.08 # http://www.rockbox.org/wiki/IfpCryptanalysis However I ran into problems when i tried running irde on E10's firmware. It seems on the positions in the blocks where there should be checksums (offset x*51 + 50, and offset 255), large parts of the E10 firmware has no checksums but something else entirely. Even if the contents of the blocks varies, the "checksums" stays the same, so they're not checksums. 20.17.11 Quit Unhelpful (Remote host closed the connection) 20.17.32 Join Topy44 [0] (~topy@my.fastsh.it) 20.18.31 Join Luca_s [0] (~5711b744@giant.haxx.se) 20.19.51 # how big is the firmware file? on a color target large sections may be graphics which don't need to be check summed 20.20.06 # i think the older ifp targets weren't color and so would have had few graphics 20.22.19 # good point. 20.22.46 Quit Topy44 (Ping timeout: 276 seconds) 20.22.59 # e10 uses SWF flash for the user interface. that might have something to do with it as well. 20.23.15 # it's 6 MB. 20.23.26 # much larger than IFP's. 20.25.48 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 20.25.58 # i can confirm that the SoC has only one small RAM and one small ROM 20.26.51 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 20.27.34 Join funman [0] (~fun@rockbox/developer/funman) 20.31.25 # ranma: nice findings, do you understand what the as3514 bits you modified mean ? 20.32.24 # kugel: Targets with software treble/bass should have it working in the sim, targets wih hardware treble/bass shouldn't (unless sdl allows setting the soundcard's tone filters) 20.32.41 # linuxstb: I found code initing structures with lcd addresses 20.33.11 # ...but no code using literal addresses 20.33.31 # That's why I'm trying the emulator approach instead 20.34.09 # that doesn't make sense to me 20.34.12 # The elio rom uses a lot of thumb code 20.34.17 # it's a simulator afterall 20.34.29 # not an emulator 20.34.56 # then MAS playback should be simulated as well ;) 20.35.29 # we also simulate backlight without really dimming the brightness of the display 20.36.44 Join Topy44 [0] (~topy@my.fastsh.it) 20.38.37 # kugel: it makes sense but the SW controls wouldn't run on the target, so they shouldn't run in the sim either 20.39.31 # surely simulating in another way is better than not simulating at all? 20.40.01 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 20.41.30 # Isn't it a "UI Simulator"? Isn't the key presenting an accurate visual representation of the target, not necessarily anything else? 20.41.36 Quit Topy44 (Ping timeout: 276 seconds) 20.42.06 # Well, the more it simulates, the more useful it is for developers. 20.42.06 # Llorean: no it can be used to debug code as well 20.42.32 # I wonder if running this code when simulating a target where it wouldn't run, would harm debugging audio code 20.43.26 # it's probably a question how representative it is (and if it adds much code complication) if code goes a different code path for a specific target's sim and the real target 20.44.36 Quit droidcore (Ping timeout: 252 seconds) 20.45.07 # ollebe: Are you able to remove the disk and access it directly? 20.45.30 # linuxstb: probably. 20.46.15 Quit ender` (Ping timeout: 276 seconds) 20.46.15 Quit mapi (Ping timeout: 252 seconds) 20.46.21 # i'm looking at the HDD through the usual interface right now 20.46.55 # "usual" interface? You mean with it still in the E10? 20.46.59 # i'm expecting the OF to "censor" some hidden area at the beginning or the end of the disk. 20.47.01 # Llorean: it also runs the whole SWCODEC and buffering systems too, so I use it a lot to debug and develop for those parts of rockbox too 20.47.01 # yes 20.47.04 Quit Unhelpful (Remote host closed the connection) 20.47.13 Join DerPapst [0] (~Alexander@p4FE8FECA.dip.t-dialin.net) 20.47.17 # kugel: but something different. I tested the simplify PLA patch on my Ondio and it works fairly well on my Ondio, with the one of metronome. It's still better than SVN but I *believe* an earlier patch worked better. Unfortunately it's long ago that I tested earlier version and I only remember being impressed before, I'm not a 100% sure though if it also was the Ondio etc. 20.47.33 Join mischasworld [0] (~quassel@f051145057.adsl.alicedsl.de) 20.47.37 # Yes, the OF will probably not expose the first X MB of the disk via USB - so you'll need to physically remove it to see what's there. 20.48.20 # kugel: one exception I mean 20.48.21 # however i have found a 1.5 MB area that I'll look at. 20.48.34 # pixelma: can you tell what worked and now doesn't anymore? 20.49.54 # no, hence my "I'm not sure". The problem is tapping and start/stop "playing" all on the same button 20.50.38 # maybe I can find out by looking at the different patches 20.50.58 # I guess you can still try out the older patches by applying it to an older svn rev 20.51.59 # yeah - but updating builds on the Ondio is no fun :\ maybe the sim can help 20.52.27 Quit flydutch (Quit: /* empty */) 20.52.36 # pixelma: I can imagine what changed 20.53.00 # try changing the "#define METRONOME_TAP PLA_SELECT" to "#define METRONOME_TAP PLA_SELECT_REL" 20.53.05 # +line 20.54.19 # funman: FuzeV2 - I did the battery bench without CPU frequency scaling. lame_128.mp3 played in loop for 13hrs 30minutes. The difference is about 4hrs, so it's actually noticeable. 20.54.30 Nick Luca_s is now known as Luca_S (~5711b744@giant.haxx.se) 20.55.27 # yep I saw that, it was to be expected 20.56.02 Join MethoS- [0] (~clemens@134.102.106.250) 20.56.11 # kugel: ok, I'll try. I have to run off for a while in a bit though 20.56.20 Join Topy44 [0] (~topy@my.fastsh.it) 20.56.57 Join ender` [0] (~ender@foo.eternallybored.org) 20.57.52 Join Lear [0] (chatzilla@rockbox/developer/lear) 21.01.06 Quit Topy44 (Ping timeout: 276 seconds) 21.02.34 Join mapi [0] (~mapi@KHP222006067242.ppp-bb.dion.ne.jp) 21.02.37 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 21.03.26 Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) 21.04.33 Join mirak [0] (~mirak@85-171-108-160.rev.numericable.fr) 21.09.41 Join archivator [0] (~archivato@stu0279.keble.ox.ac.uk) 21.10.29 Quit GeekShadow (Read error: Connection reset by peer) 21.10.45 Quit Unhelpful (Remote host closed the connection) 21.11.06 # Question: When doing the CFMod (H340), should I be concerned about CF Card write speeds if I plan to use the H340 to record live concerts? Or should any decent card be fine for recording audio? 21.12.21 Join Topy44 [0] (~topy@my.fastsh.it) 21.13.00 # mozetti: I suspect the forums might be a better place for that question. My impression is that there are more people there who do recording 21.13.29 Quit stripwax (Quit: http://miranda-im.org) 21.13.33 *** Saving seen data "./dancer.seen" 21.13.42 # Is there a non-callback recording API? I'd like to add recording to FFT but would like to keep the current 2-thread system. 21.15.34 # gevaerts: thank you. I knew the devs spent time here and thought it might be more of a hardware capability/technical kind of question. I'll try the forums. 21.16.57 # mozetti: only one or two of the devs really care much about recording, and they don't seem to be online right now 21.17.21 Quit Topy44 (Ping timeout: 276 seconds) 21.17.26 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 21.17.52 Join dfkt [0] (dfkt@unaffiliated/dfkt) 21.18.07 # mozetti: Even uncompressed PCM is only about 176KB/s, so I wouldn't worry too much. But yes, it wouldn't hurt to ask in the forums. 21.18.32 # thanks everyone 21.21.55 Join Unhelpful [0] (~quassel@71.173.205.32) 21.21.55 Quit Unhelpful (Changing host) 21.21.55 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 21.24.22 Quit mischasworld (Remote host closed the connection) 21.28.10 Quit funman (Quit: free(random());) 21.28.21 Quit Lear (Quit: ChatZilla 0.9.86 [Firefox 3.6.4/20100413172113]) 21.31.04 # mozetti: Just a question - why wav instead of lossless wavpack? If you're worried about write speeds for some reason (as linuxstb mentioned, it shouldn't be a big concern) that would give you even more elbow room. 21.31.09 Quit esperegu (Read error: Connection reset by peer) 21.32.17 # Llorean: familiarity - never used wavpack before. Just .wav and the encode it to FLAC/MP3/OGG/etc on my PC 21.32.25 Join esperegu [0] (~quassel@145.116.15.244) 21.32.38 # *then encode 21.36.38 Join Topy44 [0] (~topy@my.fastsh.it) 21.36.40 Quit saratoga (Quit: Page closed) 21.36.54 Quit Rob2222 (Remote host closed the connection) 21.37.09 Join Rob2222 [0] (~Miranda@p4FDCBC10.dip.t-dialin.net) 21.37.45 Quit pixelma (Disconnected by services) 21.37.46 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 21.38.08 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 21.38.20 Quit amiconn (Disconnected by services) 21.38.22 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 21.38.31 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 21.42.03 Quit Topy44 (Ping timeout: 276 seconds) 21.44.28 Quit Jaykay (Ping timeout: 240 seconds) 21.45.06 Quit pamaury (Quit: Page closed) 21.48.02 Join Topy44 [0] (~Topy44@f049083072.adsl.alicedsl.de) 21.48.44 Join Topy [0] (~topy@my.fastsh.it) 21.50.27 Quit Strife89 (Quit: See ya.) 21.54.18 Join Kitr88 [0] (Kitar_st@BSN-182-78-81.dial-up.dsl.siol.net) 21.56.49 Quit anewuser (Quit: http://xrl.us/NitroQueer What do you know...THE WORLD'S first NTRQ (that's for NES/FAMICOM) tracking compo. Have powerpak? Try it out! Otherwise ROM IMAGE.) 21.57.05 Quit Kitar|st (Ping timeout: 276 seconds) 21.59.07 Quit stoffel (Remote host closed the connection) 22.00.23 Join mischasworld [0] (~quassel@f051145057.adsl.alicedsl.de) 22.00.26 Quit mischasworld (Remote host closed the connection) 22.02.03 Quit merbanan (Ping timeout: 264 seconds) 22.02.19 Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) 22.03.58 Quit stripwax (Ping timeout: 265 seconds) 22.04.50 # New commit by 03jethead71 (r25717): Optimized DSP sample out functions for armv6. (For stereo output) ~9% faster than SVN asm and about 4% faster than SVN asm rearranged to observe ... 22.06.18 Quit Kitr88 () 22.13.20 Join Kitar|st [0] (Kitar_st@BSN-182-80-188.dial-up.dsl.siol.net) 22.15.54 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 22.26.01 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 22.27.37 Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) 22.30.35 Join krazykit [0] (~kkit@adsl-76-251-236-208.dsl.ipltin.sbcglobal.net) 22.30.53 Quit stripwax (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 22.31.46 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 22.32.03 Quit krazykit` (Read error: Connection reset by peer) 22.32.05 Quit mozetti (Ping timeout: 252 seconds) 22.42.22 Join Watermark [0] (~chatzilla@adsl-220-169-17.mob.bellsouth.net) 22.42.57 Join emrecelikten [0] (~anubis@88.240.140.202) 22.43.18 # hello linuxstb, user gave me other info to share :) 22.43.26 # Jan 10, 2008 SPECIFICATION TCC79XX 22.43.28 # EXTERNAL MEMORY CONTROLLER REV 0.10 22.43.29 # 29-4 Preliminary 22.43.31 # SDRAM Configuration Register (SDCFG) 0xF1000000 22.43.32 # 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 22.43.34 # CL BW CW RC RCD WR 0 0 22.43.35 # 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 22.43.37 # RP RW 0 0 0 0 0 0 AM 0 PPD SR 22.43.38 # Field Name RW Reset Description 22.43.40 # 0 SR RW 0 22.43.41 # Self refresh enable register 22.43.43 # 0 : Disabled(exit from self-refresh state) 22.43.44 # 1 : Enabled(enter self-refresh state) 22.43.46 # Before entering self-refresh state, the instruction and 22.43.47 # data in the SDRAM should be written back. 22.43.49 # 1 PPD RW 0 22.43.50 # Precharge power-down mode enable 22.43.52 # 0 : Disabled, 1 : Enabled 22.43.53 # 3 AM RW 0 22.43.55 # Address matching option 22.43.56 # 0 : BANK-RAS-CAS address order 22.43.58 # 1 : RAS-BANK-CAS address order 22.44.00 # The address bit width for SDRAM banks is two. 22.44.01 # 11 ~ 10 RW RW 3 22.44.03 # RAS address width configuration register 22.44.04 # {0} : 12 bits RAS address width 22.44.06 # {2} : 13 bits RAS address width 22.44.07 # {1, 3} : 11 bits RAS address width 22.44.09 # 15 ~ 12 RP RW 4 Precharge-to-Refresh cycle parameter 22.44.10 # 19 ~ 18 WR RW 2 Write-to-Read wait cycle parameter 22.44.12 # 23 ~ 20 RCD RW 4 RAS to CAS cycle parameter 22.44.14 # 27 ~ 23 RC RW 10 Refresh-to-Idle cycle parameter 22.44.16 # 29 ~ 28 CW RW 2 22.44.17 # CAS address width 22.44.19 # {0,1} : 8 bits CAS address width 22.44.20 # {2} : 9 bits CAS address width 22.44.22 # wouldn't pastebin be more appropriate for this? 22.44.22 # {3} : 10 bits CAS address width 22.44.23 # 30 BW RW 1 22.44.25 # SDRAM Bus width 22.44.26 # 0 : 32 bits data bus 22.44.28 # 1 : 16 bits data bus 22.44.29 # 31 CL 0 22.44.31 # CAS latency 22.44.32 # 0 : 2 Cycles 22.44.34 # 1 : 3 Cycles 22.44.35 # 0x6A484C00 is the reset default vaule 22.45.10 # Watermark: please don't paste lots of lines here 22.45.17 # *PLEASE* use pastebin or some other sharing resource for this kind of information next time 22.48.52 # sorry... 22.50.00 Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-uxoetmnexcpttmhh) 22.50.21 # when did the bot stop banning people for channel flooding? 22.52.16 # @linuxstb, http://paste.lisp.org/display/98333/raw 22.52.22 Quit Watermark (Remote host closed the connection) 22.52.42 Join Watermark [0] (~chatzilla@adsl-220-169-17.mob.bellsouth.net) 22.53.00 # @linuxstb, http://paste.lisp.org/display/98333/raw 22.53.07 # hope this helps 22.57.13 Quit tchan (Quit: WeeChat 0.3.3-dev) 22.57.53 Join droidcore [0] (~mark@206-248-131-88.dsl.teksavvy.com) 23.01.00 Join Spaceghost [0] (irssi@unaffiliated/spaceghost) 23.01.04 # Hello 23.01.25 # exist something for run Rockbox in Android? 23.02.16 # no. but it has been said that "the future for rockbox is an app" 23.02.20 # is possible now run android on iPhone 2G, and is near for the iTouch, so, can I use the rockbox's interface on it? insiode android? 23.02.41 # isnide 23.02.42 # so maybe in the future, but not now, i guess. 23.02.47 # auch, *inside 23.03.12 # and what about can run rockbox in the iTouch? 23.03.31 # if will be possible run android, will be possible run rockbox on it? 23.03.34 # rockbox can not run as an app, yet 23.03.50 # maybe in the future 23.03.57 # and have three option in the boot? would be cool 23.04.05 # Spaceghost: NO 23.04.13 # jajaja 23.04.15 # ok, sorry 23.05.26 Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 23.06.11 # who is the bot that is loggin? 23.06.15 # logging 23.07.20 # hmm, scrolling through the list of users I clearly see a nick called "logbot". :-P 23.08.01 # Spaceghost: if you want to read the logs just check the topic 23.12.27 Quit bmbl (Quit: Bye!) 23.13.36 *** Saving seen data "./dancer.seen" 23.13.39 # ls 23.13.48 # oops... 23.16.53 # I read 23.16.58 # jaja 23.17.10 # neinnein 23.17.29 # logbot, impossible more clearer name 23.19.58 # @linuxstb, what could you make out of the Link i posted 23.20.00 # '? 23.22.38 # New commit by 03bluebrother (r25718): Log failures in mountpoint resolving, log filesystem formats in mountpoints(). 23.23.44 Part Farthen 23.24.43 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 23.25.36 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 23.26.13 Quit tchan (Client Quit) 23.26.44 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 23.31.47 # domonoky: around? 23.32.01 # jup, but not long :-) 23.33.24 # I've added a repeat detection to the system trace logging function. I'm wondering if that's a good idea at all, as it will consume all repeated lines and only output a duplicate count when the next different line gets logged 23.34.01 # any thoughts on this? The idea came from some parts logging too much (like the Info tab ... logged the same string > 200 times for me :o ) 23.34.16 # Watermark: I know nothing about SDRAM configuration... 23.35.09 Quit bertrik (Ping timeout: 246 seconds) 23.36.48 Quit Highlander (Quit: Quitte) 23.37.40 # kugel: Well, an emulator would emulate a target, and run a target build on top of that 23.38.17 # The simulator should still simulate the target, by means of running (almost) the same code compiled for the host cpu 23.39.30 # That said, we could simulate tone controls for targets with hardware tone controls, *but* if we do that this should either use the host's hardware (if possible), or if it has to be done in software, it should be done in the simulator layer, not in the app layer 23.41.11 # bluebrother: hm, the idea is nice. But it may get problems if we do something twize because of a bug. 23.41.56 # if for example talkfile generation speaks a string multiple times due to a bug, we wont see it. 23.42.54 # well, I put a "(last message repeated n times)" in the log. The problem is that this output is delayed as I only know the number on the first different log message 23.44.24 # ah, then it shouldnt be a problem. maybe add this log entry also when opening/saveing the systrace ? 23.45.52 # could you try that value out that was posted? 0x6A484C00 23.46.10 # that notice is added to the log itself, so it appears everywhere -- on stdout for debug builds, the log viewer and when saving 23.46.10 # ie end the dublicaton detection when getTrace() gets called :-) 23.46.37 # it's hooked into SysTrace::debug() 23.47.05 # Watermark: That's the one you gave me a few days ago. 23.47.12 # yes, but if the log ends whith dublicates, you wont see this line. 23.48.02 # we could just log the getTrace() call to always get this line, even when a log ends in dublicates :-) 23.48.03 # ah, right. Good point. 23.48.34 # current state: http://pastebin.de/5770 23.48.55 Join mikroflops [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) 23.51.16 Quit robin0800 (Remote host closed the connection) 23.51.21 Quit Watermark (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 23.52.00 # bluebrother: looks good. just add a qdebug() to getTrace() and commit it :-) 23.52.08 Quit mikroflops_ (Ping timeout: 252 seconds) 23.54.04 # ok :) 23.54.13 # bluebrother: if you find time, can you test the paralell tts patch from archivator on Mac with TTSCarbon ? (i had problems with sapi, so we should make sure it runs fine with the other non-paralel tts before commiting) 23.55.47 # ok, will try to find some time the next days. 23.56.50 # kugel: the release action really works better (before you sometimes triggered another tap (and messing up the bpm) when you used the "Long Mode" (Select repeat, I guess) to start "playing"