#rockbox 2011-08-12

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).

#rockbox log for 2011-08-12

00:00:04	kugel	ntfs supports that AFAIK
00:01:19	saratoga	i think this is some virtualbox trick where its driver is smart enough to expand the image file when it loads it
00:01:25	kugel	sideral: no idea then
00:01:47	n1s	saratoga: if you put that on the wiki it would probably be nice if we removed links to the outdated VM's since people seem to still download the oldest one and have trouble with it
00:01:47	sideral	OK, thanks kugel!
00:02:14	kugel	didn't we want to provide .debs of the compilers instead of VM images?
00:02:16	saratoga	n1s: yea i'm going to
00:02:24	saratoga	just hoping someone else could test it to make sure it works on other systems
00:02:42	saratoga	in case i somehow made it 64 bit only or something stupid
00:03:11	sideral	saratoga: I've stumbled over some MP3 files that contain a lot of 0x55 (padding?) bytes after the ID3v2 header (after id3->first_frame_offset bytes), interspersed with some "LAME3.98." strings and other junk. Any idea what that might be?
00:03:23	saratoga	sideral: probably padding
00:03:40	saratoga	usually id3v2 tags are padded to the nearest 4k or 16k or whatever boundary
00:03:43	n1s	saratoga: if i have time tomorrow i can try it on my netbook
00:03:51	saratoga	that way if someone adds a tag you don't have to rewrite the entire file
00:03:58	sideral	does the codec know to ignore these bytes despite first_frame_offset pointing before them?
00:03:59	n1s	(which is 32 bit)
00:05:33	saratoga	sideral: assuming its padding, it should, most id3v2 tags will have it
00:05:38	saratoga	if its something else then maybe not
00:05:54	kugel	jhMikeS: how errno isn't thread-local is it?
00:06:34	saratoga	" The value of the padding bytes must be $00."
00:06:38	saratoga	hmm so maybe not padding
00:07:04	saratoga	could be part of embedded album art or something
00:08:23	sideral	saratoga: Here's part of that data: http://pastebin.com/LisbiB0G
00:08:34	jhMikeS	kugel: no
00:09:26	kugel	any reason for that?
00:09:32	kugel	other than we don't bother? :)
00:09:45	kugel	not that we use errno extensively
00:09:46	jhMikeS	I think nobody bothered
00:10:02	saratoga	sideral: doesn't look familiar to me, but i don't know much about ID3
00:10:21	sideral	could this be part of an MPEG program stream?
00:11:37	saratoga	i don't think so
00:11:55	saratoga	the mpeg headers are small, and the contents of the stream itself are compressed and so would not have such low entropy sequences
00:12:10	sideral	file says these tracks are Audio Data Transport Streams (ADTS)
00:12:15	saratoga	you could try opening the file in foobar and see what it reports
00:12:32		Quit domonoky (Read error: Connection reset by peer)
00:13:11	sideral	Never used that program. Is it Win-only?
00:13:56	saratoga	yeah
00:14:16	saratoga	its kind of the gold standard
00:14:41	saratoga	what happens when rockbox loads this file?
00:15:00	sideral	it just works
00:15:19	sideral	mpg123 says there's a Xing header in there. what is that?
00:16:05	Torne	VBR index thingy
00:16:32	saratoga	Xing headers are on pretty much all modern mp3 files
00:17:05	saratoga	usually a modern file has a xing header and a lame tag at the top
00:17:37	sideral	maybe that's it? there's this strange LAME substring in there
00:19:13	saratoga	the usual headers are very short, pretty much just a few bytes identifing the file, some gapless info and a 100 entry seek table
00:20:50	sideral	yeah, something like that is just before the 0x55 block
00:21:27	saratoga	if you're already like 5KB into the file, you're probably looking at the end of an id3v2 tag
00:21:34		Quit drezon (Read error: Operation timed out)
00:22:27	sideral	The 0x55 extend 12 KB into the file
00:22:41	sideral	also, I just noticed that there are more 0x55 at the end of the file
00:24:06	sideral	I think there's a good chance that this is not ID3v2. I downloaded the file from Soundcloud, where there usually are no ID3 headers/footers, and tacked on the (short) ID3v2 header afterwards
00:25:51	saratoga	people do weird things to mp3 files since you can usually get away with it
00:25:55	sideral	(just downloading it again to make sure)
00:26:08	saratoga	foobar at least should be able to strip and retag the stream
00:26:47	saratoga	huh 7zip compression is not as good if i use 10 threads instead of just 2
00:27:07	saratoga	maybe i can get that image under 500MB
00:28:46		Nick soap_ is now known as soap (~soap@rockbox/staff/soap)
00:28:49	sideral	my motivation is that I'd like to ID tracks by CRCing a part of them (for fixing fuzzy DB resurrection), and those redundant parts give me duplicates
00:29:13	sideral	so I'd like to know whether there's a way to find the real compressed audio data
00:29:25	saratoga	the mpeg headers let you know if you're looking at audio data
00:30:02		Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com)
00:30:12	saratoga	although thats obviously MP3 specific
00:30:58	sideral	I'd like to rely on whatever the metadata parser puts into the mp3entry structure
00:32:04	sideral	but right now only the MP3 parser makes a half-assed attempt to identify the end of the header by filling in a non-zero first_frame_offset
00:32:19	saratoga	yea i think some of the logic is in mpa.c
00:32:45	saratoga	alternatively, you could look at the mp3 CRC, which is always at the start of the file and should be unique on almost all files
00:32:59	saratoga	although in theory someone could have decided to remove it
00:33:16	sideral	interesting idea
00:33:38	saratoga	would be easy enough to have the metadata parser store it if it doesn't already
00:33:52	sideral	yeah
00:34:01	saratoga	it has to parse that header anyway
00:34:09	n1s	also mp3 specific though
00:34:12	sideral	that would save the CRC computation at least for MP3 files
00:34:53	saratoga	i think vorbis has a crc too
00:35:17	saratoga	as do pretty much all lossless format
00:35:25	sideral	how would streamable formats fill this in?
00:35:35	n1s	it has a per page or packet or whatever they are called one but not sure about a whole file one but possibly
00:35:47	n1s	ogg that is
00:36:16	saratoga	yeah so its just a crc of the start of the file, but should be unique since its hard to combine vorbis files in a way that renders them playable in rockbox :)
00:36:33	sideral	hmm. problem is a CRC of the first few seconds is not enough, as many podcasts have the same audio intro
00:36:44	sideral	that's on trap I already stepped into :)
00:37:13	sideral	right now I'm seeking 10 KB into the file
00:37:32	sideral	er, 1 MB
00:38:08	saratoga	try it and see
00:38:17	saratoga	i bet its rare to have an identical start even if the audio is the same
00:38:27	sideral	I did try that, and I found dupes
00:38:37	saratoga	with the vorbis crc?
00:39:01	sideral	no, with MP3-encoded podcasts, CRCing the actual audio data myself
00:39:13	saratoga	wow tweaking the 7zip parameters shaved ~60MB off the file size
00:39:27	saratoga	but you only CRCed a point 10KB into the file?
00:39:55	saratoga	would guess that you had tracks with the same embedded album art file :)
00:40:04	sideral	I tried various points: directly after first_frame_offset, first_frame_offset + 4 KB, +10 KB, and +1 MB
00:40:47	sideral	saratoga: No, I skipped behind any ID3 header (first_frame_offset does that much)
00:41:15		Join Scromple [0] (~Simon@115-64-195-104.static.tpgi.com.au)
00:41:27		Quit robin0800 (Remote host closed the connection)
00:41:30	sideral	also, my podcast downloader shaves off any album art
00:42:11	n1s	what is this crc'ing for?
00:42:15	sideral	anyway, I got lots of dupes at offsets < 10 KB
00:42:19		Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com)
00:43:10	sideral	n1s: The context is FS #12076, where I now try to restore the fuzzy resurrection feature that I turned off before because it resurrected DB data for similar, but nonidentical tracks
00:43:11	fs-bluebot	http://www.rockbox.org/tracker/task/12076 Autoresume feature can start from wrong offset due to resurrection of old runtime stats (bugs, assigned)
00:43:56	sideral	my approach right now is to ID the audio to tell similarly tagged tracks apart
00:44:07	kugel	great, hwcodec seems to work with buflib as well
00:45:01	saratoga	http://duke.edu/~mgg6/rockbox/rockbox_virtualbox.7z
00:45:07	saratoga	smaller file
00:45:52	n1s	sideral: so you want to store the crc in the db for each file and check it if a file moves?
00:46:04		Quit HaimN (Ping timeout: 240 seconds)
00:46:19	sideral	right
00:46:31		Join HaimN [0] (~quassel@212.76.114.232)
00:47:06	sideral	if too few tags match, I'd rerun the CRC and compare that
00:47:19		Join Thra11 [0] (~thrall@91.125.143.156)
00:49:56	sideral	is 0xfffb an MPEG syncronization mark?
00:51:43	n1s	random offsetts etc might hit some special location in some specific file type so i'd say full crc's is the way to go but the initial crc calculation when building the db would be sort of expensive
00:52:43	sideral	yeah, that'd be too expensive. I'm already worried because seeking to 10 MB to avoid dupes might be taking to long.
00:53:00	sideral	And the issue of skipping over any metadata the user might have changed in between remains
00:53:12	n1s	many files won't be 10MB so you'd end up at the end of them too
00:53:13	kugel	full crc if tags change, no?
00:53:21	kugel	+fails
00:53:29	sideral	so it'd have to be full CRC minus the metadata
00:53:33	n1s	kugel: yeah but you need the crc to compare to
00:54:10	kugel	the crc is meant as additional measure if the tags changed, iirc
00:54:10	sideral	kugel: the idea is to find retagged, renamed tracks that are actually the same track as one the DB already knows about
00:54:39	n1s	i've seen files with 1MB AA and such an album would probably get all identical crc's if you crc'ed a few kb at some offset in the image
00:54:54	sideral	kugel: (The existing CRCs have another purpose. they're just hashes for tag strings that might not be in the DB any more.)
00:55:34	sideral	n1s: I'd hope that AA would be skipped as metadata, that is id3->first_frame_offset would point after the AA
00:56:48	n1s	yes it should, i thought you were doing file offsetts
00:57:09	sideral	yeah, this won't work for small files. but those generally don't have the problem this is trying to solve, which seems to be fairly specific to podcasts (episodes with very similar metadata)
00:57:19	n1s	audio offsetts hould be more reliable but you can still hit corner cases
00:58:22	n1s	emulated and chip formats might also have identical parts that are not metadata though
00:58:39	n1s	anyway, i think this kind of guesswork logic is a bad idea
00:58:50	sideral	n1s: yeah, I ran into that as well with my atari chiptunes library :)
00:59:09	kugel	n1s: i tend to agree
00:59:42	kugel	but then i dont see lots of value in this resurrection
00:59:43	sideral	I personally don't rely on fuzzy resurrection either, but roolku found it important enough to reopen the FS task
01:00
01:00:24	sideral	(non-fuzzy) resurrection, though, is rather critical to have, because it's the only mechanism to recover DB data for tracks on removable media
01:01:14	sideral	the point of this work is to reenable fuzzy resurrection by making it more precise
01:01:37	sideral	by IDing the tracks with audio-data CRCs
01:02:44	sideral	convincing people to drop fuzzy resurrection for good certainly would be easier than completing this work :)
01:05:50		Quit n1s (Remote host closed the connection)
01:33:12		Nick scorche` is now known as scorche (~scorche@rockbox/administrator/scorche)
01:35:29		Part Zagor
01:36:48		Join Thra11_ [0] (~thrall@113.190.pn.adsl.brightview.com)
01:40:35		Quit Thra11 (Ping timeout: 276 seconds)
01:44:15		Quit saratoga (Quit: Page closed)
01:46:51		Quit sideral (Quit: Leaving.)
01:55:58		Join SecretofMana [0] (~spiritofm@204.237.38.224)
01:56:34	***	Saving seen data "./dancer.seen"
02:00
02:03:24		Quit liar (Ping timeout: 258 seconds)
02:05:27		Quit Thra11_ (Ping timeout: 264 seconds)
02:11:36		Quit lebellium (Quit: ChatZilla 0.9.87 [Firefox 6.0/20110804030150])
02:19:14		Quit mc2739 (Quit: leaving)
02:19:55		Join mystica555 [0] (~mike@216.58.116.195)
02:20:05		Join Thra11_ [0] (~thrall@113.190.pn.adsl.brightview.com)
02:20:52		Join mc2739 [0] (~mc2739@rockbox/developer/mc2739)
02:27:39		Quit HaimN (Ping timeout: 264 seconds)
02:28:43		Quit Thra11_ (Quit: kthxbai)
02:34:38		Join Thra11 [0] (~thrall@113.190.pn.adsl.brightview.com)
02:37:20		Quit mc2739 (Quit: leaving)
02:40:47		Join mc2739 [0] (~mc2739@rockbox/developer/mc2739)
02:41:02		Quit stripwax (Quit: http://miranda-im.org)
02:43:40		Join ChickeNE_ [0] (HydraIRC@99-133-145-177.lightspeed.cicril.sbcglobal.net)
02:47:34		Quit Thra11 (Ping timeout: 240 seconds)
02:50:36		Join bluefoxx_ [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net)
02:51:43		Quit bluefoxx (Ping timeout: 240 seconds)
03:00
03:04:13		Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com)
03:08:20		Quit bertrik (Quit: :tiuQ)
03:09:22		Quit mc2739 (Remote host closed the connection)
03:10:23		Join mc2739 [0] (~mc2739@rockbox/developer/mc2739)
03:13:51		Quit robin0800 (Quit: Leaving)
03:17:02		Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com)
03:19:54		Join mordocai [0] (~mordocai@mail.mordocai.net)
03:20:17		Quit robin0800 (Remote host closed the connection)
03:22:14		Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net)
03:24:49		Quit mordocai (Quit: Leaving)
03:30:46		Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com)
03:31:03		Quit Strife89 (Ping timeout: 252 seconds)
03:31:10		Join Strife89 [0] (~Strife89@207-144-19-39.cstel.net)
03:32:21		Quit robin0800 (Client Quit)
03:41:33		Quit MethoS- (Remote host closed the connection)
03:42:59		Quit markun (Ping timeout: 276 seconds)
03:56:36	***	Saving seen data "./dancer.seen"
04:00
04:25:46		Quit amiconn (Disconnected by services)
04:25:46		Join amiconn_ [0] (quassel@rockbox/developer/amiconn)
04:26:06		Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn)
04:26:42		Quit pixelma (Disconnected by services)
04:26:44		Join pixelma_ [0] (quassel@rockbox/staff/pixelma)
04:26:46		Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma)
04:27:12		Quit skx` (Ping timeout: 240 seconds)
04:27:30		Join skx` [0] (~skx@78-20-16-156.access.telenet.be)
04:33:04		Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com)
04:42:53		Quit robin0800 (Quit: Leaving)
04:58:05		Quit [7] (Disconnected by services)
04:58:17		Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven)
05:00
05:10:54		Quit sinthetek (Ping timeout: 252 seconds)
05:11:42		Join sinthetek [0] (~sinthetek@cpe-174-111-016-189.triad.res.rr.com)
05:11:42		Quit sinthetek (Changing host)
05:11:42		Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek)
05:20:36		Join pireau [0] (1000@pdpc/supporter/student/pireau)
05:32:43		Quit Horscht (Quit: Verlassend)
05:35:35		Quit ps-auxw (Ping timeout: 255 seconds)
05:37:45		Join Rob2222 [0] (~Miranda@p5DE4B182.dip.t-dialin.net)
05:39:23		Join ps-auxw [0] (~arneb@p4FF7EE4A.dip.t-dialin.net)
05:41:28		Quit Rob2223 (Ping timeout: 250 seconds)
05:56:38	***	Saving seen data "./dancer.seen"
06:00
06:23:06		Join jbeatty [0] (~jbeatty@c-75-64-73-152.hsd1.tn.comcast.net)
06:23:20	jbeatty	is Rockbox 100% libre or does it contain proprietary firmware?
06:31:30	JdGordon	100%
06:32:01	JdGordon	well... depends on how much you want to fight the FSF regarding GPL
06:32:11	jbeatty	BSD code is libre
06:32:29	JdGordon	gpl isnt
06:33:07	jbeatty	freedom-for-users, not freedom-for-developers ;) it's a debate I'd be happy to indulge in if I had the time.
06:33:40	jbeatty	at the moment I'm just trying to find a good media player for my younger brother without sacrificing principles
06:36:13	JdGordon	your principles dont exten as far as IP protection?
06:37:38	jbeatty	if people don't want to deal with the "viral" nature of the GPL, don't use GPL code
06:37:46	jbeatty	it's really that simple.
06:38:18	jbeatty	(but to be more to the point, no, I don't believe in "intellectual property")
06:39:29	alexbobp	I <3 the GPL
06:40:01	alexbobp	it basically establishes the community as a company in competition with all the vendors of proprietary software
06:40:13	alexbobp	which IMO is what we need if we actually want to see open source beat proprietary software
06:40:16	alexbobp	in the market
06:40:37		Quit SecretofMana ()
06:40:41	jbeatty	exactly, plus the GPL is an easy way for developers to firmly state "I do not want my code in proprietary products"
06:40:54	jbeatty	which is the essense of the whole IP argument in the first place, right? developer desires?
06:41:09	JdGordon	this is off topic, join #rockbox-community
06:41:46		Part jbeatty
06:42:40		Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net)
07:00
07:20:21		Join stoffel [0] (~quassel@p57B49F87.dip.t-dialin.net)
07:28:32		Quit Strife89 (Read error: Operation timed out)
07:30:51		Quit wtachi (Ping timeout: 258 seconds)
07:43:17		Join JdGord [0] (~AndChat@122.110.244.206)
07:53:18		Join Buschel [0] (~chatzilla@p54A3ACDA.dip.t-dialin.net)
07:56:40	***	Saving seen data "./dancer.seen"
07:57:28	CIA-14	New commit by buschel (r30282): Remove unused sources from libgme.
07:59:29	CIA-14	r30282 build result: All green
08:00
08:00:27		Join HaimN [0] (~quassel@212.76.114.232)
08:05:59		Quit JdGord (Read error: Connection reset by peer)
08:06:13		Join JdGord [0] (~AndChat@122.110.244.206)
08:09:59		Quit powell14ski_ (Quit: powell14ski_)
08:13:47		Quit factor (Remote host closed the connection)
08:15:13		Quit stoffel (Remote host closed the connection)
08:16:06		Join B4gder [0] (~daniel@www.haxx.se)
08:16:06		Quit B4gder (Changing host)
08:16:06		Join B4gder [241] (~daniel@rockbox/developer/bagder)
08:18:31		Join sideral [0] (~sideral@rockbox/developer/sideral)
08:23:42		Quit Buschel (Quit: ChatZilla 0.9.87 [Firefox 3.6.18/20110614230723])
08:30:08		Join Zagor [242] (~bjst@rockbox/developer/Zagor)
08:36:02		Join factor [0] (~factor@74.197.205.204)
08:36:51		Join FoH_Phobos [0] (~foh@adsl-98-83-162-86.bhm.bellsouth.net)
08:48:18		Quit bluefoxx_ (Ping timeout: 260 seconds)
09:00
09:00:26		Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
09:01:21		Join ender` [0] (~ender@foo.eternallybored.org)
09:08:36		Quit kadoban (Ping timeout: 258 seconds)
09:09:16		Quit JdGord (Quit: Bye)
09:14:10		Quit Scromple (Read error: Connection reset by peer)
09:15:04		Join petur [0] (~petur@rockbox/developer/petur)
09:15:27		Join lebellium [0] (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr)
09:16:33		Quit Keripo (Quit: Leaving.)
09:16:47		Quit sideral (Quit: Leaving.)
09:20:19		Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net)
09:21:39		Join sideral [0] (~sideral@rockbox/developer/sideral)
09:24:00		Quit sideral (Client Quit)
09:27:02		Quit FoH_Phobos (Quit: ¡ooʇ ‘ǝןdoǝd ǝɹɐ sʇɐq)
09:34:02		Quit pixelma (Disconnected by services)
09:34:04		Join pixelma_ [0] (quassel@rockbox/staff/pixelma)
09:34:07		Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma)
09:34:15		Quit amiconn (Disconnected by services)
09:34:15		Join amiconn_ [0] (quassel@rockbox/developer/amiconn)
09:34:35		Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn)
09:37:54		Join n1s [0] (~quassel@rockbox/developer/n1s)
09:56:44	***	Saving seen data "./dancer.seen"
10:00
10:05:08		Join sideral [0] (~sideral@rockbox/developer/sideral)
10:16:12		Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
10:21:49		Quit HaimN (Ping timeout: 258 seconds)
10:22:15		Join HaimN [0] (~quassel@212.76.114.232)
10:39:41		Quit God_Eater (Quit: Page closed)
10:41:01		Join God_Eater [0] (93722cc8@rockbox/staff/GodEater)
10:44:20		Join lorenzo92 [0] (~chatzilla@host18-111-dynamic.20-79-r.retail.telecomitalia.it)
10:48:39		Join pamaury [0] (~quassel@cez63-2-88-164-98-172.fbx.proxad.net)
10:48:39		Quit pamaury (Changing host)
10:48:39		Join pamaury [0] (~quassel@rockbox/developer/pamaury)
10:50:20		Join markun [0] (~markun@s3eea32f5.adsl.wanadoo.nl)
10:59:34		Quit lorenzo92 (Quit: ChatZilla 0.9.87 [Firefox 5.0/20110622232440])
11:00
11:07:34		Quit pamaury (Remote host closed the connection)
11:15:31		Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
11:25:04		Quit Xerion (Read error: Connection reset by peer)
11:25:56		Quit kadoban (Ping timeout: 250 seconds)
11:38:22		Join mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de)
11:40:12		Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com)
11:43:55		Join drezon [0] (~skeller@2a01:238:4200:7e03:f2de:f1ff:fe4f:3584)
11:51:10		Quit ChickeNE_ (Quit: Computer has gone to sleep.)
11:56:45	***	Saving seen data "./dancer.seen"
11:57:53		Quit robin0800 (Remote host closed the connection)
11:57:54		Join bluefoxx [0] (fuzzylomba@2002:4647:1f1f::4647:1f1f)
12:00
12:03:43		Quit HaimN (Ping timeout: 250 seconds)
12:04:12		Join HaimN [0] (~quassel@212.76.114.232)
12:47:13		Quit GigaBrick (Remote host closed the connection)
12:53:19		Quit petur (Quit: plop)
13:00
13:31:53	*	n1s ponders trying to clean up the codec optimization flag mess but is lacking good ideas.
13:32:37	n1s	AFAICT we can do it like we do now, setting the flags directly in the makefiles or we could use #pragmas handled by the PP
13:33:05	Zagor	what advantage would #pragmas give?
13:34:01	n1s	slightly easier to do them per arm generation without duplicating that stuff as make vars but not much else
13:34:42	n1s	the big problem is that to be optimal we need a setting per arch(generation (for arm)) per codec
13:34:53	n1s	atm it's only arm/cf/default
13:35:05	Zagor	I think a major drawback is that we don't have compiler flags outside the makefiles anywhere else (or do we?)
13:35:47	n1s	i don't think so
13:36:25	n1s	i don't think that we do that is. i agree it is a drawback as it's a bit non obvious that a header would set these flags
13:36:57	Zagor	yes. some ifdef magic in the makefiles should be able to do the same, no?
13:38:38	n1s	probably
13:41:14	Zagor	that gets my vote then
13:41:22	n1s	it would be neat to have it a bit centralized so you could set a default for an arch and define exceptions only where needed. can make do that?
13:41:37	Zagor	sure
13:42:52	n1s	i wonder if something like that could go in the template stuff...
13:43:22	n1s	i guess i need to read up a bit on make :)
13:50:26		Join antil33t [0] (~antil33t@124-197-33-15.callplus.net.nz)
13:55:54		Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel)
13:56:35	kugelp	n1s: newer gcc allow pragma for optimization
13:56:49	***	Saving seen data "./dancer.seen"
13:56:51	kugelp	4.5+ iirc
13:58:31	sideral	I think you can define target-specific compiler flags in GNU Make, as in: plugin.o: OPTFLAGS = -Osomething # defines these OPTFLAGS for all dependencies of plugin.o
13:59:17	sideral	look for "Target-specific Variable Values" in the make info doc
13:59:34		Join germanmushroom [0] (~remco@s5146db6a.adsl.wanadoo.nl)
14:00
14:03:49		Quit bluefoxx (Read error: Connection reset by peer)
14:04:11		Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net)
14:04:55		Quit AlexP (Remote host closed the connection)
14:11:02		Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel)
14:18:47	n1s	kugel: yes i know, that's why i suggested it as a possible way to do it
14:19:07	kugel	I would prefer that way
14:19:14	n1s	why?
14:20:02	n1s	according to the docs it works in 4.4 to otherwise it would be quite useless with our current arm toolchain
14:20:23	n1s	but why do you prefer it over makefiles?
14:20:53		Quit antil33t ()
14:21:25		Join AlexP [0] (~alex@rockbox/staff/AlexP)
14:23:08	kugel	I dislike working with makefiles
14:23:51	n1s	i do too but that is the only reason i can come up with :)
14:24:02	kugel	isn't that enough?
14:24:33	kugel	another reason is that changing the makefiles doesn't trigger a rebuild as changing the source files does, which very often trapped me
14:24:35	Zagor	unless you want to replace make with something else, splitting compiler options into more files isn't an improvement
14:26:00	gevaerts	kugel: disliking something enough reason to prefer something else, sure, but it's usually not a convincing argument :)
14:27:34	n1s	sideral: yes, that might come in handy
14:28:14		Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il)
14:34:20	n1s	Zagor: is the rule in codecs.make used for the files in a codec subdir if there's no special compilation rule in the subdir's .make?
14:48:47	Zagor	yes
14:49:05	n1s	aha, thanks
14:49:13	Zagor	or, let me check
14:52:05		Join MethoS- [0] (~clemens@134.102.106.250)
14:52:09	Zagor	which directory has no .make?
14:53:07	n1s	uh, no. i mean if there's no rule for making the .o'
14:53:13	n1s	s in the .make
14:53:32	n1s	for example http://svn.rockbox.org/viewvc.cgi/trunk/apps/codecs/libatrac/libatrac.make?r1=29042&r2=29041&pathrev=29042
14:54:28	kugel	they are made with the default rules by adding them to OTHER_SRC, IIUC
14:54:37	Zagor	yes
14:54:55	Zagor	rules are path mathing and don't care where the makefile is located
14:54:59	Zagor	matching
14:56:05	Zagor	all files without explit rules are compiled by the general rule in root.make
14:56:19	Zagor	$(BUILDDIR)/%.o: $(ROOTDIR)/%.c
14:56:51	n1s	aha, ok
14:58:17	Zagor	yikes, a <2min build round
14:59:33	*	kugel wonders if roolku considered to put the ccache on a ramdisk
14:59:58	kugel	I did, but 4GB RAM is not enough :)
15:00
15:05:09		Join gilkup [0] (~gilkup@93-172-174-53.bb.netvision.net.il)
15:09:18		Quit gilkup (Client Quit)
15:16:03		Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com)
15:23:29		Join wtachi [0] (~wtachi@cpe-069-134-168-033.nc.res.rr.com)
15:25:25		Quit n1s (Remote host closed the connection)
15:26:37		Quit robin0800 (Remote host closed the connection)
15:29:14	AlexP	We'd be buggered without roolku :)
15:29:30		Quit HaimN (Ping timeout: 246 seconds)
15:29:59		Join HaimN [0] (~quassel@212.76.114.232)
15:37:01		Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com)
15:50:56		Join dunkaist [0] (~dunkaist@bp-203-106.dialup.vitebsk.by)
15:56:52	***	Saving seen data "./dancer.seen"
15:57:25		Quit B4gder (Remote host closed the connection)
16:00
16:03:01		Join lebellium_ [0] (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr)
16:04:29		Quit lebellium (Ping timeout: 258 seconds)
16:04:41		Nick lebellium_ is now known as lebellium (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr)
16:11:00		Quit simonlnu (Ping timeout: 258 seconds)
16:12:59		Join simonlnu [0] (2o6h3nYxGI@unaffiliated/simonrvn)
16:17:42		Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93)
16:18:38	kugel	AlexP: shh, don't tell this in public! :)
16:22:14		Join Horscht [0] (~Horscht@p5DD5779F.dip.t-dialin.net)
16:22:14		Quit Horscht (Changing host)
16:22:14		Join Horscht [0] (~Horscht@xbmc/user/horscht)
16:27:59		Quit robin0800 (Remote host closed the connection)
16:56:07		Quit HaimN (Ping timeout: 240 seconds)
16:58:32		Quit dunkaist (Ping timeout: 258 seconds)
16:58:46		Join Thra11 [0] (~thrall@209.190.pn.adsl.brightview.com)
16:59:55		Quit germanmushroom (Read error: Connection reset by peer)
17:00
17:02:24	kugel	gevaerts: is there something you want to see (and I have perhaps forgotten about) before gsoc ends?
17:03:17	kugel	I'm basically done with compaction enablement, so I'm testing right, and not sure if there's anything left to implement (since we yesterday agreed on not touching buffering for now)
17:09:10		Join dunkaist [0] (~dunkaist@82.209.203.197)
17:09:20		Join HaimN [0] (~quassel@212.76.114.232)
17:10:39		Join powell14ski_ [0] (~powell14s@c-174-51-194-6.hsd1.co.comcast.net)
17:14:24		Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com)
17:15:41		Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com)
17:17:45	kugel	jhMikeS: ping
17:18:41		Part Zagor
17:24:11	gevaerts	kugel: I'd like to see as much of your work committed as possible, but apart from that I can't really think of anything
17:26:48		Join fml [0] (~chatzilla@manz-590f186f.pool.mediaWays.net)
17:27:16		Join Xerion [0] (~xerion@5419A766.cm-5-2c.dynamic.ziggo.nl)
17:28:31		Join Thra11_ [0] (~thrall@148.14.113.87.dyn.plus.net)
17:29:09	fml	The order of file formats delivered by the wps tag %fc does not correspont to what is said in the manual. MP3 is not the third option. Is that a known bug?
17:31:47		Quit Thra11 (Ping timeout: 276 seconds)
17:40:08		Quit HaimN (Remote host closed the connection)
17:44:01	AlexP	fml: It seems to have been changed in r30225
17:44:08	AlexP	fml: But the manual wasn't updated
17:44:24	AlexP	I don't know if it affects any inbuilt wps
17:44:27		Join Thra11__ [0] (~thrall@87.113.230.201)
17:44:35	AlexP	Or if the wiki page was updated
17:45:34	fml	AlexP: what? The order of the results?
17:45:36	AlexP	fml: The order of the tag
17:45:36	AlexP	by kugel
17:45:36	*	fml looks...
17:46:41	pixelma	why has the order changed?
17:46:42	pixelma	I think new formats should go to the end
17:46:42	AlexP	It isn't new
17:46:42	AlexP	MP1 was moved out of the all players section at the start and put into the swcodec section afterwards
17:46:47	fml	...but the site seems to be down ATM
17:46:50		Quit Thra11_ (Ping timeout: 258 seconds)
17:46:55	AlexP	So instead of mp1 mp2 mp3 it goes mp2 mp3 mp1
17:46:59	kugel	I didn't think of that
17:51:21	kugel	the commit can be remade to not break the order (not for swcodec at least) if needed
17:51:21	AlexP	fml: http://pastebin.com/3hFVVn3x
17:51:21	AlexP	kugel: It might be nice so we don't break any themes that use the tag
17:51:21	AlexP	Well, break is a bit strong
17:51:21	DBUG	Enqueued KICK AlexP
17:51:21	AlexP	make incorrect :)
17:51:21		Quit Topy (Read error: Connection reset by peer)
17:51:21	fml	AlexP: ah, now I see. On the one hand, a particular order doesn't matter match. But OTOH it seems more logical if it's MP1, MP2, MP3. I think the patch could be done in a way that would preserve the order (with a bit more typing in the source).
17:51:21	fml	s/match/much
17:51:21	AlexP	Yes, it would be more logical, and it wouldn't make existing themes incorrect
17:51:21	***	Alert Mode level 1
17:51:21	AlexP	But it depends how much more complicated it makes it whether it is worth it
17:51:21	kugel	fml: can you do that? busy atm
17:51:41		Quit logbot (Ping timeout: 252 seconds)
17:51:41	***	ERROR: (Closing Link: giant.haxx.se (Ping timeout: 252 seconds)) from hubbard.freenode.net
17:51:41	***	Cleanup
17:51:41	***	Cleanup
17:51:41	***	Saving seen data "./dancer.seen"
17:51:41	***	Exit
17:51:43	***	Started Dancer V4.16
17:51:43	***	Connected to irc.freenode.net on port 6667
17:51:43	***	Logfile for #rockbox started
17:51:45	Mode	"logbot :+i" by logbot
17:51:49	***	Server message 501: 'logbot :Unknown MODE flag'
17:51:49		Join logbot [0] (~rockbox@giant.haxx.se)
17:51:49		Join Thra11__ [0] (~thrall@87.113.230.201)
17:51:49		Join Xerion [0] (~xerion@5419A766.cm-5-2c.dynamic.ziggo.nl)
17:51:49		Join fml [0] (~chatzilla@manz-590f186f.pool.mediaWays.net)
17:51:49		Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com)
17:51:49		Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com)
17:51:49		Join powell14ski_ [0] (~powell14s@c-174-51-194-6.hsd1.co.comcast.net)
17:51:49		Join dunkaist [0] (~dunkaist@82.209.203.197)
17:51:49		Join Horscht [0] (~Horscht@xbmc/user/horscht)
17:51:49		Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93)
17:51:49		Join simonlnu [0] (2o6h3nYxGI@unaffiliated/simonrvn)
17:51:49		Join lebellium [0] (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr)
17:51:49		Join wtachi [0] (~wtachi@cpe-069-134-168-033.nc.res.rr.com)
17:51:49		Join MethoS- [0] (~clemens@134.102.106.250)
17:51:49		Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il)
17:51:49		Join AlexP [0] (~alex@rockbox/staff/AlexP)
17:51:49		Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net)
17:51:49		Join drezon [0] (~skeller@2a01:238:4200:7e03:f2de:f1ff:fe4f:3584)
17:51:49		Join mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de)
17:51:49		Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
17:51:49		Join markun [0] (~markun@s3eea32f5.adsl.wanadoo.nl)
17:51:49		Join God_Eater [0] (93722cc8@rockbox/staff/GodEater)
17:51:49		Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
17:51:49		Join sideral [0] (~sideral@rockbox/developer/sideral)
17:51:49		Join amiconn [0] (quassel@rockbox/developer/amiconn)
17:51:49		Join pixelma [0] (quassel@rockbox/staff/pixelma)
17:51:49		Join ender` [0] (~ender@foo.eternallybored.org)
17:51:49		Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
17:51:49		Join factor [0] (~factor@74.197.205.204)
17:51:49		Join ps-auxw [0] (~arneb@p4FF7EE4A.dip.t-dialin.net)
17:51:49		Join Rob2222 [0] (~Miranda@p5DE4B182.dip.t-dialin.net)
17:51:49		Join pireau [0] (1000@pdpc/supporter/student/pireau)
17:51:49		Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek)
17:51:49		Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven)
17:51:49		Join skx` [0] (~skx@78-20-16-156.access.telenet.be)
17:51:49		Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net)
17:51:49		Join mc2739 [0] (~mc2739@rockbox/developer/mc2739)
17:51:49		Join mystica555 [0] (~mike@216.58.116.195)
17:51:49		Join maraz [0] (maraz@kapsi.fi)
17:51:49		Join evilnick [0] (~evilnick@rockbox/staff/evilnick)
17:51:49		Join user890104 [0] (~Venci@83.228.31.135)
17:51:49		Join ender\| [0] (~ender1@foo.eternallybored.org)
17:51:49		Join Elfish [0] (amba@2a01:4f8:100:90a1:abc:abc:abc:abc)
17:51:49		Join otih [0] (~otih@CAcert/Assurer/otih)
17:51:49		Join dre [0] (dre@gateway/shell/xzibition.com/x-iyvoeejaadvazojo)
17:51:49		Join fs-bluebot [0] (~fs-bluebo@g224238024.adsl.alicedsl.de)
17:51:49		Join pjm0616 [0] (~user@114.200.203.101)
17:51:49		Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother)
17:51:49		Join yosafbri` [0] (~yosafbrid@li125-242.members.linode.com)
17:51:49		Join Utchybann [0] (~Utchy@rps6752.ovh.net)
17:51:50		Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS)
17:51:50		Join scorche [0] (~scorche@rockbox/administrator/scorche)
17:51:50		Join FOAD [0] (~dok@83.161.135.61)
17:51:50		Join Kudo-san [0] (~kudo@wireless.sit-co.net)
17:51:50		Join preglow [0] (thomj@tvilling2.pvv.ntnu.no)
17:51:50		Join aevin [0] (eivindsy@unaffiliated/aevin)
17:51:50		Join user829385 [0] (~aoeu@112.166.15.141)
17:51:50		Join gevaerts [0] (~fg@rockbox/developer/gevaerts)
17:51:50		Join Llorean [0] (~DarkkOne@rockbox/user/Llorean)
17:51:50		Join mikroflops [0] (~yogurt@h-34-156.a238.priv.bahnhof.se)
17:51:50		Join Staphylo [0] (staphylo@hyperion.epimeros.org)
17:51:50		Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de)
17:51:50		Join Bagder [241] (~daniel@rockbox/developer/bagder)
17:51:50		Join n17ikh [0] (~n17ikh@c-174-56-150-44.hsd1.sc.comcast.net)
17:51:50		Join rudi_s [0] (~simon@austria125.server4you.de)
17:51:50		Join Zambezi [0] (Zulu@unaffiliated/zambezi)
17:51:50		Join kugel [0] (~kugel@rockbox/developer/kugel)
17:51:50		Join ranmachan [0] (ranma@2a01:4f8:130:9321::2)
17:51:50		Join GodEater [0] (~bibble@rockbox/staff/GodEater)
17:51:50		Join jordan` [0] (~gromit@2001:660:3302:2826:225:90ff:fe20:d9a8)
17:51:50		Join tmzt [0] (~tmzt@adsl-99-164-33-12.dsl.akrnoh.sbcglobal.net)
17:51:50		Join Guinness [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net)
17:51:50		Join ft [0] (efftee@shell.chaostreff-dortmund.de)
17:51:50		Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net)
17:51:50		Join krazykit [0] (~quassel@li135-248.members.linode.com)
17:51:50		Join merbanan [0] (~banan@c-83-233-52-54.cust.bredband2.com)
17:51:50		Join bthomson [0] (~bthomson@c-68-33-5-232.hsd1.va.comcast.net)
17:51:50		Join Galois [0] (djao@efnet-math.org)
17:51:50		Join parafin [0] (parafin@paraf.in)
17:51:50		Join zu [0] (~zu@ks355000.kimsufi.com)
17:51:50		Join simabeis [0] (~simabeis@lobmenschen.de)
17:51:50		Join JdGordon [0] (~jonno@rockbox/developer/JdGordon)
17:51:50		Join dionoea [0] (~dionoea@yop.chewa.net)
17:51:50		Join ukleinek [0] (~ukl@octopus.hi.pengutronix.de)
17:51:50		Join belak [0] (belak@subtle/user/belak)
17:51:50		Join bylzz [0] (~bylzz@arpnet.org)
17:51:50		Join soap [0] (~soap@rockbox/staff/soap)
17:51:50		Join [fred] [0] (fred@ircop.efnet.at)
17:51:50		Join neferty [0] (~andor@173.242.127.201)
17:51:50		Join guymann [0] (~charles@66-159-144-55.adsl.snet.net)
17:51:50		Join desowin [0] (~desowin@ip-69-162-133-251.static.chi2.systeminplace.net)
17:51:50		Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
17:51:50		Join ruskie [0] (ruskie@sourcemage/mage/ruskie)
17:51:50		Join Torne [0] (~torne@rockbox/developer/Torne)
17:51:50		Join alexbobp [0] (~alex@108.60.198.57)
17:51:50		Join Hadaka [0] (~naked@naked.iki.fi)
17:51:50		Join eintopf [0] (eintopf@zzz.strace.org)
17:51:50		Join jfc [0] (~john@stat-bng-72-73-80-12.ngn.east.myfairpoint.net)
17:51:50		Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful)
17:51:50		Join niekie [0] (~niek@CAcert/Assurer/niekie)
17:51:50		Join knittl [0] (~knittl@unaffiliated/knittl)
17:51:50		Join Espreon [0] (~espreon@wesnoth/developer/espreon)
17:51:50		Join ack` [0] (~ack@mingbai.org)
17:51:50		Join Slasheri [0] (miipekk@rockbox/developer/Slasheri)
17:51:50		Join Vimk [0] (~Vimk@fireslash.net)
17:51:50		Join bzed [0] (~bzed@devel.recluse.de)
17:51:50		Join crwl [0] (~crwlll@dsl-jklbrasgw1-ffb9c300-103.dhcp.inet.fi)
17:51:50		Join avacore [0] (~avacore@1008ds1-rdo.0.fullrate.dk)
17:51:50		Join jae [0] (~jae@dedicated.jaerhard.com)
17:51:50		Join iq_ [0] (~iq@ip24-252-19-172.om.om.cox.net)
17:51:50		Join ThomasAH [0] (~thomas@aktaia.intevation.org)
17:51:50		Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu)
17:51:50		Join CIA-14 [0] (~CIA@cia.atheme.org)
17:51:50		Join Barahir [0] (~jonathan@fb08schindler24.anorg.chemie.uni-giessen.de)
17:51:50		Join ved [0] (ved@ddsbox.co.cc)
17:51:50		Join scorche\|sh [0] (~scorche@rockbox/administrator/scorche)
17:51:50		Join feisar-_ [0] (jljhook@ihq.in)
17:51:50		Join @ChanServ [0] (ChanServ@services.)
17:51:56	fml	No, sorry, not now
17:52:15	AlexP	kugel: You didn't update CustomWPS on the wiki either :)
17:52:38	AlexP	I think best would be just to put it back :)
17:54:38		Join Strife89 [0] (~Strife89@207-144-19-39.cstel.net)
17:57:12		Quit jhMikeS (Ping timeout: 250 seconds)
17:58:28		Join y4n [0] (y4n@unaffiliated/y4ndexx)
17:59:34		Nick Thra11__ is now known as Thra11 (~thrall@87.113.230.201)
18:00
18:00:10	kugel	AlexP: as I said, I didn't think of it
18:00:19	kugel	i.e. I was not aware that I changed the order
18:00:32	kugel	so sure I didn't update CustomWPS
18:00:40		Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
18:19:46		Quit dunkaist (Quit: leaving)
18:23:03		Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net)
18:26:22		Join dunkaist [0] (~dunkaist@82.209.203.4)
18:27:34		Quit ender` (Quit: Saying time travel is impossible is a really safe bet. If it turns out time travel is possible, they can always go back in time and change their statement. But since they haven't changed their statement then that means time travel is impossible.)
18:27:37		Quit parafin (Remote host closed the connection)
18:27:48		Join parafin [0] (parafin@paraf.in)
18:28:07		Quit Keripo (Quit: Leaving.)
18:30:00		Join ender` [0] (~ender@foo.eternallybored.org)
18:30:56		Quit mikroflops (Ping timeout: 276 seconds)
18:32:22		Quit fml (Quit: ChatZilla 0.9.87 [Firefox 5.0/20110615151330])
18:40:06	AlexP	kugel: Oh right, I didn't realise that is what you didn't realise :)
18:52:42		Join Stummi [0] (~Stummi@rockbox/developer/Stummi)
18:58:07		Join saratoga [0] (9803ec71@gateway/web/freenode/ip.152.3.236.113)
18:59:55	saratoga	kugel: about the resampler, I looked through the code only briefly and don't really understand it
19:00
19:00:13	saratoga	but it looks like the current implementation is really weird
19:00:25	saratoga	and i don't understand why it uses so much memory for what is basically a fairly small filter
19:01:26	drezon	what's weird about it? :)
19:02:36	drezon	It's actually pretty straight-forward, if you know how sampling and reconstruction works
19:05:17	drezon	Well, at least I think it is pretty straight-forward. :)
19:05:39	kugel	drezon: did you have a take on exploiting the symmetry? that'd halve memory usage
19:06:14	drezon	No, I was pretty busy with real work. Maybe on the week-end.
19:06:19	kugel	also switch to int16_t :)
19:06:32	drezon	That only works if we drop a bit of precision
19:06:48	drezon	And have sinc(0) at slightly less than 1
19:06:59	kugel	why _and_?
19:07:02	drezon	Because it's signed
19:07:11	kugel	oh right
19:07:14	drezon	I forgot about that−−
19:07:31	kugel	it's not signed if you do the symmetry :)
19:07:42	kugel	no wait, nevermind
19:07:49	drezon	:)
19:08:31	kugel	but yea, 30k sounds like an awful lot for what it does
19:09:12	drezon	As I wrote we can halve that, if we calculate the sinc on-the-fly (i.e. don't have the huge static table anymore)
19:09:31	drezon	I just don't know (yet) how to use fp_sincos for that
19:09:35	kugel	the tables are alternating positive and negative
19:10:00	kugel	pretty sure you can do the signedness differently
19:10:03	drezon	lol.. yea we could exploit that
19:10:33		Join mgue [0] (~mgue@p5DDA3E17.dip.t-dialin.net)
19:10:34	drezon	subtract every second term instead of add
19:10:46	drezon	Yes, should be doable
19:12:08	drezon	So if we go for int16, calculate the sinc and use the symmetry we're at ~4K or so
19:12:25	kugel	that sounds a lot better than 30k :)
19:14:52	kugel	I'm not sure calculating the sinc is a good idea though
19:16:30	drezon	But the exploiting the signedness only works for upsampling as the sinc is streched for downsampling and thus it is not easily clear where the sinc gets negative
19:17:28	saratoga	drezon: i still don't understand why you need such a large trig table with such complicated indexing?
19:18:04	saratoga	using int16 is awkward since armv4 doesn't have a good hardware instruction for multiplying by a 16 bit value
19:18:15	saratoga	it makes sense on armv5+ though
19:18:49	kugel	surely armv4 can use 32bit mul for 16bit if it's faster?
19:18:55	drezon	Can't you just sign-extend to 32bit in the register?
19:19:51	kugel	drezon: streched or not, the sign depends on the index (modulo 2) for the table, no?
19:21:28	drezon	Currently, yes. But if we calculate the sinc the stretched sinc would be calculated to use the whole table (to get rid of sinc_increment) and then it's not that clear anymore
19:22:40	saratoga	kugel: you can, but you have to use shifts and ands
19:22:44	saratoga	so its slower
19:23:03	*	kugel doesn't see that
19:23:14		Join Buschel [0] (~chatzilla@p54A3AE1C.dip.t-dialin.net)
19:23:16	saratoga	armv5 adds a multiplication instruction that references the top or bottom half of a register
19:23:18		Quit sideral (Quit: Leaving.)
19:23:19	drezon	saratoga: how else would you handle resampling? The code get's the sinc values for the 15 samples at real time t (between sample at current and current+1) and adds them. Just as the reconstruction low-pass would create the analog signal at the time t.
19:23:47	kugel	saratoga: it's still 16x16, just that the bits are sign-extended
19:23:50	saratoga	drezon: isn't this resampler just a convolution of sinc with our input data?
19:23:57	kugel	the result is still 32bit so no need for shift
19:24:05	drezon	That "between current and current+1" is the 8 bit fractional part and the second array index
19:24:19	saratoga	kugel: if you store them as an array of 16 bit values each register has two 16 bit ints in it
19:24:38	kugel	huh?
19:25:00	drezon	Kudo-san: probably there are only 32bit loads?
19:25:07	drezon	kugel i meant ;)
19:25:27	kugel	armv4 has half-word loads IIRC
19:25:59	saratoga	kugel: it does, but you want to use load multiple
19:26:13	saratoga	otherwise you will need 2x the loads, and each will also be 2x slower
19:26:44	kugel	you're at asm already aren't you? :)
19:26:54	saratoga	yes :)
19:27:09	saratoga	well predicting how gcc will handle this
19:27:20	kugel	I predict gcc does not do that :)
19:27:24	saratoga	basically if you try this with 16 bit values it will probably get a lot worse even in c
19:28:02	saratoga	although maybe android would be different given all the stuff new arm cpus can do
19:28:09	kugel	one load + shift + and is still faster than 2 loads
19:28:23	drezon	saratoga: it is, but you need the result of that convolution between two sample values. And one (less efficient) way would be to insert as many zeros as needed between samples, then filter. Another way is what I do: calculate the superposition.
19:28:38	kugel	hm, perhaps not with ldm
19:28:54	saratoga	if this is just a convolution, i don't understand why we can't just precompute the taps and store them sequentially in memory?
19:29:20	saratoga	indexing by (fractional!) amounts with fixed point math is going to absolutely kill performance
19:29:27	saratoga	its probably not all that accurate either
19:29:41	saratoga	essentially every load is going to be a cache miss
19:31:51	drezon	Because we go through the sinc by some fractional increment. In the worst case this has a period of 256, so we'd need all 15*256 coeffs anyway (access would be linear, though). Granted this would only be the case for up sampling by 256.
19:32:06	saratoga	but we know the ratio in advance
19:32:18	saratoga	so why compute the index on every single sample rather then just do it once in advance?
19:34:59		Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
19:35:08	drezon	The 8 bit index changes on every sample (it's + increment fractional part % 256). This change is periodic. In the worst case with a period of 256.
19:36:36		Quit Xerion (Read error: Operation timed out)
19:36:56	drezon	If this is about cache miss: I optimized similar code for x86 by using SSE and reversing the sinc index. I left it at [15][256] because it's easier to understand what's being done. But we could easily reverse this. Then the access would be linear per sinc_upsample() call
19:37:01		Quit fs-bluebot (Ping timeout: 255 seconds)
19:37:30	saratoga	yes the index order are backwards, but thats not the biggest issue with doing this efficient
19:37:35	saratoga	drezon: is there some source for the algorithm itself? maybe i just don't understand how this is different then ordinary convolution
19:37:48	drezon	And if we precalc for downsampling. Same would be for downsample
19:38:11		Join fs-bluebot [0] (~fs-bluebo@f053153091.adsl.alicedsl.de)
19:38:20		Quit bluebroth3r (Ping timeout: 246 seconds)
19:39:26	drezon	saratoga: I "invented" this algorithm myself. It's simply what the reconstruction low-pass does. So there is no source that I know of.
19:41:44	drezon	But I'm pretty sure I'm not the first doing this. Actually I would think all oversampling DACs do this in hardware.
19:41:56	saratoga	they do, although they implement it somewhat differently
19:42:05		Join stoffel [0] (~quassel@p57B4A84C.dip.t-dialin.net)
19:42:09	saratoga	usually they first upsample a lot by inserting zeros, and then use a conventional low pass filter
19:42:22	drezon	Really?
19:42:36	saratoga	yeah
19:42:47	drezon	I would do it my way. :)
19:42:53	saratoga	i guess the difference that i'm missing here is that you're doing the lowpass and interpolation step at once
19:42:53		Quit dunkaist (Quit: leaving)
19:43:00	drezon	Exactly
19:43:14	saratoga	so you need to oversample your kernel since you'll be hitting different point on it with each sample
19:43:22	drezon	Yes!
19:44:02	saratoga	so basically it is convolution, but not over the input samples exactly, but over the zero padded version of them
19:46:11	saratoga	heh and the least common multiple in the 48 to 44.1k case is 147 times the base rate
19:46:50	saratoga	alright well now i understand why everyone uses polynomials instead of sinc resampling for embedded devices :)
19:46:54	drezon	So I serached a bit and found this: https://ccrma.stanford.edu/~jos/resample/
19:46:58		Quit Bagder (Ping timeout: 276 seconds)
19:47:11	drezon	I think they do something similar to what I implemented
19:47:45	drezon	Only quickly glanced through it, though
19:48:49	saratoga	yeah i understand now
19:49:08	saratoga	i was missing that the huge LCM between the sampling rates means you need to very finely sample the convolution kernel
19:51:41	kugel	\o/ dircache runtime switchable
19:51:46	***	Saving seen data "./dancer.seen"
19:53:11	drezon	saratoga: maybe it would have been easier if I provided my x86 source as that one has an init() function which calculates the sinc. So it's easier to see that we sample it between zero crossings.
19:59:39		Quit jae (Read error: Operation timed out)
20:00
20:00:39		Join jae [0] (~jae@dedicated.jaerhard.com)
20:30:10		Join mikroflops [0] (~yogurt@h-34-156.a238.priv.bahnhof.se)
20:49:15		Quit kadoban (Ping timeout: 260 seconds)
20:49:28		Quit drezon (Ping timeout: 255 seconds)
21:00
21:06:46		Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk)
21:16:54		Join Thra11_ [0] (~thrall@84.93.149.190)
21:17:22		Quit Thra11 (Read error: Operation timed out)
21:17:35		Nick Thra11_ is now known as Thra11 (~thrall@84.93.149.190)
21:25:48		Quit stoffel (Ping timeout: 252 seconds)
21:28:04		Join simonlnu_ [0] (7ziUFtAAq4@unaffiliated/simonrvn)
21:31:04		Quit simonlnu (Ping timeout: 258 seconds)
21:31:12		Nick simonlnu_ is now known as simonlnu (7ziUFtAAq4@unaffiliated/simonrvn)
21:31:46		Join Farivan [0] (~chatzilla@12.20.4.100)
21:38:31		Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel)
21:42:45		Quit stripwax (Ping timeout: 240 seconds)
21:46:17	saratoga	did anyone try my new virtualbox image? curious if its working for other people
21:48:59		Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk)
21:49:35	amiconn	AlexP, kugelp: Changing the order back for swcodec will make themes incompatible between hwcodec and swcodec
21:50:34		Part Farivan
21:51:49	***	Saving seen data "./dancer.seen"
21:53:08	AlexP	bloody hwcodec
21:53:22	AlexP	at the least it should be mp3, mp2, mp1 then
21:53:39	AlexP	It is just a shame it will make people's themes wrong
21:54:18	amiconn	Maybe mp3 mp2 mp1 makes more sense
21:54:43	amiconn	One day themes will be incompatible between hwcodec and swcodec anyway (if we don't break order again)
21:55:07	gevaerts	We've had changes that made themes not work at all without doing much to help. I don't really see the problem with changing something that I suspect most people won't even look at and documenting that change
21:55:28	AlexP	gevaerts: It isn't a massive issue, I was just trying to avoid it
21:55:39	AlexP	But if it can't be avoided, then so be it
21:56:09	gevaerts	AlexP: maybe we can get JdGordon to make a breaking change at the same time? :)
21:56:21	AlexP	heh, has he got one coming up by any chance? :)
21:56:27	gevaerts	No idea
21:58:37		Quit Stummi (Quit: Bye!)
22:00
22:13:24		Quit liar (Read error: Connection reset by peer)
22:16:25	kugelp	amiconn: really?
22:16:44		Quit Thra11 (Ping timeout: 252 seconds)
22:16:45		Join mercutio22 [0] (~mercutio2@cpe-68-173-63-113.nyc.res.rr.com)
22:17:08	kugelp	could make mp2 start at 2 for hwcodec?
22:17:11	mercutio22	Hi. Can someone recommend me a device to use with rockbox? I am off to buy one right now
22:19:33	mercutio22	I heard good shit about the iriver devices
22:20:53		Join sideral [0] (~sideral@rockbox/developer/sideral)
22:21:45		Join JesusFreak316 [0] (~JesusFrea@pool-173-65-77-157.tampfl.fios.verizon.net)
22:21:47	gevaerts	mercutio22: you'll have to be a bit more specific about what you care about
22:24:15		Join dunkaist [0] (~dunkaist@bp-183-23.dialup.vitebsk.by)
22:25:52		Quit y4n (Quit: The world around me drops away, replaced by worlds being created and destroyed by my imagination.)
22:30:32		Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se)
22:30:33		Quit Bagder (Changing host)
22:30:33		Join Bagder [241] (~daniel@rockbox/developer/bagder)
22:31:15		Join Thra11 [0] (~thrall@80.229.120.221)
22:39:56		Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net)
22:45:00	mercutio22	gevaerts: I just want a long battery life and plenty of space. I don't care about video.
22:46:46	mercutio22	it seems like the sansa fuze is the only compatible one still in production
22:46:53	mercutio22	http://www.rockbox.org/wiki/BuyersGuide
22:47:32	gevaerts	Maybe the clip too, but I'm not sure
22:47:58	AlexP	what does plenty of space mean to you?
22:48:05	AlexP	ditto long battery
22:48:16	gevaerts	Make sure you don't get a fuze+ though, unless you want to work on the port instead of actually using it
22:49:08	mercutio22	battery life should last around 12 hours and space should be ~ 30-40 gb
22:49:29	AlexP	OK, so clip+ or fuze with a big µSD would do
22:49:38	AlexP	Maybe
22:49:45		Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu)
22:49:45	AlexP	Can you get 32 GB µSD yet?
22:50:20	AlexP	For that space you might need to look at HDD players
22:50:21	mercutio22	actually... its ok to have less and latter upgrade microSD cards
22:50:48	mercutio22	or whatever kind of memory card
22:51:16	mercutio22	so looks like its narrowed to the sansa fuze v2
22:51:32	mercutio22	where could I find it?
22:51:35	AlexP	or clip+
22:51:39	AlexP	I don't know
22:51:46	AlexP	I don't even know what country you are in
22:53:11	mercutio22	I am in NYC right now. I am looking at bestbuy right now. Let me know if anyone has any clues
22:53:18	AlexP	USA then?
22:53:25	AlexP	In which case I have no idea
22:53:45	saratoga	the fuze isn't in production FYI
22:54:03		Quit stripwax (Read error: Connection reset by peer)
22:54:25		Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com)
22:54:59	mercutio22	oh shit
22:55:18	mercutio22	={
22:56:12	mercutio22	I guess I can't get anything that runs rockbox that isn't apple then
22:57:14	saratoga	ok
22:57:26	gevaerts	"not in production" doesn't have to mean "not available"
22:58:25	mercutio22	yea, but I am in NYC for just a couple of days... I can't order, bell is broken and outta home all day ={
23:00
23:00:33	AlexP	clip+ is I think
23:01:44	mercutio22	lets see if I can find the clip+
23:02:57	mercutio22	Thanks! I see in their website they might have it!
23:03:05	mercutio22	I will go have a look
23:04:22		Join B4gder [241] (~daniel@rockbox/developer/bagder)
23:04:52		Quit Bagder (Ping timeout: 264 seconds)
23:08:19		Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk)
23:09:33		Quit mercutio22 (Ping timeout: 276 seconds)
23:11:03		Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com)
23:16:07		Quit Horscht (Ping timeout: 250 seconds)
23:17:23		Quit benedikt93 (Quit: Bye ;))
23:26:26		Join drezon [0] (~skeller@dslb-088-073-110-032.pools.arcor-ip.net)
23:36:31	CIA-14	New commit by buschel (r30283): 6th part of FS #12176. Reduce memory consumption of libgme emulators to allow enabling of NSF and SGC codecs for low memory targets. The main lookup ...
23:38:58	CIA-14	r30283 build result: All green
23:42:36		Join mshathlonxp [0] (~amdk7powe@5ad4ef88.bb.sky.com)
23:51:52	***	Saving seen data "./dancer.seen"
23:53:12		Quit stripwax (Quit: http://miranda-im.org)
23:54:52		Quit dunkaist (Quit: leaving)

Previous day | Next day