--- Log for 04.08.112 Server: kornbluth.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 1 month and 20 days ago 00.01.19 Quit benedikt93 (Quit: Bye ;)) 00.01.22 Quit Totalled (Ping timeout: 245 seconds) 00.05.36 Quit n1s (Ping timeout: 240 seconds) 00.07.15 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 00.10.16 Quit perrikwp (Ping timeout: 264 seconds) 00.12.17 Join amayer [0] (~amayer@h190.51.21.98.dynamic.ip.windstream.net) 00.16.42 Join Totalled [0] (~Totalled@c-98-245-9-211.hsd1.co.comcast.net) 00.21.28 Quit TheDarkPirate (Quit: Leaving.) 00.23.28 Quit Totalled (Ping timeout: 264 seconds) 00.23.52 Quit kevku (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) 00.26.57 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 00.27.19 Join Totalled [0] (~Totalled@c-98-245-9-211.hsd1.co.comcast.net) 00.29.55 Quit perrikwp_ (Ping timeout: 272 seconds) 00.54.29 Quit eckoit (Quit: eckoit) 00.55.10 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 00.57.41 Quit perrikwp (Ping timeout: 246 seconds) 01.01.11 Quit mgottschlag (Ping timeout: 246 seconds) 01.01.41 # freqmod, something goes wrong if I try to seek to granule 0 with opus 01.07.58 Quit ender (Quit: When one person suffers from a delusion it is called insanity. When many people suffer from a delusion it is called religion. -- Robert Pirsig) 01.15.21 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 01.17.48 Quit perrikwp_ (Ping timeout: 246 seconds) 01.18.04 Quit Prodicus (Ping timeout: 248 seconds) 01.18.54 Join Prodicus [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) 01.24.10 # do i need any of the add-ons to use git with rockbox code? 01.24.44 # add-ons? 01.25.30 # you need the git-core package, and I think that has all the git stuff you need 01.25.33 # i looked it up in the ubuntu software center and it has: 01.25.34 # git-arch 01.25.36 # git-cvs 01.25.38 # git-daemon-run 01.26.45 # so just git not any of the other stuff? 01.26.53 # right 01.27.32 # if you cant tell im new to the git thing. 01.27.34 # at my work we just use a central server. and yell across the hall to see if anyone is working on the file we need 01.27.51 # but then again it is only 4 of use working on the stuff 01.28.30 # a revision control system is useful even if you're the only person working on something 01.29.00 # im not saying its not useful. i was just saying i have no experience with the like at all 01.29.04 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 01.29.11 # im reading the wiki page tho 01.29.18 # even subversion is better than nothing at all 01.29.36 Quit perrikwp (Ping timeout: 240 seconds) 01.34.23 # haha we have a nas that does backups 01.34.41 Quit mikroflops (Ping timeout: 245 seconds) 01.35.27 # we are a pretty small firm. most of the software and web development falls on my lap... and the only thing my boss knows about computers is that his is running windows and mine runs linux(but he doesnt know what that means either) 01.35.34 # * gevaerts would like to point out that discussion of why VCSes and backup tools are different things is a #rockbox-community matter 01.35.54 # gevaerts: sorry 01.36.39 Join mikroflops [0] (~yogurt@h-34-21.a238.priv.bahnhof.se) 01.42.23 *** Saving seen data "./dancer.seen" 01.47.58 Quit perrikwp_ (Read error: Operation timed out) 01.48.07 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 01.50.54 Join saratoga [0] (98032941@gateway/web/freenode/ip.152.3.41.65) 01.51.22 # new resampler is pretty much ready to go aside from optimization 01.51.31 # so 48k with opus shouldn't be an issue 01.56.53 Quit pamaury (Remote host closed the connection) 01.57.15 # saratoga: does the hardware rockbox runs on not output 48KHz? 01.57.36 # gmaxwell: most devices do, but we operate our DSP pipeline at 44.1k 01.57.45 # Bummer. 01.58.08 # very little music actually uses 48k, so we never bothered to have good quality for it 01.58.36 # Hopefully none of thoe devices have AC97 codecs. :) 02.00.23 # pretty much the same thing 02.01.15 # How much work would be involved in getting native 48k playback? What stuff would have to be rewritten? 02.01.38 # Prodicus: we decided it wasn't worthwhile 02.02.07 # or at least not supporting multiple sampling rates 02.02.13 # I'd expect that fully switching to 48k shoudln't be too tricky, but that doesn't really solve anything 02.02.30 # i guess you could do a compile that was always 48k without a huge amount of work 02.02.43 # but yeah everything else gets resampled 02.04.05 # Interesting. Is your current resampler particularly efficient for small fractions i.e. would 24k, 16k playback also benefit from a version compiled for 48k output? 02.04.33 # right now its just linear interpolation, so the ratio doesn't really matter 02.05.05 # oof. 02.05.21 # ugh 02.05.29 # g#304 is hermite, which also probably doesn't care too much (although i guess all interpolations work better going from very high sampling rates to much lower ones) 02.05.31 # 3Gerrit review #304 at http://gerrit.rockbox.org/r/304 : Introduce new hermite polynomial resampler. by Michael Giacomelli (changes/04/304/1) 02.05.42 # with 48k to 44.1k... directly? 02.06.07 # 17:00 < saratoga> pretty much the same thing 02.06.14 # what is pretty much the same thing? 02.06.49 # the DACs we use are basically the same as AC97, although obviously with I2S or whatever as the interface instead of PCI 02.07.14 # The resampler is an old issue. I'd say too many of us have tin ears, so we haven't been motivated to fix it 02.07.15 # or does AC97 not use PCI? 02.07.48 # saratoga: well virtually (?) all AC97 dacs are horrible at 44.1k because they internally run at some multiple of 48k and there is a very low precision linear resampler for other rates. 02.08.12 # gmaxwell: thats just a software thing, you can clock a DAC at whatever you want if you don't care about windows compatibility 02.08.26 Join Syconaut^ [0] (viper@c-4dfd72d5.162-1-64736c10.cust.bredbandsbolaget.se) 02.09.24 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 02.09.50 # saratoga: if you have an oscillator which can be divided down the a relevant rate... but it's not like 48k and 44100 are both common denominators for many possible clocks. 02.10.27 # gmaxwell: the oscillator depends on the system, not the DAC, and virtually all systems have dividers for both sample rates 02.10.55 # since we can control the PLL and dividers we usually don't have much trouble, although sometimes it can be tricky to get the clock just right without breaking something else 02.11.08 # Okay thats good then! 02.11.41 # but yeah, an AC97 DAC and a mp3 player DAC are not much different aside from the digital interface 02.12.01 # actually there is very little difference between any modern DACs 02.12.03 Quit Syconaut (Ping timeout: 248 seconds) 02.12.24 Quit perrikwp (Ping timeout: 246 seconds) 02.13.34 # Sure, I was just under the impression that the crap linear resampling and the lack of ability to run 44.1k was something specific to the interface used on AC97 since its the only place where I've seen it be an obvious issue on PC hardware (/linux drivers). 02.14.20 # AC97 defines some chipset level interface that requires 48k (or maybe some other sampling rates) 02.15.07 # but if you're not hooked up to an intel chipset, thats not a problem 02.15.45 Join Prodicus_ [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) 02.15.54 Quit Prodicus (Ping timeout: 246 seconds) 02.16.04 Nick Prodicus_ is now known as Prodicus (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) 02.17.57 # i guess the downside of not using AC97 is that we have to write drivers for each and every DAC 02.21.33 # i'm really not understanding the ASM code we have for the linear resampler 02.21.52 # its somehow gigantic even though its just taking the weighted average of two numbers? 02.24.58 # I've been thinking that once the rockbox opus support is solid and the opus experimental vbr etc encoder stuff is released I'll reencode my entire collection in opus and flash my clip zip. So I would personally be interested in a 48k-native version as I'd no longer be worried about 22/44 kHz playback. 02.27.37 Quit bertrik (Ping timeout: 246 seconds) 02.28.40 # do different media types use different kHz or is it a hardware thing? 02.28.57 # opus uses 48k internally 02.29.06 # all other formats support various sampling rates 02.29.18 Quit lebellium (Quit: ChatZilla 0.9.88.2 [Firefox 15.0/20120724191344]) 02.32.19 # so opus is only 48k? 02.32.52 # yeah 02.34.29 # Opus encoding and playback tools can deal with any sample rates. But internally it uses 48k (and a handful of integer divisors) and requires resampling for other output rates. 02.36.07 # So by avoiding the final-stage resampler, 48k playback would be a bit more efficient and avoid some distortion. 02.36.49 # is this about us still using 44k for everything internally? :> 02.37.00 # yeah 02.37.03 # blame coldfire 02.37.08 # no 02.37.10 # blame iriver! 02.37.34 # its not just that, its too difficult to switch sample rates and would break too much 02.37.46 # too difficult in what way? 02.37.57 # reclocking during playback without glitching is not simple 02.38.02 # during playback? 02.38.06 # why would you do that? 02.38.31 # if you don't want to resample then sooner or later you'll have to reclock 02.38.57 # well sure, but you won't be doing it during playback 02.39.17 # between tracks/albums instead 02.39.21 # stopping playback => really long glitch 02.39.26 # not really long 02.39.27 # longish 02.39.42 # like what? 250ms max? 02.39.51 # 17:36 < Prodicus> So by avoiding the final-stage resampler, 48k playback would be a bit more efficient and avoid some distortion. 02.39.58 # its less annoying to just properly resample 02.40.12 # no glitch, and good resampling isn't actually that expensive 02.40.15 # normally you don't have any reason to worry about distortion from a competently written resampler.. but linear isn't competent. :( Fast though. 02.40.35 # linear is a throwback from when doing better meant having choppy playback 02.40.44 # gmaxwell: exactly. 02.40.49 # even fairly good resamplers can be pretty fast. 02.41.05 # sure 02.41.06 # write it 02.41.22 # i did :) 02.41.32 # patch up? 02.41.49 # http://gerrit.rockbox.org/r/#/c/304/ 02.42.04 # awesome 02.42.29 # was thinking about trying a higher order polynomial as well 02.42.34 # but this is still enormously better 02.42.52 # that looks awfully much like pure hermite 02.42.59 # it is 02.43.04 # what happened to the upsampling? 02.43.14 # oh haven't done that yet 02.43.19 # but it's in the works? 02.43.28 # hermite spline is an improvement, but not by much 02.43.31 # well i made a filter in matlab, but thats it :) 02.44.06 # well, i can't talk, all i did was start reading the code of the speex resampler 02.44.18 # whats it do? 02.44.29 # jean-marc spoke so convincingly of it to me i felt i had to have a look at it 02.44.45 # it's fir based 02.45.00 # as far as i know i think it's a variant of the jos resampler 02.45.03 # fixed ratios only then? 02.45.06 # but it kinda does it two ways 02.45.11 # no, i don't think so 02.45.21 # It has code to update the filters. 02.45.24 # is it in our code? 02.45.27 # nope 02.45.29 # i think i left it out 02.45.41 # it not being needed to compile speex 02.45.58 # Don't ask me how that works. It's pretty good though... might not be fast enough in fixed point for you though. It's also not terribly large. 02.46.11 # gmaxwell: the cheap mode would work good for our faster targets 02.47.06 # http://git.rockbox.org/?p=rockbox.git;a=blob;f=lib/rbcodec/codecs/libspeex/resample.c;h=65dfef28a3dc684e56bb42e3157714490d5d13c5;hb=HEAD 02.47.13 # that would be it :> 02.47.27 # it's basically untouched since that rev 02.47.30 # so that's it 02.47.34 # re gmaxwell's comment 6min ago: Sometimes a moderately competent resampler can still be noticeable for other reasons. For instance I've found that using SoX's resampler rather than allowing LAME to use its internal polyphase resampler gives a noticeable quality difference when you're downsampling to 16k. Probably because of the wider passband and flatter response in the passband. 02.48.19 # Prodicus: well it matters a lot more for lower frequencies than it does near 44.1k/48k. 02.48.23 # Prodicus: in who's favour? 02.48.29 # little differences in the passband can be noticable. 02.48.30 # gmaxwell:sure 02.48.46 # i doubt they're very different in most of the passband 02.49.02 # preglow: right but the cutoff is audiable. 02.49.07 # yep 02.49.13 # SoX's. Its default resampler is rather high quality and has a passband of 95% 02.49.15 # that's usually where you hear the difference 02.49.21 # Prodicus: yep, as expected 02.49.27 # heh speex also uses kissfft 02.49.33 # sox's resampler is of the usual overkill sinc type 02.49.39 # did you ever optimize speex's ffts? 02.49.46 # speex doesn't use any for decode 02.49.50 # nor encode, i think 02.50.03 # Oh it uses fft in encode for sure, at least now. 02.50.08 # But not for decode. 02.50.25 # decode is pretty much pure filterbank fidgetry 02.50.30 # Current speex has a toy version of the vorbis psymodel for noise shaping. 02.50.52 # ah ok 02.51.12 # gmaxwell: there's no reason for it to use ffts for encode, really, celp encoders usually never did, at least 02.51.27 # sounds more like an echo canceller thing 02.53.03 # the psy model certainly would need it 02.53.50 # The noice canceler and AEC use it too. 02.53.59 # i love giving opinions without doing a grep :> 02.54.22 # well, I haven't looked at the speex code in years either. so ::shrugs:: 02.54.49 # haven't looked at it since i put in the decoder, but i never looked much at the encoder then either 02.55.18 # just talking off a vague understanding of celp encoders in general 02.56.42 # You'll have fun looking at opus' linear predictive coder hah. 02.56.46 # but jm knows what he's about, having a look at the resampler would be clever 02.57.01 # which part of opus? i've had a look at celt 02.57.13 Part amayer 02.57.13 # the speech coder is basicaly silk, afaik 02.57.41 # is his resampler fast? 02.57.46 # Yes, silk is a acelp codec which spent far too long being overdesigned. :) 02.57.50 # IMO we just need one good enough for portable use 02.57.56 # saratoga: he claimed it was meant for embedded platforms 02.57.58 Join amayer [0] (~amayer@h190.51.21.98.dynamic.ip.windstream.net) 02.57.58 # saratoga: it can be, variable quality. 02.58.13 # saratoga: also that he made it just so resamplers like mine would never have to be made again :> 02.58.26 # i didn't buy it completely at the time, but those were different times 02.58.26 # ok i'll have to look at it 02.58.30 # but so much code 02.58.38 # doesn't opus include an updated copy of the speex resampler code? 02.58.45 # saratoga: the silk in opus is substantially change from the original silk— the overall design is the same but all the details changed (though there still are some dumb things in it, oh well) 02.58.50 # Prodicus: opus-tools. 02.58.55 # Prodicus: it shouldn't, speex is no part of opus 02.59.23 # Prodicus: ah, resampler, nvm 02.59.28 # not because it uses speex, because xiph had working code and reused it. 02.59.34 # Prodicus: but the only 'update' is fixing a multichannel bug with weird sampling rates that have enormous prime factors. 02.59.40 # ah. 03.00.02 # saratoga: the core is quite simple, really 03.00.20 # saratoga: possibly not simple to optimize... 03.00.26 # multi also means 2 so it might be relevant for you, if you care about 22047 hz 0_o. 03.01.14 # that it's a fir resampler makes the critical path fairly easy to optimize. 03.01.28 # i'd start with porting the _direct one anyway 03.02.45 # well direct uses a fairly large amount of memory for 44.1k/48k. I'm using direct for that in opus-tools now, but it's not the default for the version in the speex code for that ratio. 03.02.59 # yeah, it doesn't perform too well for that 03.02.59 # certantly easy to make fast, it's just a multiply add loop. 03.03.22 # but few things do unless you do it a bit more elaborately 03.03.25 # preglow: well on x86 desktops direct is a bunch faster even for 44.1k/48k which is why opus-tools uses it now. 03.03.55 # what, resampling is a concern on x86 desktops? :P 03.04.04 # (just because it has fewer multiplies.. of course this is for quality 5.. q=1 probably not :) ) 03.04.43 # preglow: upsampling 44.1k -> 48k for input. 03.05.13 # Opus-tools also preserves the original rate by default on decode, and exact sample length— just because that the expectation for a file encode/decode tool. 03.06.02 # I didn't think the performance really mattered but I got people asking me to add crazy features because they wanted to use the sox resampler because it was faster. 03.07.03 # So there was twiddling to get it faster to make the crazy feature requests go away. :) 03.08.35 # so basically its 4x oversampled lagrange using a 32 tap oversampling filter 03.08.52 # for 82.3% cutoff ( ~60 dB stop) 03.08.54 Quit Rower85 (Quit: Hmmm...) 03.27.45 Join eckoit [0] (~ryan@50.65.10.24) 03.42.27 *** Saving seen data "./dancer.seen" 04.02.56 Join zz_TheSphinX^ [0] (~briehl@p5B321732.dip.t-dialin.net) 04.06.22 Quit TheSphin_ (Ping timeout: 245 seconds) 04.09.44 Quit TheSeven (Disconnected by services) 04.09.53 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 04.17.56 # what is your email used for in git? 04.19.22 Quit Totalled (Ping timeout: 244 seconds) 04.27.36 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.27.37 Quit pixelma (Disconnected by services) 04.27.41 Quit amiconn (Disconnected by services) 04.27.41 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.27.46 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.29.13 # it shows up on all your commits 04.29.17 # its basically your username 04.29.19 # amayer: 04.29.34 Quit saratoga (Quit: Page closed) 04.29.58 # saratoga: so we wont get emails everytime there is a commit or something? 04.30.25 # its just like a signature? 04.31.31 Quit Thra11 (Ping timeout: 246 seconds) 04.46.18 Quit eckoit (Quit: eckoit) 05.11.01 # how do i compile the uisimulator? 05.11.26 # i just set up git(no ssh yet) and would like to test a theme i am making 05.11.28 # (baby steps) 05.11.57 # im on linux btw 05.31.38 Join Totalled [0] (~Totalled@c-98-245-9-211.hsd1.co.comcast.net) 05.42.29 *** Saving seen data "./dancer.seen" 05.55.12 Join Amqui [0] (~a@d50-99-201-71.abhsia.telus.net) 05.55.18 # good evening 06.04.50 # Amqui: hello 06.17.24 Quit scorche (Ping timeout: 248 seconds) 06.23.59 Join scorche [0] (~scorche@rockbox/administrator/scorche) 06.26.35 Nick perrikwp_ is now known as perrikwp (~quassel@cpe-024-163-024-033.triad.res.rr.com) 07.03.36 Join kevku [0] (x@heaaqi4aafadxgaamaafaadyaby.dyn.reverse.name) 07.05.17 Quit Prodicus (Quit: ChatZilla 0.9.88.2 [Firefox 10.0.2/20120216092139]) 07.10.14 Part amayer 07.42.32 *** Saving seen data "./dancer.seen" 08.39.01 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 08.39.05 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 09.02.32 Join stoffel [0] (~quassel@pD9E438F9.dip.t-dialin.net) 09.17.55 Join pretty_function [0] (~sigBART@123.252.213.191) 09.18.13 Quit Totalled (Read error: Connection reset by peer) 09.18.19 Join Totalled [0] (~Totalled@c-98-245-9-211.hsd1.co.comcast.net) 09.42.11 Join ender` [0] (krneki@foo.eternallybored.org) 09.42.33 *** Saving seen data "./dancer.seen" 09.45.26 Quit [Saint] (Remote host closed the connection) 09.57.38 Join megal0maniac [0] (~megal0man@196.213.53.210) 10.04.55 Join mgottschlag [0] (~quassel@HSI-KBW-46-223-232-253.hsi.kabel-badenwuerttemberg.de) 10.04.56 Quit mgottschlag (Changing host) 10.04.56 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 10.28.01 Quit mystica555 (Remote host closed the connection) 10.30.08 Join mystica555 [0] (~Mike@71-211-209-19.hlrn.qwest.net) 10.36.20 Join [Saint] [0] (~sinner@unaffiliated/saint/x-8516940) 10.48.18 Quit pretty_function (Ping timeout: 246 seconds) 10.54.21 Quit mikroflops (Ping timeout: 246 seconds) 10.56.26 Join mikroflops [0] (~yogurt@h-34-21.a238.priv.bahnhof.se) 11.02.47 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 11.02.47 Quit bertrik (Changing host) 11.02.47 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 11.04.38 Join pretty_function [0] (~sigBART@123.252.213.191) 11.12.49 # bertrik: hmm 11.13.04 # the seeking does probably seek to the first packet which is the header 11.13.27 Quit fs-bluebot (Ping timeout: 245 seconds) 11.14.44 Join fs-bluebot [0] (~fs-bluebo@g231120239.adsl.alicedsl.de) 11.15.06 Quit bluebrother (Ping timeout: 245 seconds) 11.17.05 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 11.19.59 Join pamaury [0] (~quassel@cez63-2-88-164-98-172.fbx.proxad.net) 11.20.00 Quit pamaury (Changing host) 11.20.00 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.42.35 *** Saving seen data "./dancer.seen" 11.44.54 Join lebellium [0] (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr) 11.49.18 Quit Wardo (Ping timeout: 246 seconds) 11.59.27 Join stoffel_ [0] (~quassel@pD9E4307D.dip.t-dialin.net) 11.59.42 Quit stoffel (Ping timeout: 246 seconds) 12.29.08 Join Ward [0] (~Mirandaha@bpb01-1-88-162-4-186.fbx.proxad.net) 12.29.33 Nick Ward is now known as Guest49978 (~Mirandaha@bpb01-1-88-162-4-186.fbx.proxad.net) 12.31.35 Quit pretty_function (Read error: Connection reset by peer) 12.31.45 Join pretty_function [0] (~sigBART@123.252.213.191) 12.34.05 Join n1s [0] (~n1s@nl118-168-30.student.uu.se) 12.34.06 Quit n1s (Changing host) 12.34.06 Join n1s [0] (~n1s@rockbox/developer/n1s) 12.49.16 Quit pretty_function (Ping timeout: 264 seconds) 13.03.09 # please ban user "loving" from the forums, posting spam 13.05.38 # That was quick 13.07.09 # * n1s wonders why the opus codec doesn't just statically alloc its buffers, they are statically sized and live as long as the codec runs afaict 13.07.21 # and malloc w/o free looks weird 13.07.42 # (and the codec_free function doesn't actually do anything :)) 13.09.05 # and wow, it's a lot of files 13.10.43 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 13.11.43 # bertrik: are silk and celt separate codecs? 13.12.24 # no, 13.13.27 # silk is based on some skype codec, but it's heavily modified for use in opus. celt was a codec research project from xiph as I understand. 13.14.46 # roughly, silk does low-frequency linear prediction coding and celt does mdct stuff for the higher frequencies, opus is the combination of the two 13.14.57 # ah 13.15.21 # any idea if it can use the mdct lib we have in the codec lib? 13.16.22 # I don't know, I vaguely remember either saratoga or jhMikeS discussing this with the opus guys, the mdct size used was different IIRC 13.21.00 # seems the fixed point representation it uses is different too but not sure whow hard that would be to change 13.22.18 # might be fun to write some asm for it but i guess i'll wait untill it's in the repo 13.42.37 *** Saving seen data "./dancer.seen" 13.53.27 Quit mgottschlag (Ping timeout: 246 seconds) 14.02.40 Quit stoffel_ (Ping timeout: 244 seconds) 14.13.18 # bertrik: done 14.14.15 # n1s: multithreading. We don't run a codec multiple times from the same process, but some people do. You can;t statically allocate buffers then 14.17.50 # gevaerts: we do that in pretty much all codecs, i only saw mallocs in the rockbox specific main codec file, are there other places too? 14.18.43 Join petur [0] (~petur@rockbox/developer/petur) 14.21.10 # Ah, right. Yes, I think part of that will need static allocation, if only to get the right bits into iram 14.22.08 # ah yes, avoiding the horrible iram malloc thing used in vorbsi would be nice :) 14.22.49 # i guess i'll take a closer look at it when it gets pushed 14.36.55 Join Thra11 [0] (~thrall@23.123.112.87.dyn.plus.net) 14.39.21 Quit mikroflops (Ping timeout: 244 seconds) 14.43.46 Join mikroflops [0] (~yogurt@h-34-21.a238.priv.bahnhof.se) 14.44.24 # not everything can be static when decoding opus 14.44.26 Join stoffel [0] (~quassel@pD9E4307D.dip.t-dialin.net) 14.44.41 # like we don't always know how big some buffers need to be in advance 14.45.12 # you might not like the mallocs, but it's very practical and doesn't require all kinds of deep changes the make later upstream sync a lot harder 14.45.46 # so there are allocs in the actual codec? i was under the impression there wasn't 14.45.49 # there is no malloc / free during the playback phase, only during init 14.46.12 # there is an ogg layer too 14.46.31 # and the opus does a few mallocs, yes 14.46.33 Join pretty_function [0] (~sigBART@123.252.212.79) 14.47.05 # ah yes, managed to not think about the god damned ogg container 14.47.54 # I wonder how heavy the ogg stuff is, it does quite a bit of memcpy/memmoving to assemble pages 14.48.02 # and it does CRC checks 14.48.48 # i benchmarked disabling the crc, was about 1-2% of total cpu on cf for vorbis iirc 14.49.17 # ok, interesting, I would have guessed more impact 14.50.39 Quit [Saint] (Remote host closed the connection) 14.51.46 # sorry, about 1% on PP apparentyl 14.51.53 # http://www.rockbox.org/mail/archive/rockbox-dev-archive-2010-06/0303.shtml if you're interested 14.51.56 # We don't often sync codecs with upstream, do we? 14.52.02 # not really 14.53.12 # apparently people want to keep the crc check for vorbis, some other formats have similar checksums but their decoders don't check it (flac iirc) 14.54.07 # my feeling is that if you get files spontaneously corrupted, you have larger problems than playing back some garbage or crashing the codec 14.54.32 Join [Saint] [0] (~sinner@unaffiliated/saint/x-8516940) 14.56.10 # I agree 14.57.10 # but it's not very expensive (and the crc in tremor isn't exactly optimized, reading a char-at-a-time) 14.59.15 Quit mikroflops (Ping timeout: 246 seconds) 15.13.35 Quit megal0maniac (Quit: megal0maniac) 15.16.31 Join mikroflops [0] (~yogurt@h-34-21.a238.priv.bahnhof.se) 15.17.28 Quit n1s (Ping timeout: 264 seconds) 15.23.17 Join Thra11_ [0] (~thrall@31.185.149.61) 15.23.47 Quit Thra11 (Ping timeout: 244 seconds) 15.39.03 Join Thra11 [0] (~thrall@31.185.149.61) 15.39.55 Quit Thra11_ (Ping timeout: 246 seconds) 15.42.38 *** Saving seen data "./dancer.seen" 15.48.25 Join mgottschlag [0] (~quassel@HSI-KBW-46-223-232-253.hsi.kabel-badenwuerttemberg.de) 15.48.25 Quit mgottschlag (Changing host) 15.48.25 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 16.00.21 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 16.05.37 Join XavierGr [0] (~xavier@rockbox/staff/XavierGr) 16.23.35 Quit pretty_function (Ping timeout: 240 seconds) 16.38.18 Quit mc2739 (Ping timeout: 260 seconds) 16.44.43 Join pretty_function [0] (~sigBART@123.252.212.79) 16.46.45 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 16.50.21 Quit Guest49978 (Quit: Blarglarg) 16.54.45 Join n1s [0] (~n1s@rockbox/developer/n1s) 16.55.09 Quit benedikt93 (Quit: Bye ;)) 17.01.01 Quit petur (Quit: Leaving) 17.03.29 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 17.14.18 Quit [Saint] (Read error: Connection reset by peer) 17.15.39 Join [Saint] [0] (~sinner@unaffiliated/saint/x-8516940) 17.18.43 # <[Saint]> Hmmmm... 17.24.13 # <[Saint]> the yp-r0 toolchain is pretty nuts. 17.42.42 *** Saving seen data "./dancer.seen" 17.42.46 Quit pretty_function (Ping timeout: 244 seconds) 17.44.51 Quit n1s (Quit: Ex-Chat) 17.53.22 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 17.56.00 Quit perrikwp (Ping timeout: 246 seconds) 17.57.27 Join eckoit [0] (~ryan@50.65.10.24) 17.58.10 Quit stoffel (Read error: Operation timed out) 18.50.06 Quit eckoit (Quit: eckoit) 18.54.37 Join Thra11_ [0] (~thrall@75.56.113.87.dyn.plus.net) 18.56.28 Quit Thra11 (Ping timeout: 264 seconds) 19.11.17 Join eckoit [0] (~ryan@50.65.10.24) 19.16.51 Join pretty_function [0] (~sigBART@123.252.212.79) 19.22.50 Quit pretty_function (Remote host closed the connection) 19.42.44 *** Saving seen data "./dancer.seen" 19.50.41 Join stoffel [0] (~quassel@pD9E4307D.dip.t-dialin.net) 19.57.01 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 19.59.11 Join perrikwp__ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 19.59.35 Quit perrikwp_ (Ping timeout: 240 seconds) 20.01.45 Quit perrikwp (Ping timeout: 244 seconds) 20.07.03 Nick perrikwp__ is now known as perrikwp (~quassel@cpe-024-163-024-033.triad.res.rr.com) 20.50.44 Quit Totalled (Quit: PETTAN PETTAN, TSURUPETTAN!) 20.52.23 Quit stoffel (Ping timeout: 244 seconds) 21.03.26 Join Wardo [0] (~Mirandaha@bpb01-1-88-162-4-186.fbx.proxad.net) 21.03.40 Join pretty_function [0] (~sigBART@123.252.212.79) 21.04.17 Join lebellium_ [0] (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr) 21.05.18 Join lebellium__ [0] (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr) 21.06.30 Join lebellium___ [0] (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr) 21.06.30 *** Alert Mode level 1 21.06.30 DBUG Enqueued KICK lebellium 21.06.30 DBUG Enqueued KICK lebellium_ 21.06.30 *** Alert Mode level 2 21.06.30 DBUG Enqueued KICK lebellium__ 21.06.30 DBUG Enqueued KICK lebellium___ 21.06.30 *** Alert Mode level 3 21.07.05 Quit lebellium (Ping timeout: 246 seconds) 21.07.10 Nick lebellium___ is now known as lebellium (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr) 21.07.10 DBUG Enqueued KICK lebellium 21.07.10 *** Alert Mode level 4 21.08.59 Quit lebellium_ (Ping timeout: 250 seconds) 21.09.51 Quit lebellium__ (Ping timeout: 250 seconds) 21.10.37 Quit Thra11_ (Ping timeout: 272 seconds) 21.17.11 *** Alert Mode OFF 21.40.50 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 21.42.48 *** Saving seen data "./dancer.seen" 21.43.31 Quit perrikwp (Ping timeout: 246 seconds) 22.30.22 Quit pretty_function (Read error: Operation timed out) 22.36.59 Join TheDarkPirate [0] (~ricardo@190.202.154.188) 22.38.10 Quit TheDarkPirate (Client Quit) 22.38.18 Join TheDarkPirate [0] (~ricardo@190.202.154.188) 22.44.34 Quit y4n (Quit: PANTS OFF!) 22.48.12 Quit mystica555 (Remote host closed the connection) 23.11.41 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 23.27.14 Quit perrikwp_ (Read error: Connection reset by peer) 23.39.11 Quit benedikt93 (Quit: Bye ;)) 23.42.51 *** Saving seen data "./dancer.seen" 23.53.48 Quit jfc (Ping timeout: 248 seconds)