[gst-devel] Daily IRC logs

[wim.taymans at chello.be]

[06:32] ajmitch (ajmitch at p58-max6.dun.ihug.co.nz) left irc: Ping timeout for ajmitch[p58-max6.dun.ihug.co.nz]
[06:34] ajmitch (ajmitch at p24-max7.dun.ihug.co.nz) joined #gstreamer.
[06:46] ajmitch (ajmitch at p24-max7.dun.ihug.co.nz) left irc: Ping timeout for ajmitch[p24-max7.dun.ihug.co.nz]
[06:48] ajmitch (ajmitch at p24-max7.dun.ihug.co.nz) joined #gstreamer.
[07:06] arik|sick (arik at adsl-64-174-42-2.dsl.snfc21.pacbell.net) left irc: Ping timeout for arik|sick[adsl-64-174-42-2.dsl.snfc21.pacbell.net]
[07:18] ajmitch (ajmitch at p24-max7.dun.ihug.co.nz) left irc: Ping timeout for ajmitch[p24-max7.dun.ihug.co.nz]
[07:43] ajmitch (ajmitch at p27-max3.dun.ihug.co.nz) joined #gstreamer.
[07:45] steveb (steveb at node1ee04.a2000.nl) joined #gstreamer.
[07:45] Action: steveb yawns
[07:46] <ajmitch> hi
[07:46] <steveb> hi
[07:47] <steveb> ajmitch: how is Dunners?
[07:48] <ajmitch> same old same old, should be a good weekend tho (graduation & highlanders vs crusaders game @ carisbrook)
[07:48] <steveb> oh yeah, that is going to be busy
[07:48] <ajmitch> yup ;)
[07:48] <ajmitch> was super 12 started when you left?
[07:49] <steveb> yeah
[07:49] <steveb> although my loyalties were split between highlanders and hurricanes
[07:50] <ajmitch> for me, it's highlanders all the way ;)
[07:50] <steveb> not that I can muster much enthusiasm for rugby
[07:51] <ajmitch> yeah
[07:51] <ajmitch> so how long you been o'seas?
[07:51] <steveb> but you can't talk linux with 99.9% of kiwi blokes so you've gotta talk about something :)
[07:51] <ajmitch> hehe, dunedin LUG has been setup tho ;)
[07:52] <steveb> only 6 months
[07:52] <ajmitch> ah, ok
[07:52] <ajmitch> dunlug only been going 3 months
[07:53] <steveb> we tried to get a perl mongers going in wellington and it worked for a while
[07:54] <ajmitch> so what are you doing in the netherlands?
[07:55] <steveb> working as a developer at a broadband ISP
[07:55] <ajmitch> nice
[07:56] <steveb> i wouldn't go that far :}
[08:00] <steveb> speaking of work, i'd better go
[08:00] <ajmitch> ok
[08:00] <ajmitch> see ya
[08:00] <steveb> erik|sick: if you can raise yourself from your sick bed, can you take a look at my dparams wiki?
[08:07] Nick change: ajmitch -> ajbusy
[08:07] <erik|sick> um, I'll try to focus my eyes, yeah ;-)
[08:08] Action: taaz reads the dynparam page
[08:11] <steveb> cool, thanks
[08:11] Action: steveb goes to work
[08:11] steveb (steveb at node1ee04.a2000.nl) left irc: [x]chat
[09:06] ajbusy (ajmitch at p27-max3.dun.ihug.co.nz) left irc: Ping timeout for ajbusy[p27-max3.dun.ihug.co.nz]
[09:11] Nick change: taaz -> taazzzz
[09:13] steveb (stevebaker at 212186169160.chello.com) joined #gstreamer.
[09:13] <erik|sick> I've made some comments, but some got lost when NS crashed
[09:13] <erik|sick> I'll try to remember what I said and do it again
[09:15] <steveb> heh, ok cool
[09:23] <steveb> is it just me or do threads on LAD go in perpetual circles
[09:25] <erik|sick> no, it's not just you
[09:32] <erik|sick> round and round and round they go
[09:33] <erik|sick> where they'll stop ya never know
[09:37] laureck (blourk at chronos.cpe.fr) joined #gstreamer.
[09:37] <laureck> hello
[09:38] <erik|sick> yo
[09:39] <laureck> hello erik|sick
[09:40] Action: erik|sick is actually omega
[09:40] <laureck> so hello omega
[09:40] <laureck> do you know gtk/gdk programming?
[09:40] <erik|sick> some
[09:41] <laureck> cool :)
[09:41] <erik|sick> mostly gtk, basically no gdk
[09:41] <laureck> maybe you'll agree to answer a question...
[09:41] <erik|sick> I'll try, if I don't fall asleep first ;-(
[09:41] <laureck> I'm looking for a way to 'present' a window i.e to give focus to a window and I didn't find the gtk or gdk call in the docs
[09:42] <erik|sick> hmmm
[09:42] <laureck> I'm talking about X11 window here.
[09:42] <erik|sick> i.e. force window manager focus to switch to a given window?
[09:42] <erik|sick> hrm, ok
[09:42] <erik|sick> that's a gtk-level concept then
[09:42] <laureck> yeah, that
[09:42] <erik|sick> oh
[09:42] <erik|sick> then it's a window-manager thing
[09:43] <erik|sick> need to talk to the window manager, and beg it to change focus
[09:43] <erik|sick> (literally)
[09:43] <laureck> I know that gtk 2.0 has the gtk_window_present() call, but gtk+ 1.2 doesn't have it
[09:43] <laureck> I see...
[09:44] <laureck> Thank for your help :)
[09:44] <erik|sick> I guess I'd suggest looking at the code or gtk_window_present() and see if you can backport it
[09:44] <erik|sick> shouldn't be too hard (I hope <g>)
[09:44] <laureck> good idea.
[09:44] <laureck> hehe
[09:44] <laureck> good knight
[09:45] <erik|sick> 'night
[09:45] <laureck> :)
[09:45] laureck (blourk at chronos.cpe.fr) left #gstreamer.
[09:50] <steveb> erik: so how are you getting on with ladspa plugin?
[09:51] <erik|sick> I've made some changes, I'll get it closer to working tomorrow maybe
[09:55] <steveb> erik: "An entirely different method, and much more efficient, " did you write that?
[09:55] <erik|sick> afaik
[09:55] <erik|sick> is it signed?
[09:55] <erik|sick> grr, that's where NS crashed
[09:55] <steveb> ne
[09:55] <steveb> heh
[10:00] <erik|sick> ok, added stuff to the control rate section
[10:04] <steveb> i have a couple of comments on your chain function...
[10:04] <erik|sick> ok
[10:07] <steveb> I really think the common case in the for loop will be "no parameters have changed" so there will be a ctrldata array full of mostly the same values
[10:07] <erik|sick> yes
[10:12] taazzzz (dlehn at 66.37.66.32) got netsplit.
[10:12] matth_ (matth at qwest.dsplinux.net) got netsplit.
[10:12] maYam (mayam at cable-195-162-214-58.upc.chello.be) got netsplit.
[10:12] steveb (stevebaker at 212186169160.chello.com) got netsplit.
[10:12] wtay-zZz (wim at cable-195-162-214-58.upc.chello.be) got netsplit.
[10:12] vini (vincent at bones.kulnet.kuleuven.ac.be) got netsplit.
[10:12] erik|sick (omega at omegacs.net) got netsplit.
[10:13] taazzzz (dlehn at 66.37.66.32) returned to #gstreamer.
[10:13] maYam (mayam at cable-195-162-214-58.upc.chello.be) returned to #gstreamer.
[10:13] wtay-zZz (wim at cable-195-162-214-58.upc.chello.be) returned to #gstreamer.
[10:13] vini (vincent at bones.kulnet.kuleuven.ac.be) returned to #gstreamer.
[10:13] matth_ (matth at qwest.dsplinux.net) returned to #gstreamer.
[10:13] erik|sick (omega at omegacs.net) returned to #gstreamer.
[10:13] steveb (stevebaker at 212186169160.chello.com) returned to #gstreamer.
[10:14] <erik|sick> steveb: btw: gstreamer.net/images/dsc0009.jpg
[10:15] <steveb> what about the case where you have a whole bunch of dparams where some change and some don't - surely that leads to some messy conditionals in the chain func when deciding whether to use a single value or an array for each dparam
[10:15] <erik|sick> er, dscn
[10:15] <erik|sick> yes
[10:15] Nick change: maYam -> maYam_busy
[10:15] <erik|sick> but how is calling a function to get every control sample fast?
[10:16] <steveb> tee hee
[10:16] <steveb> ok, i'll state a number of cases...
[10:18] <steveb> case: multiple dparams, but none are updated during the buffer. The first call to gst_dparam_group_update_params sets all params then sets do_more to buffer_size.  The second call to gst_dparam_group_update_params sets do_more to 0 and the loop quits
[10:19] <erik|sick> ok, but if the value changes for every single sample, then you've got horrible performance
[10:20] <erik|sick> as is the case for any higher-order (1st or better) interpolation
[10:20] <erik|sick> then the array is by far the fastest
[10:22] <steveb> I think sample_rate==control_rate is a special case which should be treated differently - if an element wants to support that it should have an alternative chain func which more closely resembles your approach
[10:23] <erik|sick> so how does cubic interp jive with samplerate != control_rate?
[10:23] <steveb> but i think by far the common case which should be optimised for is sparse parameter updating with multiple non-constant control rates
[10:24] <erik|sick> hmmm, ok
[10:24] <erik|sick> the problem is then supporting both gets messy
[10:24] <erik|sick> are there any other systems that do this well?
[10:25] <steveb> cubic is the same as linear, the value is only interpolated at the control rate (or however you decide to update the value)
[10:25] <erik|sick> hmmm
[10:26] <steveb> the vast majority of systems seem to have constant control rate which is attached to buffer size
[10:26] <steveb> which i don't like at all - hence my proposal
[10:27] <erik|sick> right
[10:27] <steveb> <erik|sick> the problem is then supporting both gets messy
[10:27] <erik|sick> I've heard that VST2 has something kinda like sample-accuracy
[10:28] <steveb> ^^^ another option is to get each element to implement its own gst_dparam_group_update_params function.  Then it can be inlined and whatever perverse optimisation can be performed.
[10:29] <erik|sick> hmm
[10:29] <erik|sick> only if the compiler aids in specialization does it really help
[10:29] <erik|sick> without that support, we have to large-scale specialization, i.e. switching between different chain functions
[10:30] <steveb> do you have VST SDK?
[10:30] <erik|sick> I'm scanning the pdf now
[10:31] <steveb> i applied for the sdk yesterday but am yet to receive a response
[10:32] <erik|sick> hmm
[10:32] <erik|sick> I can email it to you
[10:32] <steveb> that would be cool
[10:32] <erik|sick> addr?
[10:33] <steveb> sbaker at chello.com
[10:33] <erik|sick> sent
[10:33] <steveb> remember when saying "sample-accuracy" there is an important distinction between a value changing every sample and a value which can be updated at a non-constant rate
[10:34] <steveb> ...and the latter is more useful and important IMO
[10:34] <erik|sick> right
[10:36] <steveb> whereas the former is probably another audio signal which should be treated accordingly
[10:36] <erik|sick> hmm
[10:37] <steveb> well, maybe thats an overstatement
[10:42] matth_ (matth at qwest.dsplinux.net) got netsplit.
[10:42] maYam_busy (mayam at cable-195-162-214-58.upc.chello.be) got netsplit.
[10:42] steveb (stevebaker at 212186169160.chello.com) got netsplit.
[10:42] wtay-zZz (wim at cable-195-162-214-58.upc.chello.be) got netsplit.
[10:42] vini (vincent at bones.kulnet.kuleuven.ac.be) got netsplit.
[10:42] erik|sick (omega at omegacs.net) got netsplit.
[10:42] taazzzz (dlehn at 66.37.66.32) got netsplit.
[10:48] taazzzz (dlehn at 66.37.66.32) returned to #gstreamer.
[10:48] maYam_busy (mayam at cable-195-162-214-58.upc.chello.be) returned to #gstreamer.
[10:48] wtay-zZz (wim at cable-195-162-214-58.upc.chello.be) returned to #gstreamer.
[10:48] vini (vincent at bones.kulnet.kuleuven.ac.be) returned to #gstreamer.
[10:48] matth_ (matth at qwest.dsplinux.net) returned to #gstreamer.
[10:48] erik|sick (omega at omegacs.net) returned to #gstreamer.
[10:48] steveb (stevebaker at 212186169160.chello.com) returned to #gstreamer.
[10:49] <steveb> gst_dparam_group_setup could be called before the buffer is processed, it creates an array of tuples (sample offset, param, value).  Then gst_dparam_group_update_params becomes a trivial case of updating the next param and returning the next sample offset
[10:49] <erik|sick> yup
[10:54] taazzzz (dlehn at 66.37.66.32) got netsplit.
[10:54] matth_ (matth at qwest.dsplinux.net) got netsplit.
[10:54] maYam_busy (mayam at cable-195-162-214-58.upc.chello.be) got netsplit.
[10:54] steveb (stevebaker at 212186169160.chello.com) got netsplit.
[10:54] wtay-zZz (wim at cable-195-162-214-58.upc.chello.be) got netsplit.
[10:54] vini (vincent at bones.kulnet.kuleuven.ac.be) got netsplit.
[10:54] erik|sick (omega at omegacs.net) got netsplit.
[10:55] taazzzz (dlehn at 66.37.66.32) returned to #gstreamer.
[10:55] maYam_busy (mayam at cable-195-162-214-58.upc.chello.be) returned to #gstreamer.
[10:55] wtay-zZz (wim at cable-195-162-214-58.upc.chello.be) returned to #gstreamer.
[10:55] vini (vincent at bones.kulnet.kuleuven.ac.be) returned to #gstreamer.
[10:55] matth_ (matth at qwest.dsplinux.net) returned to #gstreamer.
[10:55] erik|sick (omega at omegacs.net) returned to #gstreamer.
[10:55] steveb (stevebaker at 212186169160.chello.com) returned to #gstreamer.
[11:02] Action: erik|sick must sleep now
[11:03] erik|sick (omega at omegacs.net) left irc: [x]chat
[11:08] steveb (stevebaker at 212186169160.chello.com) left irc: quit has steveb, yes
[12:22] ajbusy (ajmitch at p27-max3.dun.ihug.co.nz) joined #gstreamer.
[12:23] Nick change: ajbusy -> ajmitch
[12:23] <ajmitch> hi
[12:23] <maYam_busy> hey ajmitch
[12:24] <ajmitch> time for me to sit down & finish off a website that i should have done 3 weeks ago ;)
[12:24] <ajmitch> then onto learning how to hack gstreamer plugins to bits...
[12:24] <maYam_busy> hehe.. you're doing exactly the same as i'm doing now
[12:24] <ajmitch> hehe
[12:25] <maYam_busy> one done, one more to go
[12:25] <ajmitch> i got 2 sites 1/2 done... ;)
[12:25] <maYam_busy> ;)
[12:26] <maYam_busy> and in the meantime i should be working on my own site as well
[12:26] <maYam_busy> it's totally neglected
[12:27] <ajmitch> you do this for a living?
[12:27] <maYam_busy> yes.. or at least i try ;)
[12:27] <ajmitch> hehe
[12:27] <ajmitch> my site has a note about finally being updated (dated 27th may 2000)...
[12:28] <maYam_busy> hoho.. that's bad!
[12:28] <ajmitch> ;)
[12:28] <maYam_busy> what's your site about?
[12:29] <maYam_busy> you don't remember?
[12:29] <maYam_busy> ;)
[12:30] <ajmitch> umm...
[12:31] <ajmitch> i never really put much on it, just stuff about what projects i was working on.. ;)
[12:32] <maYam_busy> 'was'.. yes.. :)
[12:33] <ajmitch> exactly :)
[12:34] vini (vincent at bones.kulnet.kuleuven.ac.be) left irc: Ping timeout for vini[bones.kulnet.kuleuven.ac.be]
[13:55] Nick change: ajmitch -> ajzzzz
[14:33] vini (vincent at bones.kulnet.kuleuven.ac.be) joined #gstreamer.
[15:33] thomas (thomas at 212-100-172-175.adsl.easynet.be) joined #gstreamer.
[15:35] dobey (dobey at 141.154.95.104) joined #gstreamer.
[16:07] Nick change: matth_ -> matth-waking
[18:35] thomas (thomas at 212-100-172-175.adsl.easynet.be) left irc: [x]chat
[18:41] Nick change: wtay-zZz -> wtay
[18:41] <wtay> yo
[18:41] <wtay> brb
[18:42] CHW|away (paul at temple-baptist.com) joined #gstreamer.
[18:50] <wtay> hi CHW|away
[18:50] <dobey> any of you use jabber?
[18:50] <CHW|away> ello, nope
[18:51] Nick change: CHW|away -> ChiefHighwater
[18:51] <ChiefHighwater> of course, I can't speak for everyone
[18:51] <wtay> what's jabber?
[18:51] <dobey> open im
[18:51] <wtay> what's im?
[18:52] <ChiefHighwater> instant messaging
[18:52] <dobey> instant messaging
[18:52] <wtay> what's that?
[18:52] Action: dobey smacks wtay
[18:52] <wtay> send messages?
[18:53] <ChiefHighwater> wtay: you've heard of ICQ or AIM or MSN?
[18:54] <wtay> never used it..
[18:54] <ChiefHighwater> kinda like a cross between irc and email
[18:54] <wtay> ok
[18:56] <ChiefHighwater> I'm in one right now with my mom  8-]
[18:56] <wtay> hehe, your mom :)
[18:57] <ChiefHighwater> yup
[18:57] <wtay> cool, bring her into IRC :-)
[18:57] <ChiefHighwater> hehe
[18:58] <ChiefHighwater> she uses Microsoft's instant messanger, sorry.  She doesn't know a thing about irc
[19:14] <vini> jabber is cool !
[19:14] <vini> you can talk to anyone then (wel maybe no more AOL people, unless you build a Freenet node and stuff)
[19:15] <dobey> uh
[19:15] <dobey> jabber.org has an aim transport, iirc
[19:15] <dobey> jabber rules
[19:21] Nick change: taazzzz -> taaz
[19:24] <taaz> grrr... what are the downsides to merging incsched into head now?  it's confusing having two trees... can't do development in one without porting patches to the other tree too..
[19:25] <wtay> taaz: just work in one branch, they are going to be merged anyway
[19:27] <taaz> which one?
[19:37] Nick change: taaz -> taaz-lunch
[20:07] thomas (thomas at adsl-63930.turboline.skynet.be) joined #gstreamer.
[20:07] <thomas> hi
[20:07] <wtay> yo
[20:07] <thomas> how's incsched progressing ? :)
[20:07] <wtay> dunno, ask omega :)
[20:08] <thomas> wtay: what Windowmanager are you using ?
[20:08] <wtay> sawmill
[20:08] <thomas> could you test a little program I wrote for me...
[20:08] <thomas> ... to see if it works ?
[20:08] <wtay> hmm, I guess..
[20:08] <thomas> only if you have the time
[20:09] <wtay> sure
[20:09] <thomas> it's simple, it just displays messages on the top of your X screen
[20:09] <wtay> ok, you can send it
[20:10] <thomas> ok, sent
[20:13] <wtay> thomas: going to play a trick on somebody :)
[20:13] <thomas> ;)
[20:13] <thomas> no, it's part of my gbox project
[20:13] <thomas> first thing it needs is a way to tell you stuff without interrupting what you're doing
[20:14] <thomas> I tailed my /var/log/messages with it today and it's really handy
[20:14] <thomas> though it still needs some work
[20:14] <thomas> so it works ?
[20:15] <wtay> yup
[20:15] <wtay> although it obscures the windows in some way
[20:15] <thomas> how so ?
[20:15] <thomas> You can't access the window underneath...
[20:15] <thomas> ... but the visual should be ok
[20:15] <thomas> as long as you don't move it
[20:15] <wtay> yeah
[20:15] <thomas> it's not fully transparent yet
[20:15] <wtay> ok
[20:15] <thomas> I'm learning ;)
[20:15] <wtay> not a shaped pixmap or something..
[20:16] <thomas> I'm going to add icons in front (to identify sub-systems) and some more colorization
[20:16] <wtay> funny things happen when you move the window underneat it
[20:16] <thomas> and if it's possible, the fade effect from windowmaker
[20:16] <thomas> wtay: yeah, it creates a copy at the moment it displays and keeps that copy around
[20:16] <thomas> I'll fix that
[20:16] <wtay> ok
[20:16] <wtay> neat
[20:17] <thomas> the only thing I don't have a clue about right now is how to draw fonts and then scale the image
[20:17] <thomas> though I suppose I just need a library like Imlib for stuff like that
[20:17] <wtay> possibly...
[20:38] hadess (hadess at pc2-guil2-0-cust121.gui.cable.ntl.com) joined #gstreamer.
[20:39] <wtay> hi
[20:39] <hadess> hi boys
[20:40] <hadess> should i send a mail to plee for the v4lsrc to be fixed in 0.2 ?
[20:40] <dobey> heh
[20:40] <wtay> hadess: I need help with that...
[20:41] <hadess> omega is supposed to have received the same webcam i have...
[20:42] <wtay> good
[20:44] <hadess> the version from a couple of days back is stopping on "v4l: capture probe rgb24..."
[20:45] <wtay> hadess: I need someone to look at capsnego first..
[20:45] <hadess> oh, ok
[20:45] <hadess> i reckon omega should look at it when he's better
[20:46] <wtay> and metth too, he said..
[20:46] <wtay> s/metth/matth
[20:46] <hadess> cool
[20:47] <hadess> i hope i can fixor vanity for release  with 0.2
[20:51] Nick change: ChiefHighwater -> CHW-lunch
[20:53] steveb (steveb at node1ee04.a2000.nl) joined #gstreamer.
[20:56] Nick change: ajzzzz -> ajmitch
[21:03] <hadess> btw, mp3mad is broken on ppc as well :/
[21:08] Nick change: ajmitch -> ajfood
[21:20] hadess (hadess at pc2-guil2-0-cust121.gui.cable.ntl.com) left irc: mooooh!
[21:22] omega_ (omega at omegacs.net) joined #gstreamer.
[21:22] <wtay> hi
[21:22] <omega_> yo
[21:28] <steveb> hi
[21:29] Nick change: omega_ -> omega_breakfast
[21:29] Nick change: taaz-lunch -> taaz
[21:33] Nick change: ajfood -> ajmitch
[21:43] <omega_breakfast> so, examples/autoplug works, does gstplay?
[21:44] <ajmitch> must test...
[21:44] <ajmitch> ;)
[21:44] <dobey> hey omega/ajmitch
[21:44] <ajmitch> hey dobey
[21:44] <dobey> either of you use jabber?
[21:44] <ajmitch> nope
[21:45] <wtay> omega_breakfast: testing
[21:45] <ajmitch> i guess i should recompile before testing? ;)
[21:46] <dobey> heh
[21:46] <ajmitch> i'll get back to you in a couple of hours then....
[21:47] <omega_breakfast> hmm, it works sorta
[21:47] <omega_breakfast> on mpeg1 video only I get lots of can't switch's
[21:47] <omega_breakfast> mpeg2 system I get two can't switch's and no A/V
[21:47] <omega_breakfast> mpeg2 video works fine
[21:48] <omega_breakfast> vorbis segfaults
[21:48] <omega_breakfast> mp3 plays fine
[21:48] taaz (dlehn at 66.37.66.32) got netsplit.
[21:52] matth-waking (matth at qwest.dsplinux.net) got netsplit.
[21:52] thomas (thomas at adsl-63930.turboline.skynet.be) got netsplit.
[21:52] maYam_busy (mayam at cable-195-162-214-58.upc.chello.be) got netsplit.
[21:52] dobey (dobey at 141.154.95.104) got netsplit.
[21:52] wtay (wim at cable-195-162-214-58.upc.chello.be) got netsplit.
[21:52] steveb (steveb at node1ee04.a2000.nl) got netsplit.
[21:52] vini (vincent at bones.kulnet.kuleuven.ac.be) got netsplit.
[21:52] omega_breakfast (omega at omegacs.net) got netsplit.
[21:57] maYam_busy (mayam at cable-195-162-214-58.upc.chello.be) returned to #gstreamer.
[21:57] wtay (wim at cable-195-162-214-58.upc.chello.be) returned to #gstreamer.
[21:57] matth-waking (matth at qwest.dsplinux.net) returned to #gstreamer.
[21:57] vini (vincent at bones.kulnet.kuleuven.ac.be) returned to #gstreamer.
[21:57] dobey (dobey at 141.154.95.104) returned to #gstreamer.
[21:57] thomas (thomas at adsl-63930.turboline.skynet.be) returned to #gstreamer.
[21:57] steveb (steveb at node1ee04.a2000.nl) returned to #gstreamer.
[21:57] omega_breakfast (omega at omegacs.net) returned to #gstreamer.
[21:57] taaz (dlehn at 66.37.66.32) returned to #gstreamer.
[21:57] <omega_breakfast> apparently it's some kind of enviro in which, as Kai says, 'apps are plugins'
[21:57] taaz (dlehn at 66.37.66.32) got netsplit.
[21:57] matth-waking (matth at qwest.dsplinux.net) got netsplit.
[21:57] thomas (thomas at adsl-63930.turboline.skynet.be) got netsplit.
[21:57] maYam_busy (mayam at cable-195-162-214-58.upc.chello.be) got netsplit.
[21:57] dobey (dobey at 141.154.95.104) got netsplit.
[21:57] wtay (wim at cable-195-162-214-58.upc.chello.be) got netsplit.
[21:57] steveb (steveb at node1ee04.a2000.nl) got netsplit.
[21:57] vini (vincent at bones.kulnet.kuleuven.ac.be) got netsplit.
[21:57] omega_breakfast (omega at omegacs.net) got netsplit.
[21:58] maYam_busy (mayam at cable-195-162-214-58.upc.chello.be) returned to #gstreamer.
[21:59] wtay (wim at cable-195-162-214-58.upc.chello.be) returned to #gstreamer.
[21:59] matth-waking (matth at qwest.dsplinux.net) returned to #gstreamer.
[21:59] vini (vincent at bones.kulnet.kuleuven.ac.be) returned to #gstreamer.
[21:59] dobey (dobey at 141.154.95.104) returned to #gstreamer.
[21:59] thomas (thomas at adsl-63930.turboline.skynet.be) returned to #gstreamer.
[21:59] steveb (steveb at node1ee04.a2000.nl) returned to #gstreamer.
[21:59] omega_breakfast (omega at omegacs.net) returned to #gstreamer.
[21:59] taaz (dlehn at 66.37.66.32) returned to #gstreamer.
[21:59] taaz (dlehn at 66.37.66.32) left irc: Reconnecting
[21:59] taaz_ (dlehn at 66.37.66.32) joined #gstreamer.
[21:59] Nick change: taaz_ -> taaz
[21:59] <omega_breakfast> what's amusing to me is the implicit assumption of 'busses' and all their restrictions
[22:00] Action: wtay is trying to do webbanking with the new 100mil$ system...
[22:00] <omega_breakfast> is it working?
[22:00] <wtay> nope
[22:00] <omega_breakfast> if it fails do you get the 100mil$?
[22:01] <wtay> nope :(
[22:01] matth-waking (matth at qwest.dsplinux.net) got netsplit.
[22:01] thomas (thomas at adsl-63930.turboline.skynet.be) got netsplit.
[22:01] maYam_busy (mayam at cable-195-162-214-58.upc.chello.be) got netsplit.
[22:01] dobey (dobey at 141.154.95.104) got netsplit.
[22:01] wtay (wim at cable-195-162-214-58.upc.chello.be) got netsplit.
[22:01] steveb (steveb at node1ee04.a2000.nl) got netsplit.
[22:01] vini (vincent at bones.kulnet.kuleuven.ac.be) got netsplit.
[22:01] omega_breakfast (omega at omegacs.net) got netsplit.
[22:01] Topic changed on #gstreamer by ChanServ!s at ChanServ: GStreamer: the ultimate multimedia framework
[22:02] maYam_busy (mayam at cable-195-162-214-58.upc.chello.be) returned to #gstreamer.
[22:02] wtay (wim at cable-195-162-214-58.upc.chello.be) returned to #gstreamer.
[22:02] matth-waking (matth at qwest.dsplinux.net) returned to #gstreamer.
[22:02] vini (vincent at bones.kulnet.kuleuven.ac.be) returned to #gstreamer.
[22:02] dobey (dobey at 141.154.95.104) returned to #gstreamer.
[22:02] thomas (thomas at adsl-63930.turboline.skynet.be) returned to #gstreamer.
[22:02] steveb (steveb at node1ee04.a2000.nl) returned to #gstreamer.
[22:02] omega_breakfast (omega at omegacs.net) returned to #gstreamer.
[22:02] <wtay> omega_breakfast: apparently
[22:02] <omega_breakfast> 'doze?
[22:02] <wtay> omega_breakfast: I've been complaining to them for about a month now...
[22:03] <wtay> nope, 50 suns with lot's of CPU/RAM etc...
[22:03] <omega_breakfast> 50???
[22:03] <wtay> omega_breakfast: the app I wrote really flies...
[22:03] <wtay> omega_breakfast: it's very high end, yes
[22:03] <ajmitch> hmm, silly opn....
[22:03] <wtay> great, now netscape hangs...
[22:04] <omega_breakfast> you did tell them that shoving data from 50 suns through an ISDN lie is gonna suck?
[22:04] <omega_breakfast> er, line
[22:04] <wtay> omega_breakfast: they upgraded to 2Mbit, which is still a joke IMO
[22:04] <omega_breakfast> heh
[22:04] <omega_breakfast> how many of these machines actually directly serve http requests?
[22:04] Action: wtay heads off to the 1000$ version again..
[22:05] <omega_breakfast> ?
[22:05] <ajmitch> 200Mbit, maybe, but 2??
[22:05] <wtay> omega_breakfast: 2
[22:05] Action: omega_breakfast gags
[22:05] <omega_breakfast> dare I ask what the rest do?
[22:05] <wtay> omega_breakfast: 4 security ones, couple of LDAP servers, couple of management servers, routers, firewalls
[22:05] Nick change: omega_breakfast -> omega_
[22:06] <ajmitch> fscking mozilla!
[22:06] <omega_> ok, up to 14
[22:06] <wtay> omega_: couple of database servers etc...
[22:06] <omega_> 16
[22:06] <ajmitch> a few workstatiosnfor emplyees to use irc? ;)
[22:06] <omega_> hehehehe
[22:06] <wtay> hmm, lemme see what else we have...
[22:06] <wtay> oh yeah, a couple of print servers, X servers
[22:07] <ajmitch> damn, can't get java to work in mozilla
[22:07] <omega_> still not counting even close to 50
[22:08] <wtay> couple of document servers
[22:08] <omega_> 22...
[22:08] <wtay> couple of clients to poll the system, couple of NIDS servers
[22:08] <wtay> couple of logging servers
[22:09] Nick change: CHW-lunch -> ChiefHighwater
[22:09] <wtay> oh yeah and the tivoly management servers
[22:09] <omega_> um, lemme guess, they have rack after rack after rack of machines, right?
[22:09] <wtay> tivoli even
[22:09] <wtay> omega_: yup, small ones though
[22:09] <omega_> why don't they just get 1 rack with a bunch of 1u servers, x86, cluster them 2x, and be done with it
[22:10] <omega_> 42 machines in a rack, another rack with kvm switches & monitors just for fun
[22:10] <ajmitch> heaps of suns looks better ;)
[22:10] <wtay> omega_: it's not that easy with those huys :)
[22:10] <omega_> they make the designers look, um, brighter ;-)
[22:11] <ChiefHighwater> yeah, yeah, that's it
[22:11] <wtay> it's not funny... not at all... :(
[22:11] <wtay> somebody's gonna get fired...
[22:11] <omega_> amusing, at least
[22:12] <ajmitch> not you?
[22:12] <ChiefHighwater> if they fire Wim, RidgeRun would just have to hire him 8-]
[22:12] <wtay> I hope not.
[22:12] <wtay> fired I mean :)
[22:12] <omega_> ChiefHighwater: yup <g>
[22:13] <wtay> ahh those 3 PII's are just sooo much better :)
[22:13] <ajmitch> hadess was saying that even his job is uncertain... ;)
[22:14] Action: ajmitch doesn't have a job to be fired from ;)
[22:14] <dobey> heh
[22:14] <wtay> I forgot to say that we have the same setup x4 (test/E2E/accept/prod)
[22:14] <omega_> oh
[22:15] <wtay> I think it's just the net connection, on the LAN it flies
[22:15] <wtay> oh well..
[22:15] <omega_> E1 ?
[22:15] <wtay> ?
[22:15] <omega_> connection type
[22:16] <wtay> 2Mb cable connection
[22:16] <omega_> cable?
[22:16] <omega_> er, o
[22:16] <wtay> yeah
[22:16] <omega_> ick
[22:16] <wtay> a much slower version then I have at home :)
[22:16] <omega_> heh
[22:17] <wtay> I volunteered to host the damn thing but they refused :)
[22:17] <omega_> hehehe
[22:18] <wtay> they got the stats fron the ISP about the net utilisation, it peaked at 100% during evening hours... they were amazed :)
[22:18] <omega_> uh, you have a phone number for them I can call?
[22:18] <omega_> cause I want to say "DUH!" to them directly
[22:18] <wtay> hehehe, 
[22:19] <ajmitch> lol
[22:19] <wtay> dammit! anyway I got proof my SW is as fast as lightening :)
[22:20] <wtay> mpeg1 hangs..
[22:20] <wtay> err, mp3 too.. hmm.
[22:21] <omega_> mp3 works for me
[22:21] Action: wtay modprobes emu10k1
[22:21] <wtay> ok, mp3 works
[22:21] Action: omega_ modprobes snd-card-es1968
[22:21] <omega_> doh
[22:22] <omega_> taaz: what options have you been using for ./lat ?
[22:22] <wtay> mpeg1 system fails, mpeg1 video is ok, with lots of can't switch printouts
[22:22] <taaz> i checked in that latency tester
[22:22] Uraeus (cschalle at c224s9h5.upc.chello.no) joined #gstreamer.
[22:22] <taaz> heh... it isn't obvious? ;)
[22:22] <Uraeus> hiho
[22:22] <omega_> uh, no
[22:23] <taaz> something like ./lat 100000 1000 500 simple 13
[22:23] <wtay> Uraeus: howdy
[22:23] <omega_> segfault
[22:23] <taaz> segfault?
[22:23] <omega_> #0  0x8049715 in handoff_src (src=0x8070b58, buf=0x0, user_data=0x0) at lat.c:32
[22:23] <omega_> 32	  GST_BUFFER_TIMESTAMP(buf) = start;
[22:24] <ajmitch> hi Uraeus
[22:24] <taaz> did you rebuild with the fake{sink/src} updates?
[22:24] <omega_> er, no
[22:24] <taaz> it passes the buffer in the handoff signal now
[22:25] <omega_> ok, which numbers are interesting?
[22:25] Action: ajmitch waits for the recompile to finish...
[22:25] <taaz> the last one is latency in seconds
[22:25] Action: Uraeus is in a bad mood, we where to put the sailingboat on water today, well it is now in the water; grounded! fcsk bloody amatour boat harbour master
[22:25] <omega_> this one?: avg-s:0.-1472155730
[22:25] <ajmitch> oh dear
[22:25] <omega_> oooh
[22:25] <taaz> um... well it doesnt look like that for me ;)
[22:25] <wtay> Uraeus: oops
[22:25] <taaz> this isn't bulletproof code btw...
[22:26] Action: omega_ guesses Uraeus's boat isn't bulletproof either ;-(
[22:26] <ajmitch> Uraeus: was it low tide when you took it out, or high tide?
[22:26] Action: omega_ knows the harbormaster isn't
[22:26] <ajmitch> lol
[22:27] <Uraeus> ajmitch: low tide, but we waited until high tide and it was still grounded, so now we are hoping that the tide tommorow morning is higher than the one this evening, if not we have a 'small' issue
[22:27] <ajmitch> yeah...
[22:27] <taaz> the 500 is mhz of my machine btw...  the avg:# is the ticks, the avg-s is based on mhz... i have no idea if that calculation is proper or not
[22:27] <omega_> you've removed all excess weight from the boat?
[22:27] <omega_> avg:2084470544343
[22:28] steveb (steveb at node1ee04.a2000.nl) left irc: [x]chat
[22:28] <taaz> 0100000:00014273 min:00013880 max:00242465 avg:00014620 avg-s:0.000029240
[22:28] <omega_> er
[22:28] <omega_> 0100000:2186711044571 min:00000000 max:2186711044571 avg:2185195716519 avg-s:0.-1885274290
[22:28] Action: omega_ does a make
[22:28] <Uraeus> omega_: the problem is that it isn't deep enough for the boat to float anyway, we are currently just resting high on thr keel supported by the dock
[22:28] <ajmitch> omega_: maybe your machine is too fast? ;)
[22:28] <omega_> ajmitch: same as taaz's
[22:29] <omega_> Uraeus: ergh
[22:29] <ajmitch> Uraeus: how did it get there??
[22:29] <Uraeus> ajmitch: the harbour master lowered it down there with his crane
[22:29] <omega_> can't he just raise it back up again?
[22:29] <ajmitch> oh... ;)
[22:30] <Uraeus> he can raise it back up again, but then we are stranded on land
[22:30] <ajmitch> you think the harbour master should be lowered in with his crane & submerged? ;)
[22:30] <Uraeus> definetly
[22:30] <omega_> who needs a crane for that??
[22:30] <ajmitch> let him back up a few hours after the bubbles have stopped rising
[22:31] <Uraeus> well it is quite heavy so we can be sure he doesn't resurface if he is tied to the crane
[22:31] <omega_> taaz: um, still getting completely wrong results
[22:31] <omega_> Uraeus: good point
[22:31] <wtay> 0100000:00014416 min:00013729 max:17325004 avg:00014955 avg-s:0.000029910
[22:31] <wtay> what does it mean?
[22:32] <taaz> wtay: it's testing fakesrc -> identity*n -> fakesink
[22:33] <wtay> the time in ms to travel from src to sink?
[22:33] <taaz> all the numbers are ticks vs the last which is s based on the mhz param
[22:34] <omega_> now, someone for whom this works, compile with DEBUG disabled and time it again
[22:34] <taaz> you can do ...simple 0 for just src->sink 
[22:34] <wtay> omega_: can do..
[22:34] <taaz> there's a queue test in thre too but it doesnt work for me... dunno why
[22:34] <ajmitch> hmm, still compiling....
[22:35] Action: ajmitch needs faster computer....
[22:35] Action: ajmitch 'borrows' omega_'s computer ;)
[22:36] <taaz> anyone know if rdtsc value is syncronized accross processors in SMP system?  that queue test has multi threads and not sure if the numbers will mean anything if tick count isnt synced
[22:36] <omega_> taaz: no, afaik they're not
[22:37] <ajmitch> omega_: you have SMP?
[22:37] <omega_> well, they could be, but the tsc starts when the processor does, and the 2nd,3rd,etc. procs don't start up immediately
[22:37] <omega_> ajmitch: no
[22:37] <taaz> omega_: :( oh well... probably should switch that timing to something else then
[22:37] Action: wtay is rebuilding without DEBUG and INFO
[22:37] <omega_> taaz: maybe, unless you can force processor affinity at either end of the pipeline to the same proc
[22:38] <wtay> maybe you can measure the diff first and then recompensate
[22:39] <wtay> but that's hard I guess..
[22:39] <omega_> hrm, that would do it
[22:39] <omega_> the buffer timestamp is always zero
[22:39] Action: omega_ doublechecks fakesrc
[22:40] Action: omega_ has HEAD
[22:40] <ajmitch> yay, gstreamer compiled...
[22:41] <omega_> handoff_src is firing
[22:41] <wtay> omega_: does rdtsc work?
[22:41] <omega_> yes
[22:41] <omega_> monotonically increasing, a really big number
[22:42] <omega_> something's clearing the timestamp on the buffer
[22:43] <wtay> 0100000:00013302 min:00013026 max:19857687 avg:00013801 avg-s:0.000027602
[22:43] <taaz> hmm... i didn't think this would cause so much trouble ;)
[22:43] <omega_> hmm
[22:43] <omega_> not significant difference, from .0000299 to .0000276
[22:43] <wtay> is that good or bad?
[22:43] <wtay> I mean the numbers
[22:44] <taaz> how many elements did you do?  (ie the simple # param?)
[22:44] <wtay> 13
[22:45] <omega_> good, in that the debug stuff doesn't have hardly any impact on performance, even when inline'd like the stuff in HEAD still is
[22:45] <wtay> I guess I should use 1200 too instead of 500
[22:45] <omega_> um, yeah <g>
[22:45] Action: omega_ thwacks wtay
[22:45] <wtay> 0100000:00013119 min:00013003 max:22634248 avg:00014755 avg-s:0.000012295
[22:45] <omega_> oy
[22:45] <ajmitch> hehe
[22:45] <taaz> i'm not sure how useful the numbers are... 
[22:45] <omega_> so, .12msec latency
[22:46] <omega_> not bad ;-0
[22:46] <taaz> it includes the overhead of fireing signals too...
[22:46] <omega_> wtay: change the params in cothreads.h to match INCSCHED1
[22:46] <omega_> yeah
[22:46] <taaz> if you patch cothread files you could try it with 61
[22:46] <omega_> you can get up to 61 identities then
[22:46] Action: omega_ still can't figure out why the buffer timestamp is getting cleared
[22:47] <omega_> printing it out in handoff_src shows that it's getting set right
[22:47] <omega_> but before it gets to handoff_sink, it's cleared
[22:47] <omega_> even with zero identities
[22:48] <omega_> it's the same buffer pointer on either end
[22:48] <taaz> thats odd
[22:49] <omega_> http://www.eca.cx/laaga
[22:49] hehehehe (trevo at 208.141.162.68) joined #gstreamer.
[22:49] <omega_> yo
[22:49] Action: thomas is back
[22:49] <thomas> damn it's hot in belgium
[22:49] <wtay> thomas: yeah :)
[22:49] Action: omega_ is rebuilding libgst.la from scratch
[22:49] <wtay> omega_: hmm, segfaults, 13 is fine...
[22:50] <omega_> segfaults with how many?
[22:50] <wtay> >13
[22:50] <omega_> even with the different numbers in cothreads.h ?
[22:50] <omega_> #define COTHREAD_STACKSIZE 32768
[22:50] <omega_> #define COTHREAD_MAXTHREADS 64
[22:50] <omega_> #define STACK_SIZE 0x200000
[22:50] <wtay> #define COTHREAD_STACKSIZE 32768
[22:50] <wtay> #define COTHREAD_MAXTHREADS 64
[22:50] <wtay> #define STACK_SIZE 0x200000
[22:50] <omega_> hmm
[22:51] <omega_> try reducing the stacksize back to 8KB
[22:51] <wtay> is STACK_SIZE = CT_STACKSIZE*MAX_CT?
[22:51] <omega_> theoretically
[22:51] <taaz> the number of current cothreads is known isn't it?  in cothread_create we should really check if you are at the max and return NULL if so.  and make the callers check for that too (just in gstschedule i think?)
[22:52] <omega_> taaz: yeah, I'll do that
[22:52] <wtay> omega_: then a 0 is missing
[22:52] <omega_> wtay: oh?
[22:52] Action: ajmitch is meant to be doing maths homework ;)
[22:52] <omega_> STACK_SIZE should == 2MB
[22:52] <wtay> 200000 != 2MB
[22:52] <wtay> == 200K
[22:52] <omega_> it's 2MB
[22:53] <omega_> 0x200000
[22:53] <taaz> that's hex 0x200000
[22:53] Action: omega_ hands wtay a BPB
[22:53] Action: wtay twacks himself
[22:54] <wtay> ouch
[22:54] <wtay> 0100000:00074653 min:00072726 max:31463607 avg:00079601 avg-s:0.000066334
[22:54] Action: ajmitch attempts to understand how to hack plugins
[22:54] <wtay>  ./lat --gst-mask=-1 100000 10000 1200 simple 61
[22:55] <taaz> wtay: can you try 'queue' instead of 'simple'?  oh.. and fix it so it works too ;)
[22:55] <omega_> so it's about 1msec per identity
[22:55] <wtay> it's not chain based
[22:55] <omega_> right, a chain-capable scheduler will make that lots faster
[22:55] <ajmitch> where is this latency tool?
[22:55] <omega_> HEAD:test/lat.c
[22:56] <omega_> not that it's doing me much good ;-(
[22:56] Action: ajmitch wonders where it has got to...
[22:56] <ajmitch> got it. now how much should i recompile? ;)
[22:57] <omega_> World
[22:57] <wtay> ./lat --gst-mask=-1 100000 10000 1200 queue 61
[22:57] <wtay> 0100000:15523882 min:00230896 max:38622756 avg:06809998 avg-s:0.005674998
[22:57] <omega_> ouch
[22:57] Action: omega_ isn't surprised
[22:57] <taaz> heh... what is that?
[22:57] <omega_> waitasec
[22:57] <omega_> why are you running with --gst-mask=-1 ???
[22:57] <wtay> 'cause it doesn't matter
[22:58] <omega_> erm
[22:58] <wtay> 0100000:05626654 min:00048623 max:56476447 avg:07034033 avg-s:0.005861694
[22:58] <taaz> hold up... queue thing works for you?  i swear i had it working then it stopped doing so and i couldnt figure out why
[22:58] <wtay> to be sure info/debug is compiled out
[22:58] <omega_> ok
[22:58] Action: omega_ still gets zero'd timestamp field
[22:58] Action: omega_ is getting annoyed
[22:58] <wtay> omega_: it must be cleared somewhere..
[22:59] <omega_> duh
[22:59] <wtay> I mean *somewhere*
[22:59] <omega_> but where??
[22:59] <taaz> hmm... is there some locking problem? i can get it to output a few buffers if i run it many times... odd
[22:59] <wtay> taaz: could be
[23:00] <taaz> how did you run it with 61 anyway?  queues and extra threads don't get cothreads?
[23:00] <wtay> omega_: printf time
[23:01] <omega_> wtay: yeah
[23:01] <omega_> taaz: each thread gets its own set of cothreads
[23:01] <wtay> ./lat 100000 10000 1200 queue 61
[23:01] <taaz> ahh... ok
[23:01] <omega_> I can run 61 cothreads though, at 8KB/each
[23:02] <wtay> omega_: yup, that's what I did too
[23:02] <wtay> time ./lat 100000 10000 1200 queue 61
[23:02] <wtay> 0100000:04949233 min:00046531 max:38358285 avg:06769768 avg-s:0.005641473
[23:02] <wtay> real	0m5.771s
[23:02] <wtay> user	0m4.430s
[23:02] <wtay> sys	0m1.210s
[23:02] Action: omega_ wishes linuxthread implemented the function that set the thread stack size
[23:02] <taaz> hmm.. well, its sort of randomly getting into a spin state on my smp machine.  that's no good.
[23:03] <wtay>  time ./lat 100000 10000 1200 simple 61
[23:03] <wtay> 0100000:00074961 min:00073272 max:23594120 avg:00078818 avg-s:0.000065681
[23:03] <wtay> real	0m15.816s
[23:03] <wtay> user	0m15.470s
[23:03] <wtay> sys	0m0.060s
[23:03] Action: omega_ offers to take taaz's extra, troublesome processor
[23:03] <wtay> 4 times as long...
[23:03] <dobey> just buy a dual g4
[23:03] Action: omega_ drools
[23:04] <ajmitch> 8088 & 640k ought to be enough for everybody ;)
[23:04] Action: wtay wants an 8-way Athlon 1.4 GHz system
[23:04] <omega_> ah, so now we know who ajmitch really is
[23:04] <wtay> ajmitch: yeah look where he ended up :)
[23:04] thomas (thomas at adsl-63930.turboline.skynet.be) left irc: Ping timeout for thomas[adsl-63930.turboline.skynet.be]
[23:04] <ajmitch> lol
[23:04] <dobey> dude
[23:04] <dobey> PS
[23:05] <dobey> /
[23:05] <dobey> 2
[23:05] <ajmitch> heh, who wants a ps/2? ibm stopped making them ages ago ;)
[23:06] <dobey> haha
[23:09] <ChiefHighwater> anyone want my TI 994a...it has 64k RAM!
[23:10] <wtay> ChiefHighwater: sure :)
[23:10] <ChiefHighwater> maybe it would make a good donation for a museum!?!
[23:11] <ChiefHighwater> I even had a casette tape drive for that thing
[23:11] <ChiefHighwater> I think I still have the drive
[23:11] Uraeus (cschalle at c224s9h5.upc.chello.no) left irc: syntax error - user imploded
[23:19] <omega_> um, now I don't get zeroing
[23:20] Action: omega_ goes to remove the debug outputs in order
[23:20] <omega_> erm
[23:21] hehehehe (trevo at 208.141.162.68) left irc: Read error to hehehehe[208.141.162.68]: EOF from client
[23:21] <omega_> I added printfs all over the place: fakesrc_get, handoff_src, pushfunc_proxy, pullfunc_proxy, fakesink_chain, handoff_sink
[23:22] <omega_> removed from fakesrc_get, no change
[23:22] <omega_> removed from handoff_src, it drops back down to zero
[23:22] <wtay> hmm
[23:24] <omega_> it would seem to me somehow that the assignment isn't actually happening for some reason, maybe because it's not being immediately accessed
[23:24] <omega_> even though that's not relevant to such an assignment
[23:25] <omega_> even more odd:
[23:25] <omega_> printing out the start var (right after rdtsc) gives zero, but then the correct value manages to make its way into the buffer timestamp and through the pipeline
[23:25] <omega_> taaz: are you sure you wrote rdtsc correctly??
[23:26] <omega_> I'm not sure you did at all
[23:26] <taaz> nope
[23:27] <omega_> #define rdtscll(result) \
[23:27] <omega_>         __asm__ __volatile__("rdtsc" : "=A" (result) : /* No inputs */ )
[23:27] <taaz> well, i just took the code from gsttrace.c and had to hack off those regs at the end to get it to compile
[23:27] <omega_> doesn't take a pointer
[23:27] <omega_> um
[23:27] <omega_> you don't want to be doing stuff with pointers like that unless you explicitely write up the inline asm so it knows that the *contents* of those pointers are going to be touched
[23:28] <omega_> it was probably optimizing the rdtsc out of the binary alltogether
[23:28] Action: taaz laughs
[23:29] <taaz> heh.. so what's the fix?
[23:29] <omega_> use the above rdtsc
[23:29] <omega_> remove the & in front of start and end
[23:29] <omega_> much much much better
[23:29] <omega_> 0100000:00002488 4028080695660->4028080698148 min:00002319 max:11526226 avg:00003013 avg-s:0.000006026
[23:29] Action: taaz is confused
[23:30] <omega_> that was with zero identities
[23:30] <omega_> 0100000:00056289 4046672090721->4046672147010 min:00054207 max:24471894 avg:00061624 avg-s:0.000123248
[23:30] <omega_> with 61
[23:30] <taaz> ok... well, if you want to commit a fix i suggest you update gsttrace.c too
[23:30] <omega_> taaz: you understand how 64-bit x86 instructions work?
[23:30] <omega_> ok
[23:30] <taaz> omega_: not at all ;)
[23:31] <taaz> which should be obvious right about now <g>
[23:31] <omega_> they write into eax and edx
[23:31] <omega_> the above line (the 'A') tells gcc/as to 'place' the 64-bit variable in those registers before calling that instruction
[23:32] <omega_> to get the data back out, gcc is responsible for managing the two registers and the ptr math to put them in the right place in the stack variable start or end
[23:33] <taaz> hmm... so i guess that's why your original code had that eax and edx stuff.  compiler was just choking on it... didn't know how else to fix it
[23:33] <omega_> yeah, that must have been a really really old copy of rdtsclll
[23:33] <omega_> er, ll
[23:33] <omega_> committed
[23:34] <ajmitch> who? ;)
[23:35] <taaz> seriously... fix gst/gsttrace.c too.  HAVE_RDTS is never defined... but just to avoid future confusion...
[23:39] <omega_> ok
[23:39] <omega_> we don't even use gsttrace anyway
[23:39] <wtay> same results though here
[23:40] <omega_> depends on your a) compiler, b) optimization options, c) sign
[23:41] thomas (thomas at adsl-64079.turboline.skynet.be) joined #gstreamer.
[23:44] <omega_> erm, I have a 2xN table in a text file, I want to plot it as X,Y in gnuplot
[23:45] <omega_> help?
[23:48] <omega_> anyone?
[23:49] greg_ (greg at home.sente.pl) joined #gstreamer.
[23:49] <wtay> no idea...
[23:49] <taaz> can't be that hard... i've done stuff like that before
[23:49] <taaz> like a few years ago though...
[23:49] <omega_> yeah, but the help system is less than useful
[23:49] <omega_> I just need the command to read the data and plot
[23:49] <ChiefHighwater> M$ Word <G>
[23:49] <omega_> I did this years ago too
[23:50] <omega_> ChiefHighwater: go away <g>
[23:50] <ChiefHighwater> lol
[23:50] <omega_> there we go
[23:50] <taaz> plot "foo.dat"?
[23:51] <omega_> ah, that's it
[23:51] <omega_> needed the dblquotes
[23:51] <ajmitch> oh, yeah, gnuplot is easy ;)
[23:51] <thomas> omega_: I added my project to the wiki
[23:51] Action: ajmitch was sorta away ;)
[23:51] <omega_> thomas: yup
[23:51] <thomas> I'm still working on the main ideas though
[23:51] <thomas> so the site isn't really "open" yet
[23:53] <omega_> gstreamer.net/images/cothreadtimings.png
[23:54] <omega_> "Thou shalt not follow the Null Pointer, for at it's end Madness and Chaos lie."
[23:54] <omega_> from /. .sig
[23:55] <vini> :)
[23:55] <taaz> um... i updated the cothread values but it's still dying. 
[23:55] <omega_> to 8192, 64 ?
[23:55] <taaz> is it just those two values?
[23:55] <taaz> 8192? i thought that was 32768?
[23:55] <omega_> it was, but that doesn't seem to work
[23:56] <taaz> i noticed ;)
[23:56] Action: taaz grumbles as whole tree recompiles
[23:56] <ajmitch> taaz: hehe, you too? ;)
[23:57] <wtay> omega_: hmm, are those your values?
[23:57] <omega_> yeah
[23:58] <wtay> [23:30:17] <omega_> 0100000:00056289 4046672090721->4046672147010 min:00054207 max:24471894 avg:00061624
[23:58] <omega_> it seems that 512KB is the maximum stack size for a pthread
[23:58] <omega_> which is *pathetic*
[23:59] <omega_> there's no good reason for it to be that small. since it's dynamically allocated by the kernel anyway, it could be .25GB or more
[23:59] <taaz> values like COTHREAD_STACKSIZE could be in a the .c vs the .h.  so as to not require a full rebuild
[23:59] <omega_> yeah, I just did that
[23:59] <omega_> committed
[00:00] --- Fri May 11 2001
[00:00] <wtay> I now have a refcounting scheme that mimics gtk (with floating and finalization/destroy/shutdown etc)
[00:00] <omega_> ok
[00:01] <wtay> the parts that are gone in glib2 are implemented like in gtk1.3.5
[00:01] <omega_> ok
[00:01] <taaz> um.. you need to move that cothread_context stuff into the .c too
[00:01] <taaz> it uses CT_MAXTHREADS but i think that struct is just used in the .c anyway
[00:01] <omega_> hmm?
[00:01] <wtay> refcounting is still done on the gtk object (without locking)
[00:01] <omega_> oh
[00:01] <omega_> oops
[00:02] <taaz> err... actually... not sure how this will work... need to move private api somewhere else maybe
[00:03] <omega_> no, that works
[00:04] <taaz> heh... cant you output an image from gnuplot vs taking a screenshot?
[00:04] <dobey> yes
[00:04] <dobey> at least, yahoo does
[00:05] <dobey> bleh
[00:05] <omega_> yeah, I just don't remember how
[00:05] dobey (dobey at 141.154.95.104) left irc: home...
[00:06] <ajmitch> 0100000:19039492 min:00062212 max:186234184 avg:17582214 avg-s:0.043955535
[00:06] <ajmitch> i got a slow computer, right? ;)
[00:07] <omega_> um, yeah ;-)
[00:07] <ajmitch> 0100000:00065748 min:00056448 max:69209812 avg:08764994 avg-s:0.021912485
[00:07] <ajmitch> stopped xmms...
[00:07] <omega_> that helps
[00:07] <ajmitch>  ./lat 100000 10000 400 queue 13
[00:08] <ajmitch> was what i used
[00:08] <taaz> try simple vs queue
[00:08] <omega_> simple is more intersting
[00:08] <taaz> i'm not sure the queue numbers are useful at all as is
[00:08] <omega_> better than nothing
[00:09] <ajmitch> 0100000:00029512 min:00029216 max:52895500 avg:00040692 avg-s:0.000101730
[00:09] <ajmitch> from replacing queue with simple
[00:09] <taaz> maybe a better test would be to dump the timing for each buffer and gnuplot it... the the data dump will adversly effect the results.
[00:09] <taaz> could make a big array for the data i guess... and print after its done processing...
[00:09] <omega_> that's what gsttrace.c is for <g>
[00:10] <taaz> yeah... i figured... ;)   go forth and add a HAVE_RDTS check
[00:10] <omega_> RDTSC even
[00:11] Action: taaz notes gsttrace.c has RDTS
[00:11] <omega_> yes, but that's a typo
[00:18] <omega_> using simplified macros instead of function calls for gst_pad_push and gst_pad_pull shaves almost 20% off total time
[00:18] <taaz> for what test?
[00:18] <omega_> simple 61
[00:18] <omega_> 100msec from 120msec
[00:19] <omega_> committed
[00:20] Action: taaz happy...  even somewhat questionable benchmarks like lat.c help direct optimization effort ;)
[00:21] <omega_> and just think about how much overhead is might be in the signal handling, etc.
[00:21] <omega_> though we can quantify that as a constant in the graph
[00:21] <taaz> i bet the LAD people would smack you if you tell them a null pipeline of 61 elements has 100ms latency
[00:21] <omega_> 100us
[00:21] <omega_> very very different
[00:21] <taaz> yeah... that too ;)
[00:22] <omega_> what, they can do better?
[00:22] <taaz> 06:29PM <omega_> 100msec from 120msec
[00:22] <omega_> er, ok
[00:22] <omega_> usec
[00:22] Action: wtay has to sleep now
[00:22] Nick change: wtay -> wtay-zZZZz
[00:22] <omega_> you haven't fixed autoplug yet!
[00:22] <wtay-zZZZz> cya all
[00:23] <wtay-zZZZz> omega_: uhm
[00:23] <taaz> they?  why worry about them... -we- can do better.  (by we i mean you of course)
[00:23] <wtay-zZZZz> omega_: tomorrow, I promise
[00:23] <omega_> heh, ok
[00:23] <thomas> bye wtay
[00:23] <omega_> taaz: yeah, but they can't even pull off a null pipeline, so I guess we're OK
[00:24] <ajmitch> when's 0.2.0 planned to be released? ;)
[00:24] <ajmitch> and what libs will HEAD rely on after that?
[00:25] <taaz> omega_: are you going to fix that cothread thing?  it's not compiling as is
[00:25] <omega_> er, fixing
[00:25] <omega_> committed
[00:31] Action: thomas is going to sleep
[00:31] <thomas> bye all
[00:31] <thomas> omega_: when you find the time let me know what you think of the structure ideas
[00:32] thomas (thomas at adsl-64079.turboline.skynet.be) left irc: Client Exiting
[00:39] <omega_> ok
[00:40] <omega_> oh, he's gone
[01:02] <taaz> how would one go about writing a test for HAVE_RDTSC?
[01:03] <taaz> not sure if a run-and-check-for-segfault is appropriate.  maybe better to look at machine type and define ti for i[56..]86 and so on
[01:04] <omega_> yeah
[01:08] greg_ (greg at home.sente.pl) left irc: Read error to greg_[home.sente.pl]: EOF from client
[01:21] <ChiefHighwater> gnite all 8-]
[01:21] <omega_> l8r
[01:21] ChiefHighwater (paul at temple-baptist.com) left irc: 
[01:41] <omega_> taaz: using a loop_based=TRUE identity shaves 1/3 total time
[01:46] <omega_> total for 61 identities goes from 129usec to 74usec with loop=true and the gstpad.h updates turned on
[01:46] <omega_> trim 43% off ;-)
[01:46] <taaz> hmm... why?
[01:46] <omega_> just wait until the scheduler can set up chained stuff
[01:47] <omega_> loop=true removes the requirement for chain_wrapper, which isn't too efficient (can't be)
[01:47] <omega_> loop=true bypasses that and does the work directly
[01:49] <taaz> is that a practical way to test things?  are most sources loop or chain?
[01:49] <taaz> i guess if you are just trying to test overhead in ideal conditions then loop would be best
[01:49] <omega_> once the scheduler is fully capable of it, chained functions will be called directly anyway
[01:49] <omega_> so the case of a the scheduler making a chain into a loopfunc is a punt
[01:54] <taaz> a good test case would be an ardour clone ;)  just to claim the hears and minds of the LAD crowd
[01:54] <omega_> yeah
[01:54] <taaz> s/hears/hearts
[01:54] <omega_> hears? ;-)
[01:54] <omega_> 'hears' makes sense <g>
[01:54] <taaz> heh
[01:54] <omega_> have you ever tried to actually *compile* ardour and all its 200+ dependencies with massive versioning problems?
[01:55] <taaz> not at all...
[01:55] <omega_> besides, AES seems to do it all now, and I can find zero indication of where to find it
[01:55] <taaz> i played with quasimodo in its early days.  it was big and hairy then too
[01:55] <taaz> find what?
[01:55] <omega_> AES
[01:57] <omega_> http://www.eca.cx/laaga/spec/index.html is interesting
[01:58] <omega_> just points out the need for everything to be built at plugins, so you can suck a drum machine *into* your DAW system
[01:58] <taaz> yeah, saw that
[01:58] <omega_> maybe high-level CORBA, low-level inproc gstreamer
[02:00] <taaz> um... so isnt this AES just part of ardour cvs?
[02:00] <omega_> nope
[02:01] Action: omega_ has been asked to move off of bear.opn.net
[02:01] omega_ (omega at omegacs.net) left irc: moving
[02:01] omega_ (omega at omegacs.net) joined #gstreamer.
[02:05] <omega_> > Has anyone developed a LISP for the RCX?
[02:05] <omega_> you mean like "are theee exth"?
[02:11] vini (vincent at bones.kulnet.kuleuven.ac.be) left irc: [x]chat
[02:34] Nick change: omega_ -> omega_dinner
[03:17] Topic changed on #gstreamer by ChanServ!s at ChanServ: GStreamer: the ultimate multimedia framework
[04:53] <taaz> ahh... there's a cpuid bit for rdtsc. 
[05:04] <taaz> not that i feel like using it... but..
[05:04] <omega_dinner> have fun <g>
[05:05] <omega_dinner> remember that that's a runtime thing, not just configure-time
[05:40] Nick change: omega_dinner -> omega_
[05:57] <omega_> I think I finally have ardour building, sorta
[05:58] Action: omega_ loves the 15% sawtooth pattern g++ causes in his 256MB-scale RAM-usage display
[05:59] <omega_> make that 20%
[06:00] <omega_> and release 0.99.8 has massive syntax errors in hammerfall.*
[06:02] <omega_> that's because it's built again alsa 0.6.x, not 0.9.x
[06:02] <omega_> and there is no alsa code or hardly anything else in ardour cvs
[06:02] <taaz> so, if this cothread limit can't be fixed would it be possible to hack something that just started inserting extra threads to hold more cothreads?  have it transparent and some lightweight threadsafe buffer transfer code...
[06:04] <omega_> buffer transfer code?
[06:05] <taaz> queues
[06:05] <taaz> small ones
[06:05] <omega_> er, what does that have to do with cothreads?
[06:05] <taaz> i don't like 64 element limits ;)
[06:05] <taaz> looknig for hack around it
[06:05] <omega_> and what do queues have to do with that?
[06:07] <taaz> um... if you have pipeline like e-e-e-...-e-e-e  could you just add a thread in there to reduce cothreads per thread?  e-e-e-[-e-e-e-e-]-e-e-e or whatever..
[06:08] <taaz> i don't know what i'm talking about ;)  i just want to run a latency test with 1000 elements and i cant do it
[06:08] Nick change: omega_ -> omega_phone
[06:13] <omega_phone> then build the pipeline that way....
[06:14] <taaz> well yeah... of course you could do that... but it would be nice if the framework would do it for me
[06:14] <omega_phone> but then the framework can arbitrarily cause significant problems with latency
[06:15] <omega_phone> I want to *know* when the gst core is going to do something like that