--- Log for 23.10.105 Server: clarke.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 1 day and 15 hours ago 00.08.13 Join XavierGr_ [0] (n=XavierGr@ppp13-adsl-171.ath.forthnet.gr) 00.08.18 Quit XavierGr_ (Client Quit) 00.08.49 Join XavierGr_ [0] (n=XavierGr@ppp13-adsl-171.ath.forthnet.gr) 00.16.23 # I've now got the ffmpeg FLAC decoder working in Rockbox. It seems to be happy at 45MHz :) 00.16.38 *** Saving seen data "./dancer.seen" 00.17.35 # Wow.. nice :) 00.18.57 # Slasheri: Voice working fine again. 00.19.20 # There is the very occasional boost, but it's almost always at 45MHz. 00.19.22 # The old clip preemption problem is still there though 00.19.50 # I haven't implemented seeking yet, and it still needs lots of yields inserting into it. But apart from that, it's working well. 00.19.53 # linuxstb__: Is that with files compressed with -8 ? 00.21.00 # I'm not sure - I only have one album on my iriver at the moment, and I can't remember the compression settings. I'll do some more tests. 00.30.35 Join DrMoos [0] (i=DrMoos@m79.net81-66-158.noos.fr) 00.32.36 Quit XavierGr (Read error: 110 (Connection timed out)) 00.34.55 Quit ender` (Read error: 104 (Connection reset by peer)) 00.39.52 Quit JoeBorn ("http://groups.google.com/group/Neuros-DM320Hardware") 00.40.43 # amiconn: Yes, it works at the same speed with some -8 files. 00.41.09 # I still have about 12KB of IRAM to use in some way as well. 00.41.27 # And this is without any EMAC routines either. 00.43.38 # wow 45MHz only? 00.43.48 Join arkascha [0] (n=arkascha@xdsl-213-168-108-196.netcologne.de) 00.43.53 # What about WAV, how much juice does it needs? 00.44.50 Quit Moos (Read error: 110 (Connection timed out)) 00.45.07 # I don't think anyone has every bothered to benchmark WAV. 00.45.13 # s/every/ever/ 00.45.43 # I mean WAV should be the most easy and less consuming right? 00.46.08 # aiff would be even easier if it was implemented 00.46.23 # (no byteswap on coldfire since it's big endian) 00.46.38 # Ironically, WAV would be better on the ipod though... 00.47.56 # maybe it will be good to build a percent table of all codecs (realtime percent). It would be fun to see this. 00.48.16 # XavierGr_: We have no way to measure that at the moment. 00.48.35 # All we have is the "boost ratio" - which isn't very useful. 00.48.55 # what about xxx2wav 00.48.58 # ? 00.49.24 # It hasn't existed for a long time (and was finally removed from CVS today). 00.49.34 # oh yes 00.50.21 # then we could make a little utility that calculates how much time the CPU spend in each frequency level. 00.50.58 Quit DrMoos (Read error: 110 (Connection timed out)) 00.51.54 # but i guess that would be difficult, to measure this while the pll changes 00.54.31 # We need a better measurement than that though - e.g. if two codecs are both working realtime at 45MHz, we don't know which is faster. 00.54.57 # Measuring the CPU time spent at each frequency level would be relatively simple, but that still wouldn't tell us much about codec performance 00.55.15 # Similarly, if we try to optimise a codec that's already at 45MHz, we don't know how much a change improves it. 00.55.17 # When there's nothing to do, the CPU goes to sleep 01.10.19 Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) 01.15.09 # linuxstb__: did anyone answer your dsp question? 01.15.27 # About 16-bit ints in 32-bit arrays? 01.15.27 # linuxstb__: if not, you set SAMPLE_DEPTH to 16, and use pcmbug_insert_split 01.16.15 # How does the DSP know I'm using 32-bit arrays, and not 16-bit arrays for each channel? 01.16.23 # hmm, that's a problem 01.16.33 # it'll probably assume 16 bit array values :/ 01.16.40 # Slasheri suggested adding an extra config option for array size. 01.16.46 # yes, so do i 01.16.49 # absolutely 01.18.05 # Does the DSP make use of the input buffers when processing? i.e. does it work in-place? 01.21.46 # it depends 01.21.57 # if the format is deinterleaved, then yes 01.21.59 # i think it does 01.22.32 # if it's interleaved, i believe it deinterleaves the data to a temp buffer 01.23.00 Quit arkascha (Read error: 104 (Connection reset by peer)) 01.24.03 # linuxstb__: What's the problem with 16 bit ints in 32 bit arrays? 01.24.37 # amiconn: problem is dsp assumes sixteen bit data type size if you say sample size is sixtee nbits 01.25.21 # Hmm. I thought data fed to the dsp is always 32 bit, and you only set the number of bits used? 01.25.42 # nope 01.26.12 # Hmm. 01.26.36 # Otoh, why would one place 16 bit ints in 32 bit arrays? Sounds like a space waste... 01.27.34 # because 32 bits is the internal format 01.27.37 # FLAC uses 32-bit ints internally. In my ffmpeg-based decoder, I've kept it. 01.27.40 # if it's not 32 bits, it needs to be converted internally 01.28.11 Ctcp Ignored 2 channel CTCP requests in 8 minutes and 30 seconds at the last flood 01.28.11 # * HCl stretches and looks around 01.28.31 # hi hcl 01.28.59 # preglow: Would it be much work to add support for 24-bit audio. Or is it already there? 01.29.06 # like how? 01.29.06 # * amiconn still doesn't understand 01.29.09 # I'm thinking about 24-bit FLAC files. 01.29.14 # ahh, like that 01.29.18 # support is already there 01.29.32 # If 32 bit is the internal format, where do the 16 bit ints originate? 01.29.34 # i believe my emac optimised lpc routine even supports it 01.29.41 # amiconn: from lossless codecs 01.30.16 # Now I'm completely confused 01.30.40 # internal format is 32 bit ints 01.30.51 # the data may be placed however it wants inside those 32 bits 01.31.06 # I think the dsp supports both 16 and 32 bits... so one would use 32 bits with a codec that delivers 32 bits and 16 bitswith a codec that delivers 16 bits 01.31.08 # libmad uses only 24, liba52 30, flac 16 01.31.22 # I don't see the problem here 01.31.40 # problem is the dsp routines would have to be coded twice 01.31.47 # once for 16 bit ints, once for 32 bit ints 01.31.50 # but i need to go for a while 01.31.50 # brb 01.32.07 # Why do the routines need to be coded twice ??? 01.33.05 # Hmmm......... 01.48.30 # well 01.48.49 # can you code an eq that works equally well on 16 bit array data as 32 bit array data? 01.48.53 # i can't 01.49.14 # not without bogging it down with ifs 01.51.29 # You wouldn't need ifs... but then you would read the memory twice for 16 bit data 01.52.13 # How is this handled today? 01.52.35 # it's not, all data is converted to 32 bit data 01.52.40 # If anyone is interested in trying out my new FLAC decoder, I've uploaded a binary here: http://www.davechapman.f2s.com/rockbox/rockbox-newflac.zip 01.52.46 # I'll upload the source if anyone's interested. 01.53.13 # preglow: Ah, but then I don't understand linuxstb__'s question 01.53.34 Nick linuxstb__ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net) 01.54.32 # I think the problem is simply that the DSP assumes 16-bit input arrays if the sample depth is 16-bits. 01.54.44 # yes, and then converts that to 32 bit data internally 01.54.56 # problem is linuxstb has 16 bit data in 32 bit ints, which is what the dsp would have ended up with anyway 01.55.15 # Does it end up in the high or low 16 bits? 01.55.20 # low 01.55.30 # Exactly what I've got then. 01.55.40 # Yes, and why does the dsp take both 16 and 32 bit input if it converts it to 32 bit internally anyway, and spits out 16 bit? 01.56.04 # A bit too many conversions for my taste... 01.56.05 # convenience 01.56.12 # sure, we'll remove the worst cases some day 01.57.58 # What I mean with reading the memory twice is that you can read the 16 bit ints as 32 bits, use the half you want, and then advance the pointer by 2 bytes instead of 4 01.58.15 # At least this is possible on coldfre, but it's somewhat ugly 01.58.53 # but yeah, 16 bit intermediate data is a no go 01.58.57 # we want 32 bit data for dsp 01.59.01 # for precision 01.59.05 # linuxstb: Can I just plug flac.codec into my installation, or does it require core changes? 01.59.27 # I think that should work. 02.00.38 # Things left to do are: Seeking, more internal yields and checking for (and recovering from) errors in the input stream. 02.08.34 # wow... That's what I call performance improvement 02.08.52 # ...and codec size is almost halved 02.09.16 # And not a malloc in sight... 02.11.11 # Boost ratio with my test album (encoded with -8) around 8% atm 02.12.37 # Yes, that's about what I'm getting. 02.13.09 # Does the backlight boost the CPU still? 02.13.41 # Backlight fading does, but I have that disabled atm 02.13.54 # That's slowing my tests down then... 02.16.08 # Did just replacing the flac.codec work? If so, I'll just upload that so others can test. 02.16.16 # Yes 02.16.39 *** Saving seen data "./dancer.seen" 02.17.05 # OK. I've now uploaded just that file: http://www.davechapman.f2s.com/rockbox/flac.codec 02.17.37 # It would be useful if people could test it with their FLAC files before we replace libFLAC with it. 02.22.07 # The main limitation is that I've set a maximum limit on the block size to 4608. This is so that the buffers will fit in IRAM. Every FLAC file I've got has a block size of 4608 (it's the default for the reference flac encoder). 02.23.14 # 4608 pairs of stereo samples @ 32-bits per sample = 36864 bytes. 02.24.12 Quit actionshrimp ("a bird in the bush is worth two in your house") 02.45.42 Join webguest68 [0] (n=53463960@labb.contactor.se) 02.46.29 Quit webguest68 (Client Quit) 02.51.38 Part XavierGr_ 02.55.03 Join ashridah [0] (i=ashridah@220-253-123-97.VIC.netspace.net.au) 03.09.16 Quit merbanan (Read error: 104 (Connection reset by peer)) 03.10.46 Join XavierGr [0] (n=XavierGr@ppp13-adsl-171.ath.forthnet.gr) 03.14.34 Quit matsl (Remote closed the connection) 03.36.25 Nick ashridah is now known as Lost-ash (i=ashridah@220-253-123-97.VIC.netspace.net.au) 03.55.29 Join _user_ [0] (n=18d79b85@labb.contactor.se) 03.55.43 Quit _user_ (Client Quit) 04.05.49 Join _Vladoman [0] (n=Vladoman@p54A7CABE.dip.t-dialin.net) 04.16.41 *** Saving seen data "./dancer.seen" 04.23.10 Quit Vlad0man (Read error: 110 (Connection timed out)) 04.23.28 Quit cYmen ("zZz") 06.10.09 Join Tri-NitroToluene [0] (n=irc@adsl-217-4-93.asm.bellsouth.net) 06.10.19 Quit Tri-NitroToluene () 06.16.42 *** Saving seen data "./dancer.seen" 06.23.20 Quit Moos (Read error: 110 (Connection timed out)) 06.34.28 Quit RotAtoR () 06.50.45 Quit Rick ("I… don't need to be here.") 07.00.06 Join amiconn_ [0] (n=jens@p54BD7146.dip.t-dialin.net) 07.15.32 Join Rick [0] (i=rick@pool-71-108-9-40.lsanca.dsl-w.verizon.net) 07.18.33 Quit amiconn (Read error: 110 (Connection timed out)) 07.18.33 Nick amiconn_ is now known as amiconn (n=jens@p54BD7146.dip.t-dialin.net) 07.41.36 Nick Lost-ash is now known as ashridah (i=ashridah@220-253-123-97.VIC.netspace.net.au) 08.16.45 *** Saving seen data "./dancer.seen" 08.18.01 Join _FireFly_ [0] (n=FireFly@p54A45A7B.dip.t-dialin.net) 08.53.01 Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) 08.56.31 Join Lost-ash [0] (i=ashridah@220-253-121-8.VIC.netspace.net.au) 08.58.08 Quit ashridah (Nick collision from services.) 08.58.18 Nick Lost-ash is now known as ashridah (i=ashridah@220-253-121-8.VIC.netspace.net.au) 09.10.58 Join solexx_ [0] (n=jrschulz@c214077.adsl.hansenet.de) 09.14.30 Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) 09.25.13 Quit solexx (Read error: 110 (Connection timed out)) 09.34.59 Quit Moos (Read error: 104 (Connection reset by peer)) 10.16.48 *** Saving seen data "./dancer.seen" 10.24.57 Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) 10.57.36 Quit XavierGr (Read error: 110 (Connection timed out)) 11.02.04 Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 11.07.15 Join cYmen_ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 11.12.27 Join cYmen__ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 11.12.34 Join merbanan [0] (i=banan@dalink.campus.luth.se) 11.17.40 Join cYmen___ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 11.17.40 *** Alert Mode level 1 11.17.40 DBUG Enqueued KICK cYmen 11.17.40 DBUG Enqueued KICK cYmen_ 11.17.40 *** Alert Mode level 2 11.17.40 DBUG Enqueued KICK cYmen__ 11.17.40 DBUG Enqueued KICK cYmen___ 11.17.40 *** Alert Mode level 3 11.19.51 Quit cYmen (Connection timed out) 11.22.49 Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 11.22.49 *** Alert Mode level 4 11.22.49 *** Alert Mode level 5 11.22.49 DBUG Enqueued KICK cYmen 11.22.49 *** Alert Mode level 6 11.22.49 *** Alert Mode level 7 11.22.49 *** Alert Mode level 8 11.24.09 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 11.24.58 Quit cYmen_ (Connection timed out) 11.27.59 Join cYmen_ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 11.27.59 *** Alert Mode level 9 11.27.59 *** Alert Mode level 10 11.27.59 DBUG Enqueued KICK cYmen_ 11.27.59 *** Alert Mode level 11 11.27.59 *** Alert Mode level 12 11.27.59 *** Alert Mode level 13 11.30.00 Quit cYmen__ (Connection timed out) 11.30.48 Part amiconn 11.33.11 Join cYmen__ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 11.33.11 *** Alert Mode level 14 11.33.11 *** Alert Mode level 15 11.33.11 DBUG Enqueued KICK cYmen__ 11.33.11 *** Alert Mode level 16 11.33.11 *** Alert Mode level 17 11.33.11 *** Alert Mode level 18 11.35.13 Quit cYmen___ (Connection timed out) 11.35.39 # Bagder: Is there a reason that plugins/Makefile still links everything against CODECLIBS ? 11.38.24 Join cYmen___ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 11.38.24 *** Alert Mode level 19 11.38.24 *** Alert Mode level 20 11.38.24 DBUG Enqueued KICK cYmen___ 11.38.24 *** Alert Mode level 21 11.38.24 *** Alert Mode level 22 11.38.24 *** Alert Mode level 23 11.40.51 Quit cYmen (Connection timed out) 11.43.33 Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 11.43.33 *** Alert Mode level 24 11.43.33 *** Alert Mode level 25 11.43.33 DBUG Enqueued KICK cYmen 11.43.33 *** Alert Mode level 26 11.43.33 *** Alert Mode level 27 11.43.33 *** Alert Mode level 28 11.45.39 Quit cYmen_ (Connection timed out) 11.48.43 Join cYmen_ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 11.48.43 *** Alert Mode level 29 11.48.43 *** Alert Mode level 30 11.48.43 DBUG Enqueued KICK cYmen_ 11.48.43 *** Alert Mode level 31 11.48.43 *** Alert Mode level 32 11.48.43 *** Alert Mode level 33 11.50.43 Quit cYmen__ (Connection timed out) 11.53.00 Quit matsl (Remote closed the connection) 11.53.55 Join cYmen__ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 11.53.55 *** Alert Mode level 34 11.53.55 *** Alert Mode level 35 11.53.55 DBUG Enqueued KICK cYmen__ 11.53.55 *** Alert Mode level 36 11.53.55 *** Alert Mode level 37 11.53.55 *** Alert Mode level 38 11.55.17 Part winjer 11.55.52 Quit cYmen___ (Connection timed out) 11.59.07 Join cYmen___ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 11.59.07 *** Alert Mode level 39 11.59.07 *** Alert Mode level 40 11.59.07 DBUG Enqueued KICK cYmen___ 11.59.07 *** Alert Mode level 41 11.59.07 *** Alert Mode level 42 11.59.07 *** Alert Mode level 43 11.59.16 Quit linuxstb (Remote closed the connection) 12.01.25 Quit cYmen (Connection timed out) 12.04.21 Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 12.04.21 *** Alert Mode level 44 12.04.21 *** Alert Mode level 45 12.04.21 DBUG Enqueued KICK cYmen 12.04.21 *** Alert Mode level 46 12.04.21 *** Alert Mode level 47 12.04.21 *** Alert Mode level 48 12.06.21 Quit cYmen_ (Connection timed out) 12.09.11 Join ender` [0] (i=ychat@84.52.165.220) 12.11.30 Quit cYmen__ (Connection timed out) 12.14.22 *** Alert Mode OFF 12.16.36 Quit cYmen___ (Connection timed out) 12.16.51 *** Saving seen data "./dancer.seen" 12.21.54 Quit paugh (Read error: 104 (Connection reset by peer)) 12.22.40 Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 12.29.21 Join San [0] (n=Test@212.2.167.247) 12.29.23 # hey 12.52.35 Join markun [0] (n=karl@bastards.student.ipv6.utwente.nl) 12.52.54 # hi San 12.56.39 # hey 13.01.35 # Are you working on rockbox? 13.01.40 # me? 13.02.07 Join amiconn [0] (n=jens@p54BD6D91.dip.t-dialin.net) 13.02.55 # yes 13.03.34 # nope 13.03.42 # would like though 13.03.43 # :D 13.04.08 # any ideas what you would like to do? 13.05.25 Join arkascha [0] (n=arkascha@xdsl-213-196-211-101.netcologne.de) 13.05.57 # errrmmm 13.10.05 # San: which player do you have? 13.10.14 # H320 13.12.35 # <_FireFly_> linuxstb: could it be true, that your "new" flac decoder has a bit louder output then the "old" one 13.13.32 # _FireFly_: The decoders themselves are identical - they have to be. 13.13.55 # It could be some difference in the DSP processing though. 13.14.10 # <_FireFly_> hmm either the output is louder or the sound is better :) 13.14.32 # Unless there was a bug in the old decoder. I've confirmed the new one gives bit-perfect output (at least on my PC). 13.15.11 Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) 13.17.58 # We really do need a WAV writer in Rockbox - so we can check the accuracy of the decoders. 13.36.06 Join Febs [0] (n=cfac7a51@labb.contactor.se) 13.47.42 # yes :/ 13.49.30 # linuxstb: is there no better use for iram than the pcm buffer in the flac decoder? 13.50.34 # I don't think so. Most of the processing happens in-place in those buffers. The only other major buffer is the input data - but that's too big to go into IRAM as well. 13.50.54 # Do you want to look at my source? 13.51.19 # It could be useful to have some functions in IRAM though. Is that possible? 13.51.43 # yeah, i'd like that 13.51.45 # The entire decoder is only about 8300 bytes 13.51.54 # functions in iram is possible, but not that much to be gained 13.51.56 # holy shit 13.52.06 # why the flaming hell is libFLAC the behemoth it is, then? 13.52.07 # That's the size of flac.codec if I remove the large buffers. 13.52.09 Join _DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) 13.53.00 # I still need to add seeking support, but that won't be that much code. 13.53.53 # I'm currently using about 38KB of IRAM. So there should be room for the entire codec to be there as well. 13.55.18 # you have the code hanging around somewhere? 13.55.28 # I can quickly zip it up for you. 13.55.46 Ctcp Ignored 13 channel CTCP requests in 46 minutes and 41 seconds at the last flood 13.55.46 # * amiconn is planning to do some iram section work on codecs 13.56.49 # http://www.davechapman.f2s.com/rockbox/newflacsrc.zip 13.57.20 # This contains a new "flac.c" and "libffmpegFLAC". If you replace libFLAC with "libffmpegFLAC", then you shouldn't have to change anything else to compile it. 13.58.03 # amiconn: Do you think putting the codec itself in IRAM would be a useful optimisation? 13.59.07 # it will help, yes 13.59.11 # i've done it before 14.00.03 # It's better to put data in iram than code 14.00.26 # sure, but when there's no more data 14.00.39 Join muesli- [0] (i=muesli_t@hmln-d9b8efbb.pool.mediaWays.net) 14.00.52 # Some functions can profit from iram, especially those that are called often, but from all over the place 14.01.03 # hi 14.01.08 # isn't rockbox code supposed to use a four space indent? 14.01.11 # ...and not several times in sequence 14.01.17 # preglow: yes 14.01.25 # * linuxstb hides 14.01.28 # heh 14.01.38 # where are those rules again? i can't find them in the wiki 14.02.30 # In the source - docs/CONTRIBUTING 14.02.45 # linuxstb: and i think you should access the mem* functions through the codec api pointers, and not depend on the functions in codeclib.c 14.02.51 # right 14.02.59 # http://www.rockbox.org/docs/contributing.html 14.03.32 # preglow: I think we need to correct the mem* function mess at some point 14.03.46 # amiconn: yes 14.04.35 # gcc requires that a freestanding environment provides 4 functions: memcpy(), memmove(), memset() and memcmp() 14.05.02 # We need to have a libmem that is linked to the core and to codecs and plugins 14.05.37 # does anyone know how to set up an apache server on XP? 14.05.52 # preglow: I do, but memmove isn't in the codec API struct. 14.05.59 # no? 14.06.01 # hm 14.06.05 Quit Maxime () 14.06.16 # linuxstb: Yes, because rockbox doesn't have memmove() yet 14.07.18 # btw 14.07.24 # i think all codec plugins should enable the dsp at all times 14.07.38 # this will ease the work for us when we remove the enable dsp option 14.08.03 # it'll also spur us to fix the dsp layer if something is wrong with it 14.08.26 Quit DangerousDan (Read error: 110 (Connection timed out)) 14.09.48 # Any suggestions about how to get the new FLAC decoder into CVS? I don't really want to remove the old decoder until the new one has proven itself and has seeking support. 14.10.37 # hmm 14.10.49 # if you post it on the forums or something, i 14.10.55 # if you post it on the forums or something, i'm sure a lot of people will try it 14.11.03 # Yes, I've done that. 14.11.08 # nice 14.11.29 # <_FireFly_> http://forums.rockbox.org/index.php?topic=1687.0 14.11.39 # the volume is louder? 14.11.43 # how can that be? 14.12.15 # <_FireFly_> i have the feeling that the volume is louder 14.12.27 # <_FireFly_> but it could also be that the quality is better 14.12.42 # <_FireFly_> and so i have the feeling that the volume is ouder 14.12.46 # <_FireFly_> louder 14.13.05 # it's lossless 14.13.10 # so i don't quite see how any of them can be true 14.13.17 # we need a wav writer! 14.13.33 # One difference is that the new FLAC decoder doesn't always enable the DSP. 14.14.22 # dsp shouldn't affect the audio unless it's requested 14.14.27 # if it does, it needs to be fixed 14.14.58 # but it's not exactly easy to discover as is 14.16.53 *** Saving seen data "./dancer.seen" 14.18.41 # <_FireFly_> thats only my personal feeling i might be wrong 14.19.50 # there might be something behind it 14.19.55 # and i want to find out, but currently it's not easy 14.27.56 # <_FireFly_> i could record a wav with the song over my pc one when the "new" and one when the "old" flac-codec is use 14.29.16 # optical? 14.29.36 # <_FireFly_> i don't have an optical cable 14.29.59 # then there's not much of a point 14.30.13 # unless the differences are huge 14.30.19 # might as well try if you want to, of course 14.41.24 # I'll change the encoder to always enable the DSP - that's the only possible cause of any difference I can think of. Unless there are bugs in our libFLAC decoder. 14.41.35 # But got to go now. Back later. 14.45.19 # I've just uploaded "dspflac.codec" - same location as the other. I haven't tested it, but it should be OK. The DSP is always enabled, in the same way as the existing FLAC decoder. 14.46.37 # <_FireFly_> hmm it seems that the output is louder of the "new" codec because the wavrec prog has an peakmeter while recording and there where some clibbing 14.46.46 Quit arkascha (Read error: 104 (Connection reset by peer)) 14.48.56 Nick solexx_ is now known as solexx (n=jrschulz@c214077.adsl.hansenet.de) 14.53.20 # by how much? 14.53.43 # <_FireFly_> i will upload a image 14.55.46 # hmm... 14.55.52 # <_FireFly_> http://home.arcor.de/s.wezel/flac-codec-test.jpg 14.55.54 # i just updated to the latest daily build 14.56.00 # and now rockbox just displays "no files" 14.56.15 # and doesn't react to any buttons... 14.56.17 # any ideas? 14.56.33 # <_FireFly_> preglow: i had startet the recording when i pressed the select button to play the file 14.58.43 # is there a way to manually reset the configuration? 15.00.22 Join arkascha [0] (n=arkascha@xdsl-195-14-205-39.netcologne.de) 15.06.16 # <_FireFly_> preglow: with the dspflac.codec file it seems that it's the same as the "old" codec 15.07.08 # _FireFly_: now really 15.07.16 # there's a one bit error some place 15.07.41 # <_FireFly_> ?? 15.07.41 # i'll have a look at it in a sec 15.08.11 # the audio is almost double the amplitude 15.08.17 # which means dsp some place manages to scale it one bit down 15.08.28 # <_FireFly_> ah 15.08.52 # but now for a shower 15.08.56 # <_FireFly_> i have just made a record with the dspflac.codec file from linuxstb 15.09.21 # <_FireFly_> and now it seems that the amplitude isn't doubled anymore 15.10.58 Join Lost-ash [0] (i=ashridah@220-253-123-158.VIC.netspace.net.au) 15.11.47 # <_FireFly_> preglow: and pause works also with the dspflac.codec with the other one pause didn't work 15.11.51 # in which sector does rockbox save the configuration? 15.12.38 # CoCoLUS: start_of_first_partition - 2, usually sector 61 on harddisks 15.13.54 Quit ashridah (Read error: 110 (Connection timed out)) 15.15.11 # great. found it 15.15.16 # now, how much do i have to delete? :) 15.15.45 # we need to remove this DSP_ENABLE stuff 15.15.49 # dsp should always be enabled 15.16.36 # it just shouldn't do anything unless it's needed 15.16.37 # CoCoLUS: Just this one sector 15.19.24 Nick Lost-ash is now known as ashridah (i=ashridah@220-253-123-158.VIC.netspace.net.au) 15.21.54 # a great 15.22.01 # overwriting that sector with zeros helped :) 15.33.08 # btw, why does the rockbox save the configuration to a sector instead of a config file? Better performance? 15.33.09 Quit paugh (Remote closed the connection) 15.34.33 # It's true that the config structure makes it possible to use eeprom but we could also save that structure to a file so user could delete it 15.35.06 # maybe to survive corrupted/emptied filesystems? 15.35.30 # crwl: if the filesystem is badly corrupted, rockbox can't boot either.. 15.35.40 # Slasheri: got any thoughts on this flac dsp volume business? 15.35.40 # (unless it's flashed) 15.35.53 # preglow: haven't had yet time to test 15.44.09 Part amiconn 15.54.13 Quit ashridah ("Leaving") 16.09.40 Quit arkascha (Read error: 104 (Connection reset by peer)) 16.15.35 Join XavierGr [0] (n=XavierGr@ppp16-adsl-167.ath.forthnet.gr) 16.16.54 *** Saving seen data "./dancer.seen" 16.24.09 Join XavierGr_ [0] (n=XavierGr@ppp13-adsl-7.ath.forthnet.gr) 16.34.48 Join arkascha [0] (n=arkascha@xdsl-213-196-192-124.netcologne.de) 16.47.08 Quit XavierGr (Read error: 113 (No route to host)) 16.56.45 Quit ansivirus (Read error: 110 (Connection timed out)) 16.57.05 Quit XavierGr_ (Read error: 110 (Connection timed out)) 17.00.04 Quit muesli- (Read error: 113 (No route to host)) 17.12.05 # Unless I'm misreading it, line 450 of apps/dsp.c seems to be the culprit. In the case of 16-bit audio with no processing, "scale" is being set to 1, and the data is then being shifted right by scale bits. 17.12.29 # Thereby halving the amplitute in all cases. 17.23.21 # <_FireFly_> linuxstb: pause doesn't work with your new flac.codec but with dspflac.codec 17.23.38 Quit arkascha (Read error: 104 (Connection reset by peer)) 17.26.06 Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) 17.48.21 # I saw there was some changes for X11simulator on today's CVS logh 17.48.23 # log 17.48.40 # but the remote screen is still 1 row too small :D 17.49.01 # (this doesn't happen under windows) 17.58.58 Join linuxstb_ [0] (n=5343d4aa@labb.contactor.se) 17.59.11 Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) 18.00.16 # _FireFly_: Yes, for some reason pause doesn't seem to work without DSP. But it's not a problem as the plan seems to be to always enable the DSP. 18.00.42 Quit San (Read error: 110 (Connection timed out)) 18.16.55 *** Saving seen data "./dancer.seen" 18.21.37 Join Lear [0] (n=chatzill@h73n11c1o285.bredband.skanova.com) 18.25.14 # yes, dsp should always be enabled 18.25.20 # dithering, etc, should be a user choice, not a codec choice 18.25.40 # as should dsp 18.27.33 # preglow: Did you read my comment about line 450 of apps/dsp.c ? 18.27.41 # yes, checking out now 18.29.42 # i don't get the + 1 18.30.05 # Slasheri: comments? 18.30.46 # preglow: Hmm, sounds good :) 18.33.00 # preglow: I think fracbits is without sign, so to include the sign bit, you need +1. That's how I interpret it anyway (I didn't write the original code...) 18.33.30 # So fracbits should be set to sample_depth -1 ? 18.33.49 # In the case of integers 18.34.50 # <_FireFly_> to add a sign then you need a multiply with +1 or -1 or i'm wrong 18.36.18 # i wish this had been documented if that's the case 18.36.32 # linuxstb_: that's what vorbis.c does. When Tremor does scaling to 16-bits, it shifts right 9 bits, indicating the internal format is 25 bits. Vorbis.c sets depth to 24... 18.37.00 # As preglow says, where is this documented :) 18.37.11 # SET_SAMPLE_DEPTH is a very, very bad name for a setting in this case 18.37.12 # I'm sure most of the codecs do that wrongly then. 18.38.07 # <_FireFly_> hmm maybe this is the reason why many users thinks that the sound under iriver fw is better then under rbx 18.39.10 # Vorbis and mpa does things in the same way, I think (assuming MAD_F_FRACBITS has the same meaning as in dsp.c :) 18.39.16 # _FireFly_: doubt it 18.39.49 # _FireFly_: errors in this setting will result in massive volume changes, and we would have discovered that before now 18.40.14 # But there WERE errors - the current FLAC decoder for example. 18.40.19 # in the case of sublte audio wuality issues, that is 18.40.26 # linuxstb_: yes, but these people weren't discussing flac 18.41.06 # What were they discussing? Vorbis and MP3? 18.41.19 # <_FireFly_> afaik 18.41.21 # <_FireFly_> yes 18.41.48 # <_FireFly_> but maybe only the flac-codec shows the problem better then the other codecs 18.43.05 # Doing a "grep SET_SAMPLE_DEPTH" *.c in the codecs directory shows that almost all the codecs do the wrong thing. 18.44.00 # Flac sets depth to 16, or "unscaled", so it does the right thing, sort of. It doesn't hurt, at least. :) 18.44.54 # But the current FLAC output is seems to be half the volume compared with bypassing the DSP 18.45.06 # <_FireFly_> yepp 18.45.19 # <_FireFly_> home.arcor.de/s.wezel/flac-codec-test.jpg 18.45.38 # Which implies that it does hurt. frac_bits is 16, NATIVE_DEPTH is 16, so scale is 1 18.45.49 # (jn line 450 of dsp.c) 18.46.20 # not only does it hurt, it's outright wrong 18.46.22 # oh, so there is a bug in the dsp 18.46.36 # Slasheri: no, we only wonder what SET_SAMPLE_DEPTH argument means 18.46.48 # Slasheri: i thought it was size in bits, but it seems it is size in bits minus sign 18.47.09 # yes, i also didn't though about that sign bit.. 18.47.17 # linuxstb_: If you set "sample depth" to 16, frac_bits is actually set to 27, so your calculation is likely off. Could still be a problem though. :) 18.47.21 # i think we should fix that on the dsp 18.47.35 # ok, but then vorbis.c and mpa.c needs fixing 18.48.12 # hmm, is the mpa currently being scaled wrong (volume too high)? 18.48.18 # I don't know how mpc.c and a52.c does it now... 18.49.25 # Lear: Yes, you're right. I really don't understand dsp.c 18.49.52 Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.umbc.edu) 18.50.58 # Scaling for Flac look right to me (shift left 12 bits on "dsp entry", then scaled back 12 bits at end). 18.52.38 # Slasheri: mpa is correct, vorbis is correct, mpc isn't, but that you already know 18.52.43 # flac isn't correct 18.52.59 # preglow: ah, ok :/ 18.53.11 # i hoped that mpa and vorbis wouldn't be correct but mpc would ;) 18.53.12 # preglow: but dsp.c corrects it... 18.53.43 # how? 18.53.43 # brb 18.54.00 # Line 633: if (dsp->sample_depth <= NATIVE_DEPTH) 18.54.10 # Native depth is 16... 18.55.26 # Anyway, I agree that dsp should probably be cleared up that way (either rename DSP_SET_SAMPLE_DEPTH or change its meaning)... 19.11.45 # _FireFly_: Do you have replaygain enabled? 19.12.01 # <_FireFly_> no 19.12.55 # I can't explain the differences your recordings are showing then. 19.13.34 # I agree with Lear that dsp.c looks correct - it's shifting left 12 bits and then shifting right 12 bits. So the output should be identical. 19.13.35 # <_FireFly_> one was made with the "old" flac codec the other with your "new" flac codec 19.13.54 # Have you compared by new flac.codec and dspflac.codec? 19.14.00 # s/by/my/ 19.14.08 # <_FireFly_> if i use the dspflac.codec file then it is the same as the "old" one 19.14.45 # The only difference is that I have enabled DSP in the second one. In the first, DSP is only enabled if resampling is needed. 19.15.36 # <_FireFly_> yepp and the first one has the aplitude doupbled as you can see in the image but the recording was made from the analog-line-out 19.22.58 # well, should be quick to verify this 19.23.07 # make a flac playing at 44.1, and the same at 48 19.23.22 # if the dsp screws up, you should hear a definite volume change 19.32.39 Join Mindship-02 [0] (n=personal@62-221-202-178.dsl.fiberworld.nl) 19.33.47 # What dows my Linux kernel (2.6.13) need to mount my iRiver iHP140? USB_STORAGE ofcourse, but what about I2C? 19.34.11 # btw: does rockbox support custom boot screens? ie: my name... 19.34.20 Join RotAtoR [0] (n=e@12-208-71-148.client.insightBB.com) 19.34.39 # <_FireFly_> Mindship-02: you only need usb-storage scsi-disk support and vfat 19.34.45 # <_FireFly_> to mount the iriver 19.35.22 # okay, thanks _FireFly_ I was a bit scared because there are a couple of host controllers listed in the kernel-config, but Cyprus is not listed... 19.36.47 # I just bought a (second hand) iHP 140... is Rockbox stable enough to use as a default 'OS'? 19.37.19 # yes, and you can always dual boot/revert to the original firmware 19.38.06 # okay Slasheri, I'll give it a try! I'm scared to death though to destroy this expensive machine... 19.38.29 # preglow: I did your test, and couldn't notice any difference in the volume. The peakmeter was at the same levels as well. 19.38.35 # hehe, nobody has yet succeeded in destroying it :) 19.38.45 # just make sure the battery is fully charged before flashing.. 19.39.49 # okay. 19.39.57 # will do this week 19.40.04 # need any developers/testers? 19.40.15 # NB: I won't open it! 19.41.53 # All contributions are welcome. And don't worry, you don't need to open it. 19.43.19 # <_FireFly_> hmm i can't hear any differences in the volume with your test preglow if i use the falc-codec from linuxstb_ where dsp is only used when resampling is needed 19.44.09 # <_FireFly_> but i might hear a lower volume if i use either the original flac-codec or the new from linuxstb_ where dsp is always aktivated 19.44.20 # <_FireFly_> by both flac-files 19.44.33 # Can you notice any difference in the peak-meter readings? 19.44.48 # <_FireFly_> i don't have a peak-meter running :) 19.44.52 # <_FireFly_> so had to test it 19.49.05 # How many megs should a Rockbox developper think of as wasted? (for test-progs, the rockbox arch, etc.) 19.54.06 # <_FireFly_> if i compare the peak-meter values the two files (one 44.1khz the other 48khz) with the falc-codec-file from linuxstb(where dsp isn't aktivated all the time) then there is only a very small diffenrence 19.55.13 # <_FireFly_> but if i compare the two codec-files with one flac-file(44.1khz) then there is a greater difference between them 19.56.01 # <_FireFly_> the one with has all the time dsp aktivated has a lower value then the other(where dsp is only aktivated for resampling if needed) 20.03.24 # linuxstb_: then what the hell triggered firefly's volume change? 20.03.47 # <_FireFly_> hmm strange i have mad a falc with --sample-rate=48000 but metaflac say that the sample-rate is 44100 20.05.27 # there will always be a slight difference when resampling from 48khz using linear interpolation 20.05.35 # we're looking for a huge difference 20.05.38 Join XavierGr_ [0] (n=XavierGr@ppp15-adsl-50.ath.forthnet.gr) 20.07.55 # <_FireFly_> the peak-meter peak-bars stays in one part in the file under the "d" in (no id3) in following text-line "567kBit avg (no id3)" 20.08.25 # <_FireFly_> this is for the codec-file which has only dsp aktivated for resampling if needed 20.08.39 # <_FireFly_> am i mean if dso is always aktivated 20.09.24 # <_FireFly_> if dsp is only aktivated for resampling when needed then the peak-bars stays under the ")" of "(no id3)" in the same text-line 20.09.37 # <_FireFly_> i think that is a big difference 20.15.19 Join XavierGr2 [0] (n=XavierGr@ppp10-adsl-228.ath.forthnet.gr) 20.15.28 Nick XavierGr2 is now known as XavierGr (n=XavierGr@ppp10-adsl-228.ath.forthnet.gr) 20.16.29 # wtf? my connection is giving up on me.... 20.16.59 *** No seen item changed, no save performed. 20.18.55 Join muesli- [0] (i=muesli_t@hmln-d9b8ef44.pool.mediaWays.net) 20.20.07 Quit linuxstb_ ("CGI:IRC") 20.22.37 Quit paugh ("Leaving") 20.24.45 Join webguest21 [0] (n=81627b22@labb.contactor.se) 20.26.01 # anyone know about "Save failed No partition?" 20.29.20 # I think it means that for some reason the settings couldn't be saved. Is your battery very low? 20.29.35 Quit XavierGr_ (Read error: 110 (Connection timed out)) 20.29.44 # Battery is good. 20.30.34 # I'm not sure then. Which player do you have? 20.31.35 # I used rockbox on my Archos Recorder V2 for 2 years & loved it. I dropped it a few months ago & just got it repaired by Archos. Now I'm trying to reload the new Rockbox version but every time I play a song the display says "Save Failed No Partition?" 20.31.55 # The songs play fine though 20.33.02 Quit Mindship-02 () 20.37.33 # preglow, _FireFly_ : I can't reproduce any volume differences with the difference FLAC decoders. So I don't know what's going on. 20.38.44 Quit webguest21 ("CGI:IRC (EOF)") 20.43.10 # webguest21: have you formated the drive since you got it? 20.49.10 # I've just fixed a few small bugs and omissions in my new flac.codec. I've replaced the version here: http://www.davechapman.f2s.com/rockbox/flac.codec 20.49.18 # This has the DSP enabled by default. 20.59.48 # wee! 21.48.21 Quit XavierGr (Read error: 110 (Connection timed out)) 21.58.58 Join einhirn [0] (i=Miranda@szgt-d9b8e946.pool.mediaWays.net) 22.01.32 Join XavierGr [0] (n=XavierGr@ppp10-adsl-228.ath.forthnet.gr) 22.04.45 Quit _FireFly_ ("Leaving") 22.15.37 Join tvelocity [0] (n=tony@84.254.12.158) 22.17.00 *** Saving seen data "./dancer.seen" 22.32.19 Join amiconn [0] (n=jens@p54BD7146.dip.t-dialin.net) 22.51.26 Quit XavierGr (Read error: 110 (Connection timed out)) 22.58.22 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 23.05.36 Quit markun ("leaving") 23.06.37 Quit Lear ("Chatzilla 0.9.68.5.1 [Firefox 1.4.1/undefined]") 23.08.04 Join webguest23 [0] (n=d568f186@labb.contactor.se) 23.09.13 # hi all 23.30.06 Quit muesli- (Read error: 113 (No route to host)) 23.35.47 Join markun [0] (n=karl@bastards.student.ipv6.utwente.nl) 23.40.30 Quit ender` (Read error: 104 (Connection reset by peer)) 23.43.53 # The latest ipodlinux CVS commit looks promising: http://cia.navi.cx/stats/project/ipodlinux/.message/6144683 23.44.12 # All I have to do is wait for Sourceforge's anon cvs servers to catch up 23.45.31 # Seems the Nano is now supported: http://cia.navi.cx/stats/project/ipodlinux 23.51.25 # ooooh 23.51.42 # i am so getting an ipod if there is any possibility of that being supported by rockbox 23.52.09 # what flash based players do rockbox already run on? ondio? 23.52.20 # There is definitely a possibility. All it needs is time. 23.52.31 # Yes - I think just the Ondio. 23.52.33 # i'd be happy to port it myself 23.52.45 # Go shopping then :) 23.52.49 # haha 23.52.56 # when i get money 23.53.06 # Go working then :) 23.53.13 # waiting for Rockbox sponsoring :) 23.53.17 # and i wonder if they're releasing another version 23.53.23 # Yes, the Ondio FM and SP are the only flash players supported by rockbox now. 23.53.30 # amiconn: how does rockbox treat the flash? 23.53.34 # amiconn: just like the hard drive? 23.53.38 # yup 23.53.58 # how many write cycles can modern flash take? 23.54.02 # Some Ondio specific features are there though 23.54.21 # First, we have to support FAT16 as well as FAT32 23.54.52 # Then the Ondio can control two "disks" - the builtin 128MB flash chip and a pluggable MMC 23.55.41 # Rockbox supports accessing both at once, by a unix like approach. The internal flash is the "root", conatining the .rockbox folder etc 23.56.08 # The MMC is "mounted" under / Rockbox supports hot plugging the MMC 23.56.53 # Flash can take many write cycles today, but nevertheless we kept some write-cycle-reducing features from disk-based rockbox 23.57.10 # like? 23.57.22 # What's good to reduce disk spinups for HDs is also useful for reducing write cycles for flash 23.57.47 # Namley the delayed config sector writing