--- Log opened Sun Nov 13 00:00:17 2011
00:02 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has joined #freemyipod
00:02 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has quit [Remote host closed the connection]
02:31 -!- n1s [~n1s@rockbox/developer/n1s] has quit [Quit: Ex-Chat]
03:09 -!- Keripo [~Keripo@dhcp0751.kin.resnet.group.UPENN.EDU] has quit [Quit: Leaving.]
03:54 -!- TheSeven [~TheSeven@rockbox/developer/TheSeven] has quit [Disconnected by services]
03:55 -!- [7] [~TheSeven@rockbox/developer/TheSeven] has joined #freemyipod
06:02 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has joined #freemyipod
06:02 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has quit [Remote host closed the connection]
07:17 -!- n1s [~n1s@nl118-175-223.student.uu.se] has joined #freemyipod
07:17 -!- n1s [~n1s@nl118-175-223.student.uu.se] has quit [Changing host]
07:17 -!- n1s [~n1s@rockbox/developer/n1s] has joined #freemyipod
10:09 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has joined #freemyipod
10:29 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has quit [Read error: Connection timed out]
12:02 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has joined #freemyipod
12:02 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has quit [Remote host closed the connection]
12:26 < user890104> [7]: what should be done with the file.c functions that return negative integers on error (instead of null pointers)?
13:24 -!- user890104 [~Venci@static.225.178.40.188.clients.your-server.de] has quit [*.net *.split]
13:24 -!- teuf [~teuf@lernaeus.myrix.net] has quit [*.net *.split]
13:24 -!- scorche` [~scorche@rockbox/administrator/scorche] has quit [*.net *.split]
13:24 -!- ChanServ [ChanServ@services.] has quit [*.net *.split]
13:24 -!- Liath [~Liath@fctnnbsc30w-198164160126.dhcp-dynamic.FibreOp.nb.bellaliant.net] has quit [*.net *.split]
13:24 -!- n1s [~n1s@rockbox/developer/n1s] has quit [*.net *.split]
13:24 -!- adiblol [adiblol@planck.m.1tbps.org] has quit [*.net *.split]
13:24 -!- Kuitsi [~Kuitsi@a88-113-118-171.elisa-laajakaista.fi] has quit [*.net *.split]
13:24 -!- Utchybann [~Utchy@rps6752.ovh.net] has quit [*.net *.split]
13:24 -!- GaveUp [gaveup@your.friendly.neighborhood.hellmouth.info] has quit [*.net *.split]
13:28 -!- Kuitsi [~Kuitsi@a88-113-118-171.elisa-laajakaista.fi] has joined #freemyipod
13:28 -!- adiblol [adiblol@planck.m.1tbps.org] has joined #freemyipod
13:28 -!- Liath [~Liath@fctnnbsc30w-198164160126.dhcp-dynamic.FibreOp.nb.bellaliant.net] has joined #freemyipod
13:28 -!- Utchybann [~Utchy@rps6752.ovh.net] has joined #freemyipod
13:28 -!- GaveUp [gaveup@your.friendly.neighborhood.hellmouth.info] has joined #freemyipod
13:28 -!- n1s [~n1s@rockbox/developer/n1s] has joined #freemyipod
13:28 -!- scorche` [~scorche@rockbox/administrator/scorche] has joined #freemyipod
13:28 -!- ChanServ [ChanServ@services.] has joined #freemyipod
13:28 -!- mode/#freemyipod [+o ChanServ] by asimov.freenode.net
13:30 -!- user890104 [~Venci@static.225.178.40.188.clients.your-server.de] has joined #freemyipod
13:30 -!- teuf [~teuf@lernaeus.myrix.net] has joined #freemyipod
13:44 -!- teuf [~teuf@lernaeus.myrix.net] has quit [*.net *.split]
13:44 -!- user890104 [~Venci@static.225.178.40.188.clients.your-server.de] has quit [*.net *.split]
13:44 -!- GaveUp [gaveup@your.friendly.neighborhood.hellmouth.info] has quit [*.net *.split]
13:44 -!- Liath [~Liath@fctnnbsc30w-198164160126.dhcp-dynamic.FibreOp.nb.bellaliant.net] has quit [*.net *.split]
13:44 -!- Utchybann [~Utchy@rps6752.ovh.net] has quit [*.net *.split]
13:44 -!- adiblol [adiblol@planck.m.1tbps.org] has quit [*.net *.split]
13:44 -!- Kuitsi [~Kuitsi@a88-113-118-171.elisa-laajakaista.fi] has quit [*.net *.split]
13:44 -!- n1s [~n1s@rockbox/developer/n1s] has quit [*.net *.split]
13:45 -!- n1s [~n1s@rockbox/developer/n1s] has joined #freemyipod
13:47 -!- GaveUp [gaveup@your.friendly.neighborhood.hellmouth.info] has joined #freemyipod
13:47 -!- teuf [~teuf@lernaeus.myrix.net] has joined #freemyipod
13:47 -!- user890104 [~Venci@static.225.178.40.188.clients.your-server.de] has joined #freemyipod
13:47 -!- Utchybann [~Utchy@rps6752.ovh.net] has joined #freemyipod
13:47 -!- Liath [~Liath@fctnnbsc30w-198164160126.dhcp-dynamic.FibreOp.nb.bellaliant.net] has joined #freemyipod
13:47 -!- adiblol [adiblol@planck.m.1tbps.org] has joined #freemyipod
13:47 -!- Kuitsi [~Kuitsi@a88-113-118-171.elisa-laajakaista.fi] has joined #freemyipod
14:10 < [7]> user890104: hm, good question
14:11 < [7]> changing them to null will make it almost impossible to diagnose which error it was
14:11 < [7]> but assuming that pointers are always positive is highly target-specific
14:12 < [7]> we should probably use errno more extensively
14:12 < user890104> yeah, this should be the solution
14:12 < user890104> errno returns almost posix-compatible error codes, right?
14:13 < user890104> if yes, i can directly pass it to FUSE in my app
14:14 < [7]> yeah, but AFAICT not everything uses errno yet
14:15 < user890104> you mean the apps which use the file api, or the file api functions?
14:15 < [7]> not every function sets errno, and also some call each other and check against specific return value or errno combinations
14:15 < [7]> this needs a lot of caution
14:15 < user890104> that's why i haven't started changing it yet :)
14:16 < user890104> but it needs to be done at some point
14:16 < user890104> otherwise error detection is a mess
14:16 < [7]> also, errno and the return code are different things: errno usually points towards the root cause (e.g. out of memory) while the return code points towards the failing sub-operation
14:17 < [7]> we should possibly add another errno-like construction and use it to track the whole failing call stack, like I did with the return codes in the storage driver
14:18 < [7]> right now we could get around it by assuming that pointers are positive, which does hold true on everything except maybe the ipt2g target
14:19 < user890104> well it should be safe to assume that pointers are positive, because there's no implementation of nand/ftl for ipt2g yet
15:51 < [7]> yeah, currently, yes
15:51 < [7]> but this is not a sane design decision :)
16:17 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has joined #freemyipod
16:28 -!- r100 [565596a2@gateway/web/freenode/ip.86.85.150.162] has joined #freemyipod
16:38 < r100> I'd like to thank all the developers for their effort! Everyday I'm using Rockbox with Emcore on my iPod Classic with a smile :)
16:44 < r100> Unfortunately, my battery isn't always smiling back at me... I'm using the latest official emcore version I could find (r710) and this eats the battery quite a lot (due to the constant max voltage on the cpu if I'm correct)
16:45 < r100> Is there or will there be a newer version that underclocks/undervolts the cpu to spare the battery?
16:57 < n1s> i don't think the cause for the high power consumption is known so it's hard to know if or when someone will work on it and if that has any results
17:10 < r100> Allright, that makes sense! I just drew my own conclusions from the last release notes; "Reducing the CPU core voltage on the iPod Classic has been disabled. Battery life might be adversely affected"
17:25 < user890104> r100: this is one of the reasons
17:25 < user890104> the other one is what n1s said
17:29 < [7]> r100: apple doesn't ever reduce the CPU voltage or clock and yet they manage to get twice the battery life
17:29 < [7]> so we're obviously missing something... but what?
17:30 < r100> hmm yes I was thinking about that as well
17:30 < [7]> the only thing that I can say for sure is that it definitely isn't related to the HDD, and that the nano2g is affected as well, but to a far lesser degree
17:32 < r100> maybe it's partly because of iTunes, which slightly edits the mp3 when they're being copied to the iPod for less intensive reading and processing
17:32 < [7]> very unlikely
17:33 < [7]> actually I think our codecs are more efficient than apple's
17:33 < r100> ok
17:33 < [7]> my suspicion is that it has something to do with CPU/memory sleep states
17:33 < r100> ahah that's the spirit
17:33 < r100> When I listen to a FLAC file in Rockbox it makes sense that this is more intensive than a 192 kbps mp3
17:33 < [7]> it's the other way round
17:34 < [7]> flac is a lot less work to decode, but the files are bigger => more hdd spinning time
17:34 < r100> ok, I feel like a noob between you guys, but I learn a lot
17:34 < [7]> so flac might actually use less power than high-bitrate mp3
17:34 < [7]> but probably more than low-bitrate mp3
17:35 < [7]> haven't tested where exactly that limit is though
17:35 < r100> and the cache (64 mb or so) is also being used for this?
17:35 < [7]> my observation is that the power usage difference is the biggest when the ipod is just sitting in the main menu without doing anything, which is why I suspect it's something related to sleeping
17:36 < r100> exactly my experience as well...
17:36 < [7]> rockbox's cache is certainly bigger than apple's
17:36 < [7]> when navigating around a lot, the hdd will dominate the power consumption and the difference won't be big
17:36 < [7]> but when just letting it sit around playing music or not even doing anything, apple outperforms us by a factor of more than 2
17:38 < r100> I do notice in original Apple firmware that when the lock is on while playing the screen seems to be limited to 3-5 frames per second
17:38 < r100> and then it only shows the time and battery
17:39 < r100> while in Rockbox the complete screen stays fully active except for the backlight
17:39 < [7]> even completely powering off the screen will only improve the battery runtime by <10%, so that's at least not the only cause...
17:44 < r100> Allright, well if you're talking about a factor of more than 2 it indeed has to be something else (or a combination of several things like these)
17:45 < [7]> it's definitely a combination of multiple things, but I'd guess that there is at least one big component that accounts for more than half of the difference
17:45 < [7]> and i'd really like to figure out what that is :)
17:45 < r100> ahah, me too (even though I'm not a developer)!
17:46 < n1s> very possible there are parts of the soc that can be powered down that we don't do at the moment too
17:47 < user890104> [7]: what about desoldering parts and measuring current at their power pins?
17:47 < user890104> or something is happening inside the SoC?
17:47 < [7]> well, we already do some peripheral enabling/disabling (internally probably clock/power gating), so I'm pretty much out of ideas
17:48 < [7]> user890104: no idea whether it's inside or outside of the SoC, but good luck desoldering these BGA chips
17:48 < r100> concerning the iPod Classic, the soc is also able to play video, in my opinion this part could be shutdown
17:49 < [7]> I'm not even sure if that's software or hardware decoding
17:49 < [7]> probably some kind of IDCT accelerator but not much more implemented in hardware
17:49 < [7]> it's a pretty powerful CPU though (216MHz ARMv5e core)
17:50 < r100> they say it's able to play 640x480 (even though the screen has half the pixels or so)
17:55 < user890104> [7]: i was hoping they are at least SMD, BGA is going to be very difficult :)
17:56 < [7]> you could possibly try to desolder one of the power supply inductors to check how much current is going which path at that point
17:56 < [7]> that would at least provide some useful information
17:57 < r100> maybe original firmware also uses dynamic rpm for the hdd
17:57 < [7]> nah, it's definitely not the HDD
17:58 < [7]> the ipod firmware doesn't have much influence on the hdd, and we can measure the biggest difference when the hdd is completely powered down
18:02 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has joined #freemyipod
18:02 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has quit [Remote host closed the connection]
18:03 < r100> I got access to documents from the IEEE, found one talking about the ARM5vE architecture. Could this maybe help you guys?
18:04  * [7] has access to most of that stuff as well
18:05 < [7]> and the ARM side of things is one of the most well-understood components in that device
18:05 < [7]> the problem is all the proprietary apple crap around that ARM core
18:05 < [7]> and we obviously have no docs at all for that
18:07 < r100> nobody here works at Apple Inc. hmm?
18:18 < r100> well I have no idea about the idle battery drain (except the high cpu voltage, but that's been mentioned before)
18:20 -!- r100 [565596a2@gateway/web/freenode/ip.86.85.150.162] has quit [Quit: Page closed]
20:02 -!- r100 [565596a2@gateway/web/freenode/ip.86.85.150.162] has joined #freemyipod
20:03 -!- Keripo [~Keripo@dhcp0751.kin.resnet.group.upenn.edu] has joined #freemyipod
20:27 -!- ohoh [18cacc83@gateway/web/freenode/ip.24.202.204.131] has joined #freemyipod
20:36 -!- ohoh [18cacc83@gateway/web/freenode/ip.24.202.204.131] has left #freemyipod
21:10 -!- Liath [~Liath@fctnnbsc30w-198164160126.dhcp-dynamic.FibreOp.nb.bellaliant.net] has quit [Ping timeout: 256 seconds]
21:10 -!- Liath [~Liath@fctnnbsc30w-198164160126.dhcp-dynamic.FibreOp.nb.bellaliant.net] has joined #freemyipod
21:33 -!- r100 [565596a2@gateway/web/freenode/ip.86.85.150.162] has quit [Quit: Page closed]
22:43 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has quit [Quit: Bye ;)]
22:45 -!- n1s [~n1s@rockbox/developer/n1s] has quit [Quit: Ex-Chat]
--- Log closed Mon Nov 14 00:02:02 2011