Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2013-05-26

00:14:21 Quit krabador (Read error: Connection reset by peer)
00:20:06 Join krabador [0] (~krabador@unaffiliated/krabador)
00:39:53***Saving seen data "./dancer.seen"
00:47:54 Quit funman (Ping timeout: 276 seconds)
01:00
01:03:02 Quit krabador (Ping timeout: 260 seconds)
01:06:59 Quit bertrik (Remote host closed the connection)
01:25:55saratoga_has anyone else noticed this: FS #12864 - Automatic Resume behavior inconsistent on 3.13
01:25:56fs-bluebothttp://www.rockbox.org/tracker/task/12864 3Automatic Resume behavior inconsistent on 3.13 (bugs, unconfirmed)
02:00
02:04:45 Quit ender` (Quit: Religion is an insult to human dignity. With or without it you would have good people doing good things and evil people doing evil things. But for good people to do evil things, that takes religion.-- Steven Weinberg)
02:05:23 Quit shamus (Read error: Connection reset by peer)
02:05:36 Join shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net)
02:11:45 Quit lebellium (Quit: ChatZilla 0.9.90 [Firefox 22.0/20130521223249])
02:35:29 Join funman [0] (~fun@rockbox/developer/funman)
02:39:57***Saving seen data "./dancer.seen"
02:42:45 Quit Wardo (Read error: Connection reset by peer)
02:43:19 Join SuperBrainAK_ [0] (~Andreas@97-124-74-93.phnx.qwest.net)
02:45:56 Quit SuperBrainAK (Ping timeout: 248 seconds)
02:47:39 Quit SuperBrainAK_ (Ping timeout: 246 seconds)
02:50:48 Quit funman (Ping timeout: 246 seconds)
02:51:42 Join SuperBrainAK [0] (~Andreas@71-36-166-167.phnx.qwest.net)
02:57:38 Join funman [0] (~fun@rockbox/developer/funman)
03:00
03:37:31 Quit ball (Quit: I like pie)
03:58:28 Join krabador [0] (~krabador@unaffiliated/krabador)
04:00
04:07:36 Quit krabador (Read error: Connection reset by peer)
04:11:51 Quit amiconn (Disconnected by services)
04:11:51 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn)
04:11:53 Quit pixelma (Disconnected by services)
04:11:53 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma)
04:11:55 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma)
04:11:55 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn)
04:27:10 Nick [Saint] is now known as [Sinner] (~saint@rockbox/user/saint)
04:28:10 Nick [Sinner] is now known as [Saint] (~saint@rockbox/user/saint)
04:39:58***Saving seen data "./dancer.seen"
05:00
05:11:26 Quit TheSphinX^ (Ping timeout: 240 seconds)
05:12:08 Join TheSphinX^ [0] (~briehl@p5DD457A7.dip0.t-ipconnect.de)
05:39:05 Join efyx__ [0] (~efyx@10.207-241-81.adsl-dyn.isp.belgacom.be)
05:40:49 Quit efyx_ (Ping timeout: 256 seconds)
05:47:17 Quit prof_wolfff (Ping timeout: 248 seconds)
05:55:21 Quit [7] (Disconnected by services)
05:55:29 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
05:58:01Mirohh
05:58:06Mirnew rockbox
05:58:11Miri have been here but now
05:58:21*Mir knows what he will be doing tomorrow
05:58:44*Mir is still on 3.10
05:59:45[Saint]Heh - if RaaA ever makes it to Google Play, we'll have to make sure it is signed by a different machine then the build we push here. Unless I'm reading the new Google Play policy wrong.
06:00
06:00:17[Saint]An app hosted thereon can no longer update or replace itself from an outside source - does this include sideloading?
06:02:51Mirwhat is RaaA
06:03:05[Saint]Rockbox as an Application
06:10:53 Join saratoga__ [0] (123e1cf8@gateway/web/freenode/ip.18.62.28.248)
06:11:21saratoga__you need to have one machine sign it I think otherwise you wont' be able to push updates since the keys won't match
06:12:22saratoga__you can always sideload anything, but google forbids you to have the app sideload itself automatically
06:18:18[Saint]The wording makes me unsure of possible scenarios.
06:18:59[Saint]As far as I can piece it together, if we offered a binary here, it would need to be signed by a different machine than that which signed the one on the Play Store.
06:19:43[Saint]Since we could potentially offer a signed, yet deliberately crafted malware ridden binary.
06:32:52saratoga__i don't see why
06:33:10saratoga__lots of projects release both store and HTTP downloads
06:33:24[Saint]I basically read it as: "If its on Google Play, it isn't allowed to update via any outside sources"
06:33:29saratoga__i think you want them both signed by the same machine so that one can update the other (although i'm not sure about that..)
06:33:42saratoga__no it just means the app itself can't side load
06:33:48saratoga__like facebook used to do
06:33:51[Saint]Yeah, that would be a "no-do" as far as understand.
06:33:59saratoga__where it would download new APKs and install them directly
06:34:01[Saint]That's what they're combatting specifically.
06:34:09saratoga__they don't care if the user sideloads
06:34:24 Quit bluebrother (Disconnected by services)
06:34:29 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
06:34:40saratoga__they want to avoid the case where someone puts a legit app on the market, and then has it sideload its own malware without the user being aware
06:34:55saratoga__if the user goes and downloads something manually, then they don't care
06:35:08saratoga__since presumably the user knows what they're doing
06:35:51[Saint]That's rather dangerous, IMO.
06:36:08[Saint]I would suggest that a lot of users /think/ they know what they're doign :)
06:36:39 Quit fs-bluebot (Ping timeout: 256 seconds)
06:37:20[Saint]The thing I'm unsure about is whether or not the key can be shared. If it is acceptable to have an instance on the Play Store that is capable of being updated by a sideloaded binary or not.
06:37:36[Saint]Or, if (safer, much so) they would need seperate keys.
06:37:58 Join fs-bluebot [0] (~fs-bluebo@g226070015.adsl.alicedsl.de)
06:40:02***Saving seen data "./dancer.seen"
06:45:07fs-bluebotBuild Server message: 3Build round completed after 487 seconds.
06:52:22saratoga_jhMikeS: if you want an excuse to do some arm asm, can i suggest libopus's kissfft library?
06:53:34jhMikeSyou can
06:54:06jhMikeSWanted SPC to make up for resampler, which it does, and can call that done
06:55:24jhMikeSI do have something going that allows that output samplerate to be set, but it will be a setting. I'll never implement on the fly switching, ever.
06:56:45jhMikeSAny preference, 44.1kHz or greater that the hardware supports
06:59:51jhMikeSsaratoga: the one in libopus/celt, eh?
07:00
07:04:08saratoga_having a 48k option would be great
07:04:17saratoga_i've wanted to try that for a long time, but never got a chance
07:04:28saratoga_jhMikeS: yeah the celt one, its quite slow right now
07:04:39saratoga_2-3x slower than the MDCT lib
07:04:40derfsaratoga_: I think jmspeex is talking about reworking it to make it more SIMD-friendly.
07:04:51derfBut that is likely weeks/months away.
07:05:03saratoga_derf: probably won't help us too much since we're on armv4-5
07:05:17 Join jmspeex [0] (~jm@mf4-xiph.osuosl.org)
07:05:26saratoga_speak of the devil
07:05:27jhMikeSsaratoga_: it gets 48k if hardware has it
07:05:39derfI mean, jmspeex is sitting at the desk next to me.
07:05:45saratoga_so basically a user setting for 44.1/48k?
07:06:08jhMikeS44.1 any anything greater that the hardware has
07:06:30jhMikeSor, unless it's 48k, just have no option, which could be done
07:06:45jhMikeSotherwise is 64, 88, 96
07:06:52saratoga_this is for the entire dsp pipeline or just spc?
07:07:10saratoga_anyway, i still want to look at kissfft, but haven't had time
07:07:11jhMikeSdsp, mixer and anything using that
07:07:18 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee)
07:07:18saratoga_ah that would be great
07:07:32jmspeexsaratoga_: which kissfft?
07:07:41jhMikeSit's basically like that global sound card setting for mixed audio
07:07:41saratoga_isn't that what opus uses?
07:07:51saratoga_maybe i'm forgetting
07:08:36jmspeexsaratoga_: I mean I heavily modified it and doesn't look like the original
07:08:37jmspeexbl
07:08:39jmspeexbbl
07:09:13saratoga_anyway, it would be very easy to make a lot faster on armv4/v5
07:10:06saratoga_IIRC, the pre/post rotations and radix-3 and radix-5 (or maybe it was 4???) together are like 30 lines long and account for a majority of the entire decode time
07:10:18saratoga_since gcc makes a mess of them
07:18:26 Quit SuperBrainAK (Quit: pbly gone to sleep (-.-)Zzz...)
07:21:35jmspeexsaratoga_: I've also recently made it easy to optimize several other functions by making them all use the same code
07:21:50jmspeexcelt_autocorr(), pitch_xcorr(), celt_fir() and celt_iir()
07:22:11saratoga_IIRC, from the ARMv4 benchmarks, libopus would be faster than some commerical AAC decoders with just the FFT changes
07:22:27saratoga_in celt mode at least
07:22:27jmspeexcool. Didn't know AAC sucked that much :-)
07:22:30saratoga_never looked at the rest
07:22:40saratoga_commerical decoders are often not very good, no
07:23:14jmspeexthe think with the MDCT is that there's some algorithmic optimizations that are possible
07:23:26jmspeexand generally you want to do those before writing assembly
07:23:48saratoga_IIRC it looked pretty good
07:23:49[Saint]commercially speaking, realtime on the intended target is the benchmark really...no?
07:24:04[Saint]anything more than that is wasted effort/wages.
07:24:16saratoga_its basically the ffmpeg MDCT except with kissfft instead of the ffmpeg split radix power of 2 one
07:24:53saratoga_but it was last fall since i looked so maybe i'm forgetting
07:25:05jmspeexsaratoga_: Apparently there's a way to merge the first state of the FFT with the MDCT rotations
07:25:15jmspeexAlso, possibly getting rid of bitreverse
07:25:37jmspeexotherwise arvm4/5 isn't that complicated. It's SIMD that requires a lotof thinking
07:25:58saratoga_IIRC the tremor MDCT does that
07:26:07jmspeexpossibly
07:27:16saratoga_the thing is gcc has so much trouble with this kind of cold on old arm systems that algorithmic changes actually aren't so important
07:28:11saratoga_just getting something that doesn't spent half its time spilling registers to memory is more important
07:28:33saratoga_if you can use the v5E DSP instructions and ldm/stm, thats even better
07:28:47jmspeexsaratoga_: Yes I understand, but if you can avoid lots of loads that can still help
07:29:04jmspeexThe other issue is maintenance if we end up changing the existing MDCT
07:29:06derf[Saint]: Battery life.
07:29:17saratoga_true
07:29:55saratoga_although I think opus + mp3 are the only codecs we have that actually use their own MDCTs
07:30:02jmspeexPeople often tend to jump to assembly a bit too soon
07:30:07saratoga_since they're the only ones that have funny sizes
07:30:15derfWell, I mean, Rockbox has been shipping Opus for a year.
07:30:47jmspeexsaratoga_: Did you benchmark the Opus MDCT on powers of two against the one you're using
07:31:00saratoga_no i didn't, but it'll lose horribly
07:31:04jmspeexMaybe the solution is to add non-2 radices to your MDCT?
07:31:05saratoga_if ASM is enabled
07:31:24jmspeexNo, I mean in an apples-to-apples comparison
07:31:37saratoga_we can decode an entire WMA 128k stream in less time than the Opus FFT (not including MDCT rotations) needs
07:31:44jmspeexThe Opus MDCT "does the job", but I certainly welcome something better
07:32:11saratoga_its not clear to me how to reuse bits of the other FFT for non-powers of 2
07:32:35saratoga_i guess it might just be a case of adding the other radix powers
07:33:42saratoga_not sure how the shuffling works in that case
07:34:09jmspeexsaratoga_: could also be checking why yours is better and changing the Opus code to do that
07:34:22saratoga_ours is just the ffmpeg one with a lot of arm asm
07:34:24jmspeexe.g. does it have a bitrev step?
07:34:29derfIt's better because it wasn't written by gcc.
07:34:34saratoga_we ported it over a couple years ago when we switched from tremor's
07:34:46jmspeexderf: just because of that?
07:34:56derfjmspeex: Have you seen gcc's ARM asm?
07:35:02derfIt is atrocious.
07:35:12jmspeexI have
07:35:21saratoga_on v4?
07:35:23jmspeexBut it doesn't mean it's the *only* factor
07:35:27saratoga_i gather its better on newer arm systems
07:35:39derfMaybe for very recent gcc's.
07:35:42jmspeexI write ARM assembly in the past for Speex
07:35:46derfIt certainly wasn't as of 4.5.
07:35:49jmspeex(not just operators)
07:36:14saratoga_for a while i used the old ffmpeg FFT (before they got a split radix one), and it was actually quite fast when compiled by gcc
07:36:38saratoga_but it was a dumb fft that didn't do anything fancy so that probably helped gcc a lot
07:38:05jmspeexsaratoga_: One important questions is what's the mul you want to use
07:38:09saratoga_from the wiki, the old WMA decoder ran at 45MHz for 128k on ARM7TDMI, this was back with an all-c power of 2 FFT
07:38:29saratoga_so thats probably ~25Mhz for MDCT
07:38:39saratoga_i'll see if i can find better measurements
07:39:10saratoga_on armv4 that would be 32x32=64, on newer, it'd be nice if we could use 32x16 but i have no idea if thats possible
07:42:01saratoga_jmspeex: http://pastebin.com/hZ2eQ7sJ (tested on ARM7TDMI)
07:42:23 Quit JdGordon (Ping timeout: 256 seconds)
07:42:34saratoga_mdct_backward (and those other functions) are from libtremor
07:43:09derfsaratoga_: Our current kissfft uses 16-bit twiddles and 32-bit data, so you can do 32x16 muls.
07:43:12jmspeexsaratoga_: why no idea if it's possible?
07:43:49derf(in fact C_MULC has already been written to use them for ARMv5E)
07:44:40 Join JdGordon| [0] (~jonno@101.174.205.167)
07:44:40 Quit JdGordon| (Changing host)
07:44:40 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon)
07:44:44saratoga_oh yeah, forgot I did that :)
07:45:06derfIt's been backported to mainline now.
07:45:22derfAnd used for the forward FFT as well.
07:46:58saratoga_oh cool
07:47:58 Quit yosafbridge (Ping timeout: 246 seconds)
07:49:08 Join yosafbridge [0] (~yosafbrid@li125-242.members.linode.com)
08:00
08:03:21jmspeexsaratoga_: Maybe it's worth just doing a straight asm optimization of the current MDCT to see where the bottlenecks end up
08:03:39jmspeexIt'll be useful in the short term and it could guide further improvements
08:08:31saratoga_yeah
08:08:45saratoga_probably it'll make it fast enough that its not important to make it faster on older cpus
08:09:05saratoga_we could make tremor go faster too right now, but its almost not worth it since we can't clock CPUs low enough
08:12:24saratoga_actually, i'm surprised you guys care about SIMD, I'd think with good ASM, you'd be able to get down under 25 Mhz just using ARMv6
08:12:46saratoga_whereas anything with NEON is or SSE is probably running in the GHz
08:13:08jmspeexsaratoga_: BTW, we use a lot of Q15 operators, but it's probably not hard to convert to Q16
08:13:24saratoga_yeah, i just shifted by one and accepted a tiny bit of rounding error
08:14:16jmspeexsaratoga_: Well, the 16-bit twiddles dominate the error. If you lose one but on the data, it doesn't matter much
08:14:51jmspeexsaratoga_: About optimizing Opus, part of the idea is to free cycles for video and the rest of the audio pipeline (e.g. AEC)
08:15:26saratoga_yeah, but the amount an audio decoder should use is so small
08:15:31saratoga_compared to video
08:15:47jmspeexwe also encode
08:16:02saratoga_ah thats true
08:16:11saratoga_but i guess the MDCT probably doesn't dominate on encode
08:16:24jmspeexDoes Rockbox use the encoder at all?
08:16:33saratoga_i don't believe so
08:16:42jmspeexEncoding CELT is cheap, MDCT is a big chunk
08:16:51saratoga_we do have encoders (speex) but i don't think we ported opus yet
08:17:12saratoga_i looked, and our current MDCT is about 14MHz per 1x at 44,1k
08:17:20saratoga_using ARMv4 operations only
08:17:35jmspeexmono or stereo?
08:17:45saratoga_SIMD might get you down to 7-8MHz, but thats a lot of work for just a few MHz of total savings
08:17:48saratoga_stereo
08:18:18saratoga_power of 2 though, no idea if thats a big difference (assume no)
08:18:32jmspeexpretty good
08:18:51saratoga_we can decode some entire transform codecs in less than 20 Mhz
08:18:55jmspeexsaratoga_: FYI, at complexity 1 (still easily beats MP3), The Opus encoder is just 50% more complex than the decoder
08:19:00saratoga_could probably do much better but why bother
08:19:07saratoga_the screen will lag if you clock that low anyway
08:19:16saratoga_wow
08:19:28saratoga_thats pretty impressive
08:21:12saratoga_wait found some newer numbers
08:21:19saratoga_16.37MHz for a stereo 128k WMA stream
08:21:39saratoga_on ARMv5E (with memory run at core speed so a little unfair...)
08:21:50jmspeexBecause of the way the bit-stream is designed, the encoder and decoder need to do about the same steps
08:22:02saratoga_~50% of that is the MDCT, so probably 8 Mhz
08:22:23saratoga_of course thats cheating unless you have a device with a lot of SRAM
08:22:39jmspeexThe Opus MDCT tends to be about 33% of total decoder
08:23:04saratoga_no ARMv5E instructions either
08:23:31saratoga_similar to AAC than
08:25:58saratoga_someday i need to look at opus closely and understand whats actually happening in the decoder
08:27:12saratoga_still not entirely clear to me why opus seems to bend the quality/compression/performance curve as effectively as it does
08:29:47jmspeexsaratoga_: Fortunately, we just wrote a paper about it
08:29:56saratoga_is it published somewhere?
08:30:11jmspeexJust submitted
08:30:20jmspeexBut here it is: http://jmvalin.ca/misc_stuff/aes_opus_celt.pdf
08:30:21saratoga_whats the journal?
08:30:26jmspeexAES convention
08:30:26saratoga_oh cool
08:32:42jmspeexIn case you find any error in it, we still have a few days to correct them
08:32:56saratoga_haha i wouldn't worry about that
08:33:37saratoga_i just dabble in this stuff so i don't forget how to program and do math
08:36:24saratoga_i noticed that opus is much slower at low delays, do you have any idea why that is?
08:40:05***Saving seen data "./dancer.seen"
08:45:00jmspeexsome operations have a fixed cost per frame
08:45:08jmspeexe.g. energy decoding, bit allocation
08:46:24jmspeexBTW, I don't know if you've updated to the current git master, but it's worth it
08:46:39jmspeexWe landed lots of optimizations in the past week
08:47:57saratoga_no we're somewhat out of date
08:50:07saratoga_i'm not familiar with this Hadamard based time/frequency thing
08:50:39saratoga_IIUC, the idea is that you can take a set of coefficients from multiple short blocks to improve frequency resolution in some set of bands?
08:50:46jmspeexsaratoga_: Think of Hadamard as an approximation to the DCT/IDCT
08:51:05jmspeexexactly
08:51:53jmspeexvaguely similar to the MP3 that runs an MDCT on samples from a certain QMF band
08:52:26saratoga_how does this compare to the subband method, where you split things into bands and then MDCT them?
08:52:44saratoga_i guess it lets you decide on a per frame basis if you want to make the tradeoff, but is there some cost?
08:52:56jmspeexI don't understand what you mean
08:53:41saratoga_so in ATRAC, they split the stream into a couple different frequency bands, and then do different MDCT sizes on each
08:54:02saratoga_IIUC, this is a similiar idea, but i guess the advantage is that you can easily turn it on and off?
08:54:16jmspeexcan the MDCT size for a certain band vary over time?
08:54:26saratoga_whereas ATRAC is stuck with the filterbank and MDCT regardless of if it is actually useful
08:54:49saratoga_i think in the newest ATRAC it can, but in the 1 and 3 its fixed at some size
08:55:14jmspeexso in our case, we can change at any time. Also, we can even do the reverse.
08:55:28jmspeexTake a long MDCT and improve the time resolution
08:55:52jmspeexthe time resolution isn't as good as starting with short MDCTs, but it can still be useful
08:55:56saratoga_IIUC, there is a some efficiency cost associated with subbands because of the transistion band in the delay of the filterbank, so being able to turn it on and off is probably an advantage?
08:56:38jmspeexwell, the idea is to adapt to the signal.
08:57:08jmspeexImagine you have a piano and a high-hat at the same time frame
08:57:10saratoga_yeah
08:57:21saratoga_i guess for atrac they're actually just trying to make the MDCT not have uniform time resolution
08:57:39jmspeexyou can decide to have good freq resolution in the lower bands because it's dominated by the piano and then have good time resolution at higher freq for the high hat
08:57:50saratoga_interesting
08:58:56saratoga_one other question: Opus/CELT and WMA are the only codecs i've ever seen that allow more than 2 transform sizes in the same stream, is there some reason thats so uncommon?
08:59:40jmspeexsaratoga_: Opus really allows two sizes, it's just that you can change which two on a frame-by-frame basis
09:00
09:00:12jmspeexFor codecs like Vorbis, you need different overlap handling for each pair of sizes, so it grows in N^2.
09:00:40jmspeexFor Opus, we use the same overlap all the time. There's a quality cost, but we have to pay for it because we want to work in real-time applications
09:03:48 Quit kevku (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/)
09:07:17 Join ender` [0] (krneki@foo.eternallybored.org)
09:08:33 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf)
09:13:23 Quit ruskie (Excess Flood)
09:16:01 Join melmothX [0] (~melmoth@unaffiliated/melmothx)
09:17:34 Join ruskie [0] (ruskie@sourcemage/mage/ruskie)
09:26:06 Join Wardo [0] (~Mirandaha@176-120-190-109.dsl.ovh.fr)
09:49:33 Quit akaWolf (Read error: Connection reset by peer)
09:50:33 Join stoffel [0] (~quassel@pD9E40935.dip0.t-ipconnect.de)
09:51:01 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf)
10:00
10:26:42 Join Horscht [0] (~Horscht@xbmc/user/horscht)
10:28:46 Quit Horscht (Client Quit)
10:40:07***Saving seen data "./dancer.seen"
10:41:37 Quit saratoga_ (Quit: Page closed)
10:43:44 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee)
10:44:55 Join Horscht [0] (~Horscht@xbmc/user/horscht)
10:51:05 Quit jhMikeS (Ping timeout: 240 seconds)
10:52:27 Join y4n [0] (~y4n@unaffiliated/y4ndexx)
10:57:42 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
11:00
11:05:06 Quit TheSphinX^ (Read error: Operation timed out)
11:05:34 Nick funman is now known as j-b (~fun@rockbox/developer/funman)
11:08:53 Join bertrik [0] (~quassel@rockbox/developer/bertrik)
11:11:51 Nick j-b is now known as b-j (~fun@rockbox/developer/funman)
11:13:03 Join TheSphinX^ [0] (~briehl@p57A398C1.dip0.t-ipconnect.de)
11:15:44 Nick b-j is now known as funman (~fun@rockbox/developer/funman)
11:28:48 Quit stoffel (Ping timeout: 245 seconds)
11:34:03 Quit pamaury (Ping timeout: 246 seconds)
11:34:27 Join pamaury_ [0] (~quassel@rockbox/developer/pamaury)
11:39:57 Quit KiwiCAM_ (Remote host closed the connection)
11:42:11pamaury_does anyone know a chip manufacturer which logo looks like Pi (mathematical letter) or stylish "JL" ?
11:46:10 Join kiwicam [0] (~quassel@101.98.163.139)
11:50:13 Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr)
12:00
12:04:17 Quit pamaury_ (Quit: this->disconnect())
12:04:27 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
12:31:33 Join n1s [0] (~n1s@nl118-168-30.student.uu.se)
12:31:33 Quit n1s (Changing host)
12:31:33 Join n1s [0] (~n1s@rockbox/developer/n1s)
12:40:08***Saving seen data "./dancer.seen"
13:00
13:03:34 Quit [Saint] (Remote host closed the connection)
13:04:48 Join [Saint] [0] (~saint@rockbox/user/saint)
13:23:54 Quit Horscht (Quit: quit)
13:28:29pamauryanyone can help me find some information about a chip ? marking is logo (pi or "jl") + AC1251H7R691-96
13:47:16 Join prof_wolfff [0] (~prof_wolf@62.83.50.196.dyn.user.ono.com)
13:55:40 Join einhirn [0] (~Miranda@p4FF89141.dip0.t-ipconnect.de)
14:00
14:00:02 Quit einhirn (Ping timeout: 245 seconds)
14:00:54 Quit y4n (Read error: Connection reset by peer)
14:01:51 Join y4n [0] (~y4n@unaffiliated/y4ndexx)
14:05:47 Join Horscht [0] (~Horscht@xbmc/user/horscht)
14:13:51 Quit froggyman (Ping timeout: 256 seconds)
14:14:26 Join froggyman [0] (~froggyman@unaffiliated/froggyman)
14:26:55 Quit pamaury (Read error: No route to host)
14:27:02 Join pamaury_ [0] (~quassel@2a01:e35:243f:8460:221:6aff:feaa:cdaa)
14:32:31funmanpamaury_: do you have a picture ?
14:33:35bertrikthe internet has pages full of manufacturer logos to help identification
14:33:57bertriklike http://www.advanced-tech.com/ic_logos/ic_logos.htm
14:34:25pamaury_funman: http://amaury.pouly.free.fr/Images/SSL24936.JPG
14:34:28bertrika Pi-like logo doesn't ring a bell for me
14:34:34pamaury_I cannot find it in any list
14:34:35 Nick pamaury_ is now known as pamaury (~quassel@2a01:e35:243f:8460:221:6aff:feaa:cdaa)
14:34:54 Quit pamaury (Changing host)
14:34:54 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
14:35:14bertrikwhat kind of device is this?
14:35:45pamauryangry bird speaker :)
14:40:09***Saving seen data "./dancer.seen"
14:45:05n1sgoogle image search gives some really weird hits on that chip image :)
14:46:02pamauryyeah, I tried with a hand modified image but didn't get any useful hit
15:00
15:29:36 Join krabador [0] (~krabador@unaffiliated/krabador)
15:29:54 Quit n1s (Ping timeout: 264 seconds)
15:30:40 Join n1s [0] (~n1s@rockbox/developer/n1s)
15:33:11 Join kaputnik_ [0] (~kaputnik@p5DD9CD1B.dip0.t-ipconnect.de)
15:52:45 Quit Horscht (Quit: quit)
15:56:13 Quit Wardo (Quit: Blarglarg)
16:00
16:02:48 Join einhirn [0] (Miranda@bsod.vpn.tu-clausthal.de)
16:40:11***Saving seen data "./dancer.seen"
16:40:34 Quit guymann (Ping timeout: 252 seconds)
16:41:30 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
16:47:19 Quit [Saint] (Remote host closed the connection)
16:48:31 Join [Saint] [0] (~saint@rockbox/user/saint)
16:48:42 Quit pamaury (Ping timeout: 246 seconds)
17:00
17:18:49 Quit Xerion (Read error: Connection reset by peer)
17:19:12 Join Xerion [0] (~xerion@5419F5F4.cm-5-2d.dynamic.ziggo.nl)
17:19:19 Join KiwiCAM_ [0] (~quassel@101.98.163.139)
17:19:42 Quit kiwicam (Ping timeout: 264 seconds)
17:23:32 Quit kevku (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/)
17:42:17 Join kiwicam [0] (~quassel@101.98.163.139)
17:42:27 Quit KiwiCAM_ (Ping timeout: 252 seconds)
18:00
18:00:59 Join Wardo [0] (~Mirandaha@176-120-190-109.dsl.ovh.fr)
18:04:01 Join dionoea_ [0] (~dionoea@oyp.chewa.net)
18:04:05 Join ej0rge_ [0] (~alhaz@207.135.137.71)
18:04:57 Join uwe_mobile__ [0] (~uwe@static.88-198-8-117.clients.your-server.de)
18:17:11 Quit Provel (*.net *.split)
18:17:11 Quit dionoea (*.net *.split)
18:17:11 Quit uwe_mobile (*.net *.split)
18:17:12 Quit ej0rge (*.net *.split)
18:24:30 Quit kaputnik_ (Ping timeout: 264 seconds)
18:32:42 Join Provel [0] (~Provel@75-132-18-44.dhcp.stls.mo.charter.com)
18:40:12***Saving seen data "./dancer.seen"
18:45:01 Join guymann [0] (~c@unaffiliated/guymann)
19:00
19:18:01 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee)
19:38:13 Join jhMikeS [0] (~jethead71@50.4.247.132)
19:38:13 Quit jhMikeS (Changing host)
19:38:13 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS)
19:39:05 Join TheLemonMan [0] (~LemonBoy@adsl-ull-88-221.50-151.net24.it)
19:39:05 Quit TheLemonMan (Changing host)
19:39:05 Join TheLemonMan [0] (~LemonBoy@unaffiliated/thelemonman)
19:55:19 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
20:00
20:10:41 Quit liar (Ping timeout: 264 seconds)
20:13:10 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
20:18:13 Quit liar (Ping timeout: 256 seconds)
20:19:13 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
20:19:31 Join nosa-j [0] (~m00k@184.76.254.130)
20:20:28 Join cydd [0] (~psychocyd@31.193.12.99)
20:20:39 Part cydd
20:27:15 Quit liar (Read error: Operation timed out)
20:29:27 Join Guest35025 [0] (~liar@clnet-p09-185.ikbnet.co.at)
20:35:39 Quit Guest35025 (Read error: Operation timed out)
20:36:40 Join Guest35025 [0] (~liar@clnet-p09-185.ikbnet.co.at)
20:40:14***Saving seen data "./dancer.seen"
20:40:41 Quit Guest35025 (Read error: Operation timed out)
20:41:35 Join cydd666 [0] (cydd@cpc24-york4-2-0-cust463.7-1.cable.virginmedia.com)
20:41:48 Part cydd666
20:47:50 Join krnlyng [0] (~liar@clnet-p09-185.ikbnet.co.at)
20:51:52 Join stripwax [0] (~Miranda@rockbox/developer/stripwax)
20:52:11 Quit bertrik (Remote host closed the connection)
20:58:25 Quit mrtux (Read error: Connection reset by peer)
20:58:29 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
20:58:35 Join mrtux_ [0] (~colin@unaffiliated/mrtux)
20:59:11 Nick mrtux_ is now known as mrtux (~colin@unaffiliated/mrtux)
20:59:35 Quit Scall (Ping timeout: 256 seconds)
21:00
21:01:53 Join Scall [0] (~chat@unaffiliated/scall)
21:02:25 Quit krnlyng (Ping timeout: 256 seconds)
21:05:09 Quit krabador (Quit: Bah...)
21:07:00 Quit pamaury (Ping timeout: 246 seconds)
21:08:05 Join krnlyng [0] (~liar@clnet-p09-185.ikbnet.co.at)
21:11:29 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
21:25:46 Join SuperBrainAK [0] (~Andreas@97-124-72-176.phnx.qwest.net)
21:35:26 Quit stripwax (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
21:36:04 Quit akaWolf (Ping timeout: 248 seconds)
21:41:07 Quit mrtux (Read error: Connection reset by peer)
21:41:27 Join mrtux [0] (~colin@unaffiliated/mrtux)
21:44:35 Quit mrtux (Read error: Connection reset by peer)
21:45:01 Join mrtux [0] (~colin@unaffiliated/mrtux)
21:47:19 Join salty-horse [0] (~ori@bzq-79-180-102-35.red.bezeqint.net)
21:48:51salty-horsehey. about 3.13's "Deleting files in the active playlist now works as expected" - does this also handle resuming playback at the correct file, after adding some new files to the same directory?
21:55:48salty-horsenever mind. commit 212e780 seems to confirm that :)
21:59:56 Quit TheLemonMan (Ping timeout: 276 seconds)
22:00
22:22:47 Quit kiwicam (Remote host closed the connection)
22:38:51 Join kaputnik_ [0] (~kaputnik@port-92-206-20-123.dynamic.qsc.de)
22:39:33 Join stoffel [0] (~quassel@pD9E43C18.dip0.t-ipconnect.de)
22:40:15***Saving seen data "./dancer.seen"
22:42:37 Quit Lynx_ (Remote host closed the connection)
22:42:52 Join Lynx_ [0] (~bayer@109.171.130.211)
22:43:13 Quit stoffel (Remote host closed the connection)
23:00
23:07:26 Join bertrik [0] (~quassel@ip117-49-211-87.adsl2.static.versatel.nl)
23:07:26 Quit bertrik (Changing host)
23:07:26 Join bertrik [0] (~quassel@rockbox/developer/bertrik)
23:08:08 Quit melmothX (Remote host closed the connection)
23:18:57 Quit krnlyng (Read error: Connection reset by peer)
23:19:26 Join krnlyng [0] (~liar@clnet-p09-185.ikbnet.co.at)
23:25:34 Quit krnlyng (Ping timeout: 256 seconds)
23:31:33 Quit pamaury (Ping timeout: 246 seconds)
23:32:41 Join krnlyng [0] (~liar@clnet-p09-185.ikbnet.co.at)
23:34:46 Quit bertrik (Remote host closed the connection)
23:37:18 Quit kevku (Ping timeout: 260 seconds)
23:42:49 Join SuperBrainAK_ [0] (~Andreas@97-124-74-51.phnx.qwest.net)
23:45:53 Quit SuperBrainAK (Ping timeout: 276 seconds)
23:53:36 Quit kaputnik_ (Ping timeout: 246 seconds)
23:55:02 Quit Wardo (Read error: Connection reset by peer)

Previous day | Next day