[gst-devel] Daily IRC logs

[wim.taymans at chello.be]

[06:46] ajmitch_ (ajmitch at p57-max10.dun.ihug.co.nz) joined #gstreamer.
[06:46] aj_uni (ajmitch at p35-max5.dun.ihug.co.nz) left irc: Ping timeout for aj_uni[p35-max5.dun.ihug.co.nz]
[06:56] ajmitch_ (ajmitch at p57-max10.dun.ihug.co.nz) left irc: Ping timeout for ajmitch_[p57-max10.dun.ihug.co.nz]
[06:58] ajmitch_ (ajmitch at p36-max1.dun.ihug.co.nz) joined #gstreamer.
[08:22] Ow3n (owen at ti34a80-0313.bb.online.no) joined #gstreamer.
[08:22] <omega_> yo
[08:22] <Ow3n> yo
[08:22] <Ow3n> How's things?
[08:22] <omega_> getting better
[08:23] <Ow3n> insched1 nearly there?
[08:23] Action: omega_ is cleaning up the mass of DEBUG and INFO statements floating around
[08:23] <Ow3n> Sounds pretty close then.
[08:23] <omega_> the next trick is to follow the 9702 lines of output from gstmediaplay --gst-mask=-1 before it deadlocks
[08:23] <Ow3n> Urgh.
[08:24] <omega_> yeah, but a lot of that is nego stuff, which I can remove
[08:24] <Ow3n> ok
[08:24] ajmitch_ (ajmitch at p36-max1.dun.ihug.co.nz) left irc: Ping timeout for ajmitch_[p36-max1.dun.ihug.co.nz]
[08:24] <Ow3n> does it lock up more-or-less straight away?
[08:24] <omega_> almost
[08:24] ajmitch_ (ajmitch at p24-max6.dun.ihug.co.nz) joined #gstreamer.
[08:24] <Ow3n> Then I guess it should be eaiser to trace
[08:25] <omega_> it locks up after some data flow, but immediately after one of the autoplugs triggers
[08:25] Action: omega_ expects it'll require some significant changes to autoplug over time
[08:25] <Ow3n> I've got a really annoying bug to track down in my sound card drivers. My kernel locks up the _2nd_ time I send anything to /dev/dsp.
[08:25] <omega_> rather, not require, but allow significant improvement
[08:25] <omega_> oops
[08:26] <omega_> have you seen the latest colorization stuff? <g>
[08:26] <Ow3n> It's kind of annoying. I've never had any sound in Linux
[08:26] <Ow3n> No.
[08:26] <Ow3n> I havn't checked out HEAD for some time.
[08:26] <omega_> gstreamer.net/linux/color-debug.png is an older shot
[08:26] <omega_> the bulk of colorization is on INCSCHED still
[08:26] <Ow3n> cool. hang on...
[08:26] <ajmitch_> no sound?
[08:27] <Ow3n> no. I've never gotten any sound drivers to work :(
[08:27] <ajmitch_> must be bad bug to lock up kernel ;)
[08:27] <ajmitch_> not alsa drivers?
[08:27] <Ow3n> Nope.
[08:27] <Ow3n> Actually the ALSA thing is even more frustrating.
[08:28] <ajmitch_> man, what sound card is it?
[08:28] <ajmitch_> just so i don't buy one by mistake ;)
[08:28] <Ow3n> E-mu APS.
[08:28] <Ow3n> You definately don't want to buy one.
[08:28] <Ow3n> It was a great card for about a year...
[08:28] <omega_> Ow3n: reload the .png if you've already got it, there's a new one up
[08:28] Action: omega_ likes his Live!
[08:28] <Ow3n> omega_: 404
[08:29] <omega_> gstreamer.net/images/color-debug.png
[08:29] <omega_> doh, how did I mistype that one??
[08:29] <Ow3n> omega_: sweet!
[08:29] <omega_> that's just about everyone's reaction <g>
[08:29] Action: ajmitch_ likes his SB16 ISAPNP card ;)
[08:30] <Ow3n> The APS is essentially a Live! but with profesional quality IN/OUTs + more digitals.
[08:30] <omega_> hmm
[08:30] <Ow3n> It came out 6 months before the Live! and cost $600 then the Live came out. Same chipset but $100.
[08:30] <omega_> doh
[08:31] <Ow3n> doh, indeed.
[08:32] <Ow3n> So hence, the ALSA emu10k1 drivers work as far as /dev/dsp goes but no mixer and by default everything is muted in ALSA.
[08:32] <Ow3n> DOH!!!!!
[08:32] <omega_> yeah, alsa's utils are kinda lame, esp when you look at the hammerfall
[08:32] <Ow3n> hammerfall?
[08:32] <omega_> but then as I found out, so are Windoze's controls for the STUDI/O, without a mouse
[08:33] <omega_> 16+16, dual ADAT
[08:33] <Ow3n> Ah, neat. URL?
[08:33] <omega_> STUDI/O is the same, though the hammerfall can take a board that adds another ADAT rx/tx pair for 24+24
[08:33] <omega_> www.rme-audio.com
[08:33] <omega_> you need off-board A/D/A though
[08:34] <Ow3n> That's OK.
[08:34] <Ow3n> Hmmm. This looks pretty cool.
[08:34] <omega_> off-board ada is very $$$$
[08:35] <omega_> the key is that I need to get an alsa 0.9.x API alsasrc and alsasink that can have N pads, one for each channel on the card
[08:35] <omega_> ardour is the *only* example of that, and it's very dense
[08:36] <Ow3n> I was wondering about that actually. Are stereo elements the way to go? E.g. volume? Because it doesn't always make sense when you want to use alot of channels.
[08:36] <omega_> ah, from 9702 to 3662 lines by turning off the caps and autoplug stuff
[08:37] <omega_> Ow3n: well, we need both
[08:37] <omega_> a lot of people will deal with stereo
[08:37] <Ow3n> Can't they just use a pair of monos?
[08:37] <omega_> but then there are maniacs that will deal with ambisonic mixes, which can have as many as 9 channels in one stream
[08:37] <omega_> yes, they can, but there are cases where you don't want to
[08:38] <Ow3n> ok
[08:38] <omega_> which is why we need to have some classification scheme for audio plugins
[08:38] <omega_> the basic one just works at the common formats, mono stereo, etc.
[08:38] <omega_> then you get into a comprehensive 'consumer' caps set, then finally 'pro'
[08:39] <omega_> where the plugins have more and more optimization for common formats, like the 'pro' would handle float audio
[08:39] <Ow3n> Yes, I see.
[08:39] <Ow3n> That would make sense.
[08:39] <omega_> this doesn't have to be coded at all, just some kind of stamp with a label people can use
[08:39] <Ow3n> Yes.
[08:40] <omega_> though there should be some kind of preference given to elements with larger caps
[08:40] <omega_> if you have two options, and one element can deal with a wider range of caps, chances are you're gonna get the best results from that one, rather than the simple one that only handles stereo
[08:40] <Ow3n> Yes, at least as far as autoplugging as concerned.
[08:40] <omega_> then again, we need to put thought into the generic 'merit' concept anyway, but that's a part of it
[08:41] <Ow3n> BTW. Back to my favorite subject. Yes, networking :)
[08:41] <omega_> heh
[08:41] <Ow3n> Is the plan still to use CORBA within gstreamer?
[08:41] <omega_> yeah
[08:42] <Ow3n> Is that something you're discussing at Ridgerun?
[08:42] <omega_> yup
[08:42] <omega_> they're pushing for a general corba-ization, but I keep pushing back with arguments against, and they seem to see my point
[08:43] <Ow3n> What are your arguments against?
[08:43] <omega_> basically, I think that the work of corbaization, compare to the work needed to get the same benefits, is higher
[08:43] ajmitch_ (ajmitch at p24-max6.dun.ihug.co.nz) left irc: Ping timeout for ajmitch_[p24-max6.dun.ihug.co.nz]
[08:43] <omega_> and maintaining a heavily corbaized system is harder as well
[08:43] <Ow3n> Yes.
[08:44] <omega_> we only need a few key features of corba in the general case
[08:44] <Ow3n> It seems like a bit of a sledgehammer approach.
[08:44] <omega_> and those can be provided other ways, with corba acting as a special-case thing
[08:44] <Ow3n> yes.
[08:44] <omega_> eventually I'll want to write up all this, because it's interesting, and it'll end up being a faq one of these days, esp after we move to gobject
[08:45] <Ow3n> yeah.
[08:45] <Ow3n> I keep hitting walls with bonobo.
[08:45] <Ow3n> It's not that it can't do things I want it to do.
[08:46] <Ow3n> It's just that's it's often not clear what The Right Way [tm] is.
[08:46] <Ow3n> There are no examples that really use bonobo extensively.
[08:46] <Ow3n> Evolution, Gnumeric etc. use it to componentise certain aspects of their application.
[08:46] <Ow3n> But there aren't any examples using bonobo for their entire class structure.
[08:47] <omega_> the problem is that mango is only half the battle
[08:47] <omega_> deep integration of corba and gobject is the key
[08:47] <Ow3n> It would be nice.
[08:47] ajmitch_ (ajmitch at p10-max7.dun.ihug.co.nz) joined #gstreamer.
[08:47] <omega_> rr might get involved in that kind of stuff eventually
[08:48] <omega_> or maybe on the side..
[08:48] <Ow3n> Ok.
[08:49] <Ow3n> Hmmm... I'd better get to work soon.
[08:49] <Ow3n> It's 9 already.
[08:49] <omega_> cool
[08:49] <Ow3n> S'pose I'd better try and make it b4 lunch.
[08:49] <omega_> no it isn't, you've got >1min
[08:50] <omega_> er, <1min
[08:50] <Ow3n> less now...
[08:50] Action: omega_ loves ntp
[08:50] Action: Ow3n does too.
[08:50] <Ow3n> 15secs
[08:50] <Ow3n> OK. Now it's 10
[08:50] <omega_> I just wish there was a better way to pick a stratum N server
[08:50] <Ow3n> Er... 9
[08:50] <omega_> hrm, /me is drifting
[08:51] <omega_> ok, fixed
[08:51] <Ow3n> How do you mean?
[08:51] <omega_> I've gone a while since last boot, and my ntpd isn't configured very well
[08:51] <omega_> I need to set up my gateway to broadcast
[08:52] <Ow3n> Ah, right. I've done that. Do you want my ntpd.confs?
[08:52] <omega_> yeah, can you mail it to me?
[08:52] <Ow3n> No probs.
[08:52] Action: omega_ can't wait till mobos with onboard gps for time management are an option
[08:53] <omega_> and built-in lojack <g>
[08:53] <Ow3n> :)
[08:53] <Ow3n> I'm going to get some 802.11b cards in a couple of weeks.
[08:54] <Ow3n> I'm fed up tripping over this damn blue cable.
[08:54] <omega_> wireless is neat, except I've still got this darn power cord...
[08:54] <omega_> but at least I can disconnect for 2+hrs and go fully wireless
[08:54] <Ow3n> Wireless power. Now that would be a thing :)
[08:54] <omega_> it exists, it's just not cool. literally
[08:55] <Ow3n> Wow. How does it work?
[08:56] <omega_> microwaves
[08:57] <Ow3n> And people get scared about mobile phones.
[08:57] <omega_> "honey, you sure this wireless power thing is safe?  fido is glowing..."
[08:57] <Ow3n> :)
[09:00] <Ow3n> Damn, I really have to go.
[09:00] <Ow3n> Catch you later.
[09:00] <omega_> ok, l8r
[09:00] Ow3n (owen at ti34a80-0313.bb.online.no) left irc: [x]chat
[09:04] Nick change: ajmitch_ -> aj_busy
[10:37] aj_busy (ajmitch at p10-max7.dun.ihug.co.nz) left irc: Ping timeout for aj_busy[p10-max7.dun.ihug.co.nz]
[10:43] aj_busy (ajmitch at p10-max7.dun.ihug.co.nz) joined #gstreamer.
[10:46] aj_busy (ajmitch at p10-max7.dun.ihug.co.nz) left irc: Ping timeout for aj_busy[p10-max7.dun.ihug.co.nz]
[10:47] aj_busy (ajmitch at p10-max7.dun.ihug.co.nz) joined #gstreamer.
[10:58] omega_ (omega at omegacs.net) left irc: sleep
[11:32] Nick change: maYam_sleep -> maYam
[11:34] aj_busy (ajmitch at p10-max7.dun.ihug.co.nz) left irc: Ping timeout for aj_busy[p10-max7.dun.ihug.co.nz]
[11:34] aj_busy (ajmitch at p10-max7.dun.ihug.co.nz) joined #gstreamer.
[11:47] thomas (thomas at 212-100-172-175.adsl.easynet.be) joined #gstreamer.
[11:48] aj_busy (ajmitch at p10-max7.dun.ihug.co.nz) left irc: Ping timeout for aj_busy[p10-max7.dun.ihug.co.nz]
[12:49] aj_busy (ajmitch at p10-max7.dun.ihug.co.nz) joined #gstreamer.
[15:03] taazzzz (dlehn at 66.37.66.32) got netsplit.
[15:03] matth-vacation (matth at qwest.dsplinux.net) got netsplit.
[15:03] thomas (thomas at 212-100-172-175.adsl.easynet.be) got netsplit.
[15:08] matth-vacation (matth at qwest.dsplinux.net) returned to #gstreamer.
[15:08] taazzzz (dlehn at 66.37.66.32) returned to #gstreamer.
[15:08] thomas (thomas at 212-100-172-175.adsl.easynet.be) returned to #gstreamer.
[17:11] Uraeus (cschalle at c224s9h5.upc.chello.no) joined #gstreamer.
[17:12] <Uraeus> Summer is HERE!!!
[18:00] Nick change: Uraeus -> Ura_summer
[18:26] Nick change: Ura_summer -> Uraeus
[18:52] hadess (hadess at pc121-gui14.cable.ntl.com) joined #gstreamer.
[18:52] <Uraeus> hi hadess
[18:52] <hadess> hey Uraeus
[18:54] <Uraeus> hadess: what parameters should I use when updating from Gstreamer CVS -pA ?
[18:54] <hadess> uhu
[18:54] <hadess> cvs upd -Pd
[18:54] <hadess> that's what i use
[18:54] <Uraeus> thanks
[19:10] ChiefHighwater (paul at temple-baptist.com) joined #gstreamer.
[19:10] <aj_busy> ello ;)
[19:13] <ChiefHighwater> hehe ello 8-]
[19:22] steveb (steveb at node1ee03.a2000.nl) joined #gstreamer.
[19:24] <ChiefHighwater> ello
[19:26] <steveb> hi
[19:33] thomas (thomas at 212-100-172-175.adsl.easynet.be) left irc: [x]chat
[19:52] Nick change: Uraeus -> Ura_gym
[19:54] omega_ (omega at omegacs.net) joined #gstreamer.
[19:58] <ChiefHighwater> Ello 8-]
[19:58] <omega_> yo
[20:15] hadess (hadess at pc121-gui14.cable.ntl.com) left irc: Ping timeout for hadess[pc121-gui14.cable.ntl.com]
[20:25] hadess (hadess at pc121-gui14.cable.ntl.com) joined #gstreamer.
[20:34] omega_ (omega at omegacs.net) left irc: Ping timeout for omega_[omegacs.net]
[20:36] thomas (thomas at adsl-64078.turboline.skynet.be) joined #gstreamer.
[20:36] <thomas> no one here ?
[20:37] <ChiefHighwater> ello 8-]
[20:37] <thomas> hi
[20:37] <thomas> where did everybody go ? must be the weather
[20:37] <ChiefHighwater> must be
[20:40] omega_ (omega at omegacs.net) joined #gstreamer.
[20:42] <thomas> hi omega
[20:42] <omega_> yo
[20:44] <thomas> omega_: I tried to debug the mixer today...
[20:44] <omega_> and?
[20:44] <thomas> ... and I found something I thought was weird.
[20:44] <omega_> surprise, surprise <g>
[20:44] <thomas> My initial thought was that the cothread switching that happened in the mixer...
[20:44] <thomas> ... was during iterates ...
[20:44] <thomas> ... but in fact it only iterates once
[20:44] <thomas> and enters infinite loop in that
[20:44] <omega_> oops
[20:45] <thomas> so the cothread switching basically jumps from element to element while trying
[20:45] <thomas> to get data to flow right ?
[20:45] <omega_> sorta, yeah
[20:45] <thomas> but it just jumps from volenv to mad to disksrc and back to volenv
[20:45] <omega_> hmm
[20:45] <thomas> as if the volenv sink is attached to the disksrc
[20:45] <thomas> not that it is of course
[20:45] <omega_> lemme see if it'll agree to autoplug for me this time
[20:46] <thomas> ok, go ahead...
[20:46] <thomas> I'll look for my debug output to show you, it's on my work machine
[20:46] <omega_> bleagh, it won't
[20:46] Action: omega_ smacks wtay-zZz around a little
[20:46] <thomas> I don't understand why... it should work.  What kind of errors does it give ?
[20:46] <omega_> could not autoplug, unknown media type...
[20:46] <thomas> do you have mad installed ?
[20:46] <omega_> of course
[20:47] Nick change: aj_busy -> ajmitch
[20:48] <steveb> ajmitch: yo
[20:48] <ajmitch> hi
[20:49] <thomas> omega_: what's your command line launching the mixer anyway ?
[20:49] <omega_> ./mixer a.mp3 b.mp3
[20:50] <thomas> Ok, so what if I change it again to static mp3 caps ?
[20:50] <omega_> static mp3 caps? how do you mean?
[20:50] <thomas> well, ditch the autoplug and just assume it's an mp3
[20:50] <thomas> and not work with ogg for now
[20:50] <thomas> the scheduling issue is far more important to me right now
[20:50] <omega_> maybe include a variant, don't ditch the existing one
[20:50] <thomas> ok
[20:51] <omega_> but yeah, create mixer-mp3.c or something
[20:52] Nick change: wtay-zZz -> wtay
[20:52] <wtay> hellowdy
[20:52] <omega_> hrm, that's a new one
[20:52] Action: wtay is eating ice cream
[20:52] <omega_> shouldn't it be: 'ellowdy 8-]'
[20:56] <wtay> It'll be interesting to write a new dynamic autoplugger...
[20:56] <thomas> if you have an element and you know it has only one source pad, how do you get it's name ?
[20:57] <omega_> yeah, I started thinking about the design of that last night, when deciding that the static autoplugger would be very hard to rev to the incsched stuff witout a goal in mind
[20:57] <omega_> thomas: hmmmm
[20:57] <omega_> that's a hole in the API
[20:57] <omega_> if you have any prefered way of doing it, let us know <g>
[20:57] <thomas> have a function or macro that checks the list of src pads connected ?
[20:58] <omega_> the only way to do it right now is gst_element_get_pad_list(element)->data;
[20:58] <omega_> yeah, some way of walking them, though I suppose it's best to just walk the list returned above
[20:58] <thomas> and then use the macro to check if it's a source or sink pad ?
[20:59] <omega_> yeah
[21:00] <thomas> I'm getting a core dump in the schedule stuff
[21:00] <thomas> 922       element->sched = chain->sched;
[21:00] <thomas> (gdb) bt
[21:00] <thomas> #0  0x4035b8ce in gst_schedule_chain_elements (sched=0x8070dd0, 
[21:00] <thomas>     element1=0x80e20f0, element2=0xe515) at gstscheduler.c:922
[21:00] Nick change: ajmitch -> ajbusy
[21:00] <thomas> is that the same error as yesterday ?
[21:01] <omega_> looks like it
[21:01] <omega_> but I can't reproduce it yet, so keep going <g>
[21:01] <thomas> OK, I'll rebuild from scratch then...
[21:01] <thomas> ... I'll put the mixer online as it is, it should work statically
[21:01] <thomas> then eat something first
[21:01] <omega_> ok
[21:02] <wtay> omega_: weird that your typedetection doesn't work...
[21:02] <omega_> yup
[21:03] <wtay> gstreamer-inspect mp3types was ok?
[21:03] <omega_> yup
[21:03] <omega_> autoplug fails same
[21:03] <thomas> ok, new mixer.c is in CVS
[21:04] <omega_> you didn't create a new one?
[21:05] <omega_> um, it works for me <g>
[21:05] <ChiefHighwater> it just likes you better 8-]
[21:05] <omega_> is it supposed to ping/pong between the tracks?
[21:07] <omega_> it started with one, faded out, faded the other in, and now one track is always running and the other fades in and out
[21:08] <wtay> lemme adjust it so it adds the same element autoplug does...
[21:11] <omega_> ok, just committed a megapatch for debug stuff
[21:11] <omega_> you'll want to rebuild all your plugins as well, though you don't have to yet
[21:11] <omega_> I don't think...
[21:11] <omega_> oh wait, yes you do
[21:11] <omega_> I changed the info_handler signature
[21:12] <hadess> could you try an "nslookup rhythmbox.org" guys ?
[21:12] <omega_> can't find, non-existant
[21:12] <hadess> ok
[21:12] <omega_> fwhois lists you
[21:13] <omega_> neither of your two nameservers have anything yet
[21:13] <hadess> hoho
[21:13] <hadess> omega_: what do you mean ?
[21:13] <omega_> dig @206.13.28.11 rhythmbox.org actually times out
[21:13] <omega_> the other one doesn't return any results
[21:14] <omega_> that's a bit long for the ns's not to have anything on you...
[21:14] <hadess> hmmm
[21:14] <hadess> it was setup yesterday only
[21:15] <omega_> ok
[21:15] <omega_> octobrx is ns'ing for you?
[21:15] <hadess> yep
[21:15] <omega_> he isn't set up yet then...
[21:15] Action: omega_ watches hadess go to #gnome
[21:16] <hadess> no, i go to #lcft =)
[21:16] <Ura_gym> hmm, I am unable to build gstreamer due to some lacking gnome-stuff, weird
[21:17] Nick change: Ura_gym -> Uraeus
[21:17] <wtay> hi Uraeus, hadess, etc..
[21:17] <hadess> hey wtay
[21:17] <Uraeus> hi wtay
[21:17] <wtay> omega_: weird , now it works...
[21:24] <taazzzz> so how big is that incsched->head patch now? ;)
[21:24] jelle (jelle at rlanarh114.uni-c.dk) joined #gstreamer.
[21:24] <omega_> not big, since I've done two upwards merges already
[21:25] <omega_> the final merge will be a freeze of both, merge up, merge down
[21:25] <thomas> ok, I'm back...
[21:25] <thomas> seems the static case works
[21:25] <omega_> but it will be interesting to do a diff -u | wc between incsched and head
[21:25] <omega_> hmmm
[21:25] <omega_> ok, that doesn't surprise me
[21:25] <omega_> yo jelle
[21:25] <taazzzz> well, that's what i meant
[21:25] <thomas> omega_: yeah, it's supposed to ping pong between tracks
[21:25] <omega_> right, ok, /me hides
[21:26] <omega_> thomas: is is supposed to leave one track going all the time?
[21:26] Nick change: taazzzz -> taaz
[21:26] <thomas> omega_: no, the end result is a mix of the two (or more) at the same time
[21:26] <omega_> ok
[21:26] <thomas> you start with the first,
[21:26] <thomas> it fades out to the second
[21:26] <thomas> and then the first comes back
[21:26] <thomas> you can also mix more
[21:26] <thomas> just as a demo
[21:27] <thomas> which begs the interesting question: why is it that the fact that it used autoplug caused the iterating not to work ?
[21:27] <omega_> because autoplug does something that kills the scheduler
[21:28] <omega_> I'm not sure what, but that's the $64e3 question
[21:28] <thomas> ok, could it be that the chains aren't calculated right ?
[21:28] <thomas> Here's some debug info I got today :
[21:28] <omega_> at the core, yes
[21:28] <Uraeus> omega_: will you let me know when you fix the XFree dependency Gman reported so I can badger him to try compiling again :)
[21:28] <thomas> I was following through all of the info and at a certain point it said it had 3 chains in the sched...
[21:28] <thomas> ... then this ...
[21:28] <thomas> INFO (17564: 0)gst_schedule_chain_remove_element
[21:29] <thomas> :963: removing element "mad" from chain 0x80a2518
[21:29] <thomas> INFO (17564: 0)gst_schedule_chain_destroy:904:
[21:29] <thomas> 0m destroying chain 0x80a2518
[21:29] <thomas> INFO (17564: 0)gst_schedule_chain_new:896: c
[21:29] <thomas> reated new chain 0x80a2518, now are 4 chains in sched 0x8085048
[21:29] <thomas> INFO (17564: 0)gst_schedule_chain_add_element:91
[21:29] <thomas> 9: adding element "mad" to chain 0x80a2518
[21:29] <hadess> omega_: marius forgot the dns, that's why it doesn't work :)
[21:29] <thomas> I would think that the schedule_chain_destroy would decrease the number of chains, no ?
[21:29] <omega_> eek, there shouldn't be that many chains in the normal case
[21:29] <wtay> omega_: I'm looking what autoplug does to mess up things...
[21:29] <thomas> omega_: ok, is there more debug info that would be useful ?
[21:29] <thomas> I have the log
[21:29] <omega_> wtay: I'm gonna try to quickly write up what I think a dynamic autoplugger would do
[21:30] <wtay> omega_: ok
[21:30] <omega_> thomas: there is nothing more than what --gst-mask=-1 does...
[21:30] <thomas> yeah, but I can give you the previous chain creations if they're there, right ?
[21:30] <thomas> Maybe that tells you why there are too much
[21:30] <omega_> unlikely that'll tell me something wtay can't figure out, but if you want to email me the log, go for it
[21:31] <thomas> I can mail it to wtay if he's better suited ;)
[21:31] <omega_> probably is <g>
[21:31] <wtay> uh
[21:31] <thomas> BTW here's another error I got for all of the elements
[21:31] <thomas> DEBUG(17564: 0)gst_schedule_cothreaded_chain:310: set wrapper func
[21:31] <thomas> tion for 'mixer' to &
[21:31] <thomas> it should print the wrapper function after the & but it doesn't
[21:31] <omega_> hmm, checking
[21:32] <thomas> the %s is there in the source
[21:32] <omega_> interesting
[21:32] <hadess> Uraeus: http://rhythmbox.org/ <- tada !
[21:32] <wtay> oh!
[21:33] <omega_> 'Nothing there yet...'
[21:33] Action: omega_ is amazed at hadess' new web page
[21:33] <Uraeus> incredible :)
[21:33] <hadess> lol
[21:33] <thomas> looks great in lynx
[21:34] <omega_> I'm gonna revert to having the funcptr stuff storing in a hash
[21:34] Action: omega_ hands hadess a 'works great in all browsers' button
[21:37] <hadess> wahoo, check the stats: http://www.rhythmbox.org/stats/
[21:37] <omega_> neat
[21:38] <omega_> you're, um, popular
[21:38] Action: hadess should stop being stupid =)
[21:38] <hadess> omega_: lol
[21:38] <hadess> omega_: hadess.net/stats should more than 1/2 million hits, which is better
[21:39] <thomas> hmmm.. I changed the mixer to delay the second channel... but it seems that the function gst_bin_iterate doesn't return after one iteration
[21:39] <thomas> but it keeps on playing anyway...
[21:39] <omega_> are you using any threads?
[21:40] <thomas> no
[21:40] <Uraeus> omega_: are you looking into the XFree problem?
[21:41] <omega_> Uraeus: right now? no
[21:41] <omega_> but wtay should, since it's his dependency <g>
[21:41] <Uraeus> wtay!!!
[21:41] <Uraeus> :)
[21:41] <wtay> problem?
[21:41] <ChiefHighwater> umm...just glancing at the GStreamer page...should we maybe remove/change the "NEWSFLASH....tonight" that is a month old today?
[21:41] <omega_> um, true <g>
[21:41] Action: omega_ goes to fix tha
[21:42] <omega_> what's the latest news?
[21:42] <Uraeus> wtay: yes, you have to remove the XFree dependency so Gman can compile Gstreamer under Solaris
[21:42] <Uraeus> wtay: they don't use Xfree
[21:42] <omega_> or at least make it possible to run without xfree extensions
[21:42] Nick change: ajbusy -> ajmitch
[21:42] <thomas> omega_: is gst_bin_iterate supposed to return when a block of data has been passed from the first element to the last ?
[21:43] <wtay> sounds like a good idea
[21:43] <omega_> basically, yes
[21:43] <omega_> but it depends heavily on a number of things
[21:43] <Uraeus> wtay: let me know when/if you are fixing the problem and I get Gman to try compiling again
[21:44] <wtay> Uraeus: ok
[21:44] <Uraeus> then we can announce Solaris support in 0.2.0 :)
[21:44] <omega_> Uraeus: hehe
[21:44] <thomas> omega_: hmmm, ok.  Can I *force* a return to main from one of the plugins for now ?
[21:45] <omega_> how do you mean? when?
[21:47] <thomas> omega_: two ways
[21:47] <thomas> either hack it in an ugly way by using a global for now
[21:47] <omega_> no, I mean: why do you want to that?
[21:48] <thomas> oh...
[21:48] <thomas> well right now there's no way to add the second channel from the main program after a few seconds...
[21:48] <thomas> ... since it doesn't return there
[21:48] <omega_> it doesnt?
[21:49] <omega_> interesting
[21:50] <wtay> omega_: I have found the problem...
[21:50] <omega_> so, there are some interesting debugging things you can do
[21:50] <omega_> I'll commit them in a sec
[21:50] <omega_> the autoplug problem?
[21:50] <wtay> yes
[21:51] <wtay> lemme explain what I do...
[21:51] <omega_> thomas: committed
[21:52] <wtay> 1. create a GstBin, add disksrc, typefind in it, add that bin to a pipeline and _iterate once.
[21:52] <wtay> 2. remove the bin from the pipeline and add it to the other pipeline
[21:52] <wtay> 3. scheduling fails
[21:52] <omega_> ok
[21:52] <omega_> where are the state changes in this?
[21:52] <wtay> I'll commit my mixer changes
[21:53] <wtay> the autoplug pipeline is set to PLAYING and then to NULL
[21:53] <omega_> is this why the autoplugger fails to typefind on my machine, or something else?
[21:53] <wtay> that's something else
[21:53] <omega_> ok, do you need access to my laptop to check into that?
[21:53] <thomas> omega_: what exactly did you commit...
[21:53] <omega_> mixer.c
[21:54] <thomas> ... and what's the command to integrate the cvs version with the changes I made myself here
[21:54] <wtay> I have a version with typefind (ignore the result) and set up the same bin as autoplug would have done
[21:54] <omega_> cvs update -dP
[21:54] <omega_> wtay: you have an account on omegacs.net again, username=passwd, reset ASAP
[21:55] <omega_> once there, telnet to omicron, same passwd, change that one too
[21:55] <wtay> omega_: ok
[21:56] <omega_> Lame server on 'ns1.chello.at'
[21:56] Action: omega_ doesn't know what the definition of a 'lame server' is, though
[21:57] <Uraeus> ok, Frederic says he is willing to do the icons for us, but he needs some good ideas, anyone got any?
[21:58] <omega_> heh, depends on what the icons are for
[21:58] Action: hadess logs in omega_'s puter
[21:58] <wtay> hadess: nope :-)
[21:58] <hadess> damn
[21:58] <omega_> hadess is too slow
[21:58] <hadess> too slow :P
[21:59] <thomas> omega_: ok, now it prints the schedule and chains...
[21:59] <thomas> schedule has 5 elements, one chain
[21:59] <thomas> seems ok
[21:59] <thomas> but still only executes iterate once and never returns
[21:59] <omega_> 5 elements? that's with only one file, right?
[21:59] Action: wtay allready has root access
[21:59] <thomas> riht
[21:59] <thomas> right
[21:59] <thomas> schedule has 5 elements in it: mp3decode, volenv1, disksrc1, play_audio, adderel
[21:59] <wtay> allow me to screw up mixer.c again to show you the problem
[22:00] <thomas> wtay: can I commit it back first ?
[22:00] <omega_> wtay: gimme a sec to set up groups
[22:01] <wtay> thomas: sure, I added a WITH_BUG define to trigger it...
[22:01] <omega_> ok, newgrp to 'gst'
[22:01] <omega_> ~/gst.incsched1/...
[22:02] <Uraeus> omega_:the icons are for gstmediaplay and the editor
[22:02] <omega_> right
[22:02] <Uraeus> do we have any other apps?
[22:03] <omega_> nothing graphical
[22:03] <thomas> wtay: ok, I committed it, go ahead
[22:03] <thomas> wtay: btw you do the autoplug by doing one iteration of the bin so that caps are detected, right ?
[22:03] <wtay> thomas: yup
[22:03] <thomas> so if it's a stream input, you can't go back in the disksrc
[22:04] <thomas> do you actually lose one buffer or is there a way of putting it back ?
[22:04] <wtay> thomas: typefind should buffer things
[22:07] <omega_> wtay: I just updated mixer.c from cvs
[22:07] <omega_> are you working on it
[22:07] <omega_> ?
[22:10] <wtay> omega_: yes
[22:10] <omega_> ok, I'll leave it alone
[22:10] <omega_> should I kill esd and let you run your own?
[22:11] <wtay> omega_: check out what I'm doing wrong with the typefind
[22:11] <omega_> which?
[22:11] <wtay> I'll try to find out why the typefind doesn't work on your machine
[22:11] <thomas> omega_: while going through the debug output I was thinking two things :
[22:11] <wtay> omega_: in mixer.c (uncomment WITH_BUG)
[22:11] <thomas> a) is there a way to turn the colors off ?
[22:12] <omega_> thomas: at compile time, yes, I will add a way to turn them off at run-time
[22:12] <thomas> b) wouldn't a tree-based system be nice, so that you can see what function is calling what...
[22:12] <omega_> wtay: run it?
[22:12] <thomas> ... and so that you can quickly eliminate some trees that you know are right ?
[22:12] <wtay> sec.. phone call
[22:12] <omega_> thomas: yes, it would
[22:13] <wtay> omega_: yup, with the define uncommented, to see the lockup
[22:13] <omega_> with it #undef'd, I get a core
[22:14] <omega_> #0  0x40355673 in gst_caps_check_compatibility_func (fromcaps=0xffb0e900, tocaps=0x8073268) at gstcaps.c:478
[22:14] <omega_> 478	  if (fromcaps->id != tocaps->id) {
[22:14] <omega_> (gdb) bt
[22:14] <omega_> #0  0x40355673 in gst_caps_check_compatibility_func (fromcaps=0xffb0e900, tocaps=0x8073268) at gstcaps.c:478
[22:15] <wtay> wow
[22:17] <wtay> omega_: I get the feeling something is wrong with your build...
[22:17] <omega_> ok, I'll make clean
[22:18] <omega_> building
[22:18] <thomas> omega_: I suppose that if we want tree-based debug output, we need a global "depth" and have each function call increment or decrement that ?
[22:18] <thomas> or is that too clumsy ?
[22:19] <wtay> omega_: building in ~/gst.incsched1/?
[22:21] <omega_> yes
[22:21] <omega_> thomas: right
[22:21] <thomas> omega_: right as in that's the way or as in "too clumsy" ?
[22:22] steveb (steveb at node1ee03.a2000.nl) left irc: [x]chat
[22:22] <omega_> thomas: it's the only way I can think of
[22:23] <omega_> taaz's comment that we might do I and D and E instead of INFO and DEBUG and such
[22:23] <omega_> that would shorten the lines, make them the same width, and make treeing easier
[22:23] <omega_> the biggest problem with treeing is that we need a depth variable for each and every cothread
[22:23] <omega_> but if there are no cothreads, we have to have one for the thread
[22:23] <omega_> so it gets hairy
[22:24] <Uraeus> omega_: if you are interested in doing the asm coding for PA-Risc so can I probable get someone to test it for us
[22:24] <wtay> brb
[22:25] <omega_> Uraeus: the question is: can you get someone to do the asm coding for the PA-Risc <g>
[22:25] <Uraeus> omega_: don't think so, but you could maybe do it blind like the Sparc one :)
[22:25] <omega_> Uraeus: um <g>
[22:25] <omega_> I suppose...
[22:26] <Uraeus> I am asking boc about the asm coding part now, will be interesting to see his reply :)
[22:26] <omega_> heh
[22:30] Nick change: maYam -> half-maYam
[22:32] <thomas> omega_: hmmm... why do you need a depth variable for each cothread ? functions return to the cothread's switcher level before the cothread switcher can do the switch, no ?
[22:32] <omega_> no, they can switch from any point, that's the idea
[22:32] <omega_> if they always landed at depth 0 before switch, there'd be no point in doing cothreads
[22:32] <thomas> true, sorry
[22:33] Action: omega_ will look into the most efficient way to do this
[22:38] <Uraeus> omega_: boc was completly blank on asm coding, but he was willing to be our PA-Sparc compiler :)
[22:39] <omega_> heheh
[22:39] Nick change: omega_ -> omega_lunch
[22:45] jelle (jelle at rlanarh114.uni-c.dk) left irc: Snakkes
[22:47] <thomas> wtay: still there
[22:47] <thomas> ?
[22:47] <wtay> yup
[22:47] <omega_lunch> wtay: now a fault somewhere else in caps
[22:47] <omega_lunch> #0  0x403556d3 in gst_caps_check_compatibility_func (fromcaps=0xffb0e900, tocaps=0x8073268) at gstcaps.c:478
[22:47] <omega_lunch> 478	  if (fromcaps->id != tocaps->id) {
[22:47] <wtay> omega_lunch: yeah, I'm on it..
[22:48] <thomas> your mixer doesn't work ;)
[22:48] <thomas> but what are you trying to show ?
[22:48] <wtay> thomas: good :)
[22:48] <thomas> it does the same kind of cothread jumping I had today as well
[22:49] <wtay> thomas: undef WITH_BUG and AUTOPLUG
[22:50] <thomas> yes, then it works...
[22:50] <thomas> ...but what is it that you're trying to show with the bug ?
[22:51] <wtay> thomas: how the typefind pipeline screws up the ohter pipelines scheduling
[22:51] <thomas> wtay: ok, what you're saying is there's no reason for that, so it needs fixing on a different level, right ?
[22:51] <wtay> yup
[22:52] <thomas> ok, I'll leave that part at that then.
[22:52] <thomas> still leaves the bin_iterate problem
[22:53] <thomas> would it be better if I put everything separately in threads ?
[22:53] <wtay> for performance reasons, yes
[22:53] <omega_lunch> evnetually, yes, but not for debugging purposes
[22:53] <wtay> omega_lunch: typefind can't detect the mp3 you have there :)
[22:53] <omega_lunch> hmm
[22:53] <wtay> omega_lunch: doesn't start with FFE etc...
[22:54] <thomas> ok, I'll try and make a thread-based one tomorrow
[22:54] <thomas> omega_lunch: do you have ID3v2 tags ?
[22:54] <thomas> or level 1 ?
[22:54] <omega_lunch> probably
[22:54] <omega_lunch> works fine with -launch
[22:54] <wtay> omega_lunch: sure, it doesn't use typefind
[22:55] <thomas> so basically, that means that the mp3 decoder plugin can't determine the data type...
[22:55] <thomas> ... from the first buffer of data ?
[22:55] <wtay> yes
[22:55] <omega_lunch> so it seems, which would be odd
[22:55] <thomas> omega_lunch: why ?
[22:55] <omega_lunch> the id3 data starts only after the first frame
[22:55] <wtay> it's a pretty lame typefind function...
[22:55] <thomas> omega_lunch: not in id3 level 2
[22:55] <omega_lunch> v2 it starts at the very very end of the file, afaict
[22:55] <wtay> od -h shows you what is wrong...
[22:55] <thomas> I thought v2 started at the beginning...
[22:55] <thomas> hang on, I'll check
[22:56] <omega_lunch> hmmmm, it seems that it doesn't always
[22:57] <wtay> omega_lunch: anyway I fixed up mixer too, which caused the segfault (WITH_BUG and AUTOPLUG must always be undef'ed at the same time)
[22:57] <omega_lunch> hmm, ok
[22:57] <omega_lunch> the first farme starts at offset 0x1060, afaict
[22:57] <wtay> yup
[22:58] <omega_lunch> ok, it finds the type of some matrix mp3s
[22:58] <omega_lunch> but doesn't output any audio
[22:58] <wtay> make that 1720
[22:59] <wtay> cpu 100%?
[22:59] <omega_lunch> yes
[22:59] <wtay> ok, that's the bug then
[23:00] <wtay> now undef AUTOPLUG to rule out the autoplugger
[23:00] Action: wtay is used to press <esc>k on remote shells
[23:00] <thomas> from the id3 tech guide :
[23:00] <thomas> 5.   Tag location
[23:00] <thomas>    The default location of an ID3v2 tag is prepended to the audio so
[23:00] <thomas>    that players can benefit from the information when the data is
[23:00] <thomas>    streamed. It is however possible to append the tag, or make a
[23:00] <thomas>    prepend/append combination. When deciding upon where an unembedded
[23:00] <thomas>    tag should be located, the following order of preference SHOULD be
[23:00] <thomas>    considered.
[23:00] <omega_lunch> ick, ok
[23:00] <omega_lunch> that makes life easier in some cases, though
[23:00] <thomas> since the id3 tag can grow to 256 MB (what were they thinking ?) ...
[23:01] Action: omega_lunch has some of each somewhere
[23:01] Nick change: omega_lunch -> omeag_
[23:01] Nick change: omeag_ -> omega_
[23:01] <thomas> ... the typefinder should probably continue trying until caps are set
[23:01] <thomas> or is that too demanding ?
[23:01] <wtay> no, that's the idea
[23:01] <wtay> not implemented yet though...
[23:01] <thomas> wtay: can the mp3 decoder ask the disksrc to fast-forward to a point ?
[23:02] <thomas> without knowing that it's a disksrc, that is
[23:02] <wtay> yes
[23:02] <omega_> not yet
[23:02] <omega_> effectively, at least
[23:02] <wtay> well theoretically
[23:02] <thomas> ... but you could insert an id3v2 plugin ...
[23:02] <wtay> using _pull_region
[23:02] <thomas> ... which would basically when set to play ...
[23:02] <omega_> wtay: which will go away soon
[23:02] <thomas> ... request enough data to get there
[23:03] <thomas> and then pass through
[23:03] <wtay> omega_: hmm
[23:03] <omega_> event system will replace it somehow
[23:03] <omega_> so, I turn off with_bug and autoplug and the thing 'works'
[23:03] <wtay> omega_: yup, with_bug does the little typefind pipeline first
[23:04] <wtay> you can also turn off autoplug and leave the with_bug def and it'll lock again
[23:04] <thomas> omega_: does it stay in the first iteration as well ?
[23:04] <omega_> hmm
[23:04] <omega_> yes
[23:05] <omega_> um, in the debugger it gets a sigusr1
[23:05] <wtay> so the typefind pipeline is the key..
[23:05] <thomas> is sigusr1 set in gstreamer ?
[23:05] <thomas> as what ?
[23:05] <omega_> it seems to livelock
[23:06] <omega_> thomas: no idea where that comes from, but it is used by the pthread system
[23:06] <omega_> but you're not doing pthreads, so....
[23:06] <omega_> and it didn't happen the second time
[23:06] <thomas> could be esd... I sometimes have to break and restart gstreamer for that as well
[23:06] <thomas> only at startup
[23:07] <omega_> it seems to get stuck in 'registering volume envelope' for some number of seconds sometimes
[23:07] <omega_> and it only seems to play a single mp3, even though I have two on the cmdline
[23:08] <thomas> it doesn't fade the first one out and the second in after ten secs ?
[23:08] <omega_> it doesn't have a second mad
[23:08] <thomas> no hang on, that's the changed version.
[23:08] <thomas> right now it does only play the first one
[23:08] <thomas> the second one should be connected after a few bin_iterates
[23:08] <omega_> ok
[23:08] <omega_> the livelock is interesting
[23:08] <thomas> that's the problem actually ;)
[23:09] <thomas> as for why it would seem to get stuck in registering envelope...
[23:09] hehehehe (trevo at 208.141.162.68) joined #gstreamer.
[23:09] <thomas> the registering isn't the problem, that's pretty fast...
[23:09] <thomas> ... then it does an xml save which should be ok as well ...
[23:09] <thomas> ... but then you have the start_playing
[23:09] <thomas> that's probably where it hangs
[23:10] <thomas> sometimes when it hangs here, with debug-info, it's hanging in esdsink, trying to connect to esd
[23:11] omega_ (omega at omegacs.net) left irc: Read error to omega_[omegacs.net]: No route to host
[23:11] omega_ (omega at omegacs.net) joined #gstreamer.
[23:11] <omega_> grrrrr
[23:12] <omega_> ximian 1.4 thoroughly mangled my entire environment
[23:12] Action: omega_ will be back in a few minutes
[23:12] omega_ (omega at omegacs.net) left irc: [x]chat
[23:17] omega_ (omega at omegacs.net) joined #gstreamer.
[23:18] <omega_> stupid session stuff
[23:18] <omega_> great, and now xchat doesn't do what it used t
[23:19] <omega_> bleagh
[23:20] <omega_> all my settings where completely blown away, and now I have to figure out why my .xsession is now ignored
[23:20] <omega_> gdmconfig faults horribly
[23:22] <omega_> ping?
[23:22] <thomas>  /me is trying to hack that cool windowmaker desktop title effect out of the source
[23:23] <thomas> heh, i hate my spacebar
[23:23] Nick change: half-maYam -> maYam
[23:23] <maYam> lo everyone
[23:23] <thomas> hi
[23:24] <omega_> great.  'Xsession' is now different from GNOME
[23:24] <omega_> and thus I have to potentially lose functionality in order to get my ssh-agent stuff working again
[23:26] <thomas> hmmm... anyone good at X programming in C ?
[23:26] <omega_> um
[23:28] <ChiefHighwater> brb
[23:28] ChiefHighwater (paul at temple-baptist.com) left irc: 
[23:30] <omega_> ok, utsl gave me what the docs didn't, lemme give this a try
[23:30] omega_ (omega at omegacs.net) left irc: [x]chat
[23:30] ChiefHighwater (paul at temple-baptist.com) joined #gstreamer.
[23:32] omega_ (omega at omegacs.net) joined #gstreamer.
[23:32] <omega_> um, somewhat better
[23:38] <omega_> someone say something? I'm narrowing down a bug report for xchat
[23:38] <wtay> howdy
[23:38] <omega_> ok, thanx
[23:38] <wtay> what's wrong?
[23:38] Action: thomas is being called to bed
[23:39] <thomas> gf's and programming don't mix
[23:39] <omega_> during exposes, the timestamp and the nick both get drawn on top of each other
[23:39] <wtay> thomas: why not?
[23:39] <thomas> gf's don't always like programming
[23:39] <thomas> ;)
[23:39] <omega_> oops
[23:39] <wtay> omega_: ok, I think that's a feature not a bug
[23:39] <omega_> hardly
[23:39] <wtay> omega_: you can turn that off somewhere...
[23:40] <thomas> omega_: now I have that too
[23:40] <thomas> doesn't it re-adjust itself as soon as you type something yourself ?
[23:40] <omega_> temple-baptist.com/~omega/xchat-bug.png
[23:41] <omega_> thomas: yes, but there's still a bug
[23:41] <wtay> looks familiar
[23:41] <omega_> and it's switching colors and bold and all that on the nicks somewhat randomly
[23:41] <wtay> if you can get rid of that bar, it's fixed..
[23:41] <omega_> eh?
[23:42] <wtay> it's an option somewhere..
[23:42] <thomas> the color change is only when someone addresses you directly, right ?
[23:42] <omega_> no, it depends on any number of things
[23:42] <omega_> for isntance, all of wtay's messages were bold yellow
[23:43] <omega_> the last two were not bold
[23:43] <omega_> they switched to bold at some point retroactively
[23:43] <omega_> I hit page up, page down, and suddenly they weren't bold anymore
[23:43] <wtay> hmm, ok that's a bug
[23:43] <omega_> I should say so...
[23:44] <maYam> it's a feature, not a bug
[23:44] <maYam> pff
[23:44] <wtay> maYam: I remember you complaining about it 'till I turned of that feature..
[23:44] <omega_> which feature?
[23:44] <thomas> wtay: on the other hand, maybe a supportive GF is nice ;)
[23:45] <wtay> time/nick overlap feature
[23:45] <omega_> where is that option?
[23:46] <hehehehe> can anyone tell me if I grab gstreamer head from cvs, will it compile and work on redhat 7.1
[23:46] <wtay> omega_: good quetion, I played a bit with the toggle buttons..
[23:46] <omega_> compile: probably. work: probably not <g>
[23:46] <ajmitch> is gstreamer meant to work?
[23:46] <omega_> ajmitch: um, yeah.
[23:46] <Uraeus> hehehehe: don't think so, you probably get the same compile troubles I do(se latest mail in archive)
[23:46] <ajmitch> omega_: wow ;)
[23:47] <hehehehe> Uraeus: yeah, that is why I asked
[23:47] <ajmitch> omega_: i suppose, i recall using it quite awhile ago to play some divx avis at really slow speed ;)
[23:48] <Uraeus> hehehehe: guess we have to wait a day or so until someone takes pity on us and fixes the problem :)
[23:48] <hehehehe> Uraeus: why do you say a day or so, or where you just saying we have to wait :)
[23:49] <Uraeus> hehehehe: well, cause the gstreamer hackers are usually pretty fast at fixing stuff
[23:49] <wtay> Uraeus: your problem is related to docs, which are not very easy to build...
[23:49] <hehehehe> Uraeus: Gotcha
[23:49] <hehehehe> anyway, gotta go
[23:49] hehehehe (trevo at 208.141.162.68) left irc: Client Exiting
[23:49] <Uraeus> wtay: so how do I avoid the docs?
[23:50] <Uraeus> configure --nodocs?
[23:50] <wtay> uhm
[23:50] <omega_> --disable-docs-build
[23:50] <wtay>  --disable-docs-build 
[23:50] <wtay> right
[23:50] <Uraeus> if the docs build is buggy, maybe having it disabled should be the default
[23:50] <omega_> I was thinking that a while ago, yeah
[23:51] <wtay> makes sense
[23:53] <Uraeus> more people than me are having build problems: http://www.gnome.org/~michael/
[23:53] <wtay> Uraeus: anyway, docs are built at the end, so everything should work fine...
[23:53] <Uraeus> :)
[23:53] Action: omega_ is trying to build an rpm of the xchat-1.7.3 tarball
[23:54] <Uraeus> wtay: well problem is that non-hackers like myself asume the whole thing went south and didn't even try :)
[23:54] <wtay> ohh 1.7.3
[23:54] <wtay> Uraeus: yes, not very nice..
[23:54] <omega_> removing the separator bar does nothing to fix the bug
[23:58] <maYam> Uraeus: not a hacker?  shame on you!
[23:58] <maYam> kick him!
[23:59] <thomas> maYam: sorry, ran out of stones to throw yesterday
[23:59] <ajmitch> can't do that, they'd lose all the free publicity ;)
[23:59] <Uraeus> maYam: I am sorry, but my parents forced me to play soccer as a child when I could have learned to code :)
[23:59] <ajmitch> maYam: you are a hacker?
[23:59] #gstreamer: mode change '+o wtay' by ChanServ!s at ChanServ
[23:59] maYam kicked from #gstreamer by wtay: maYam
[23:59] #gstreamer: mode change '-o wtay' by ChanServ!s at ChanServ
[00:00] --- Thu May  3 2001
[00:00] <wtay> hehehe
[00:00] <ajmitch> nasty ;)
[00:00] <Uraeus> <g>
[00:00] <ajmitch> how far away from her are you?
[00:00] <Uraeus> wtay: does that count as domestic violence :)
[00:00] <wtay> ajmitch: getting closer...
[00:00] <omega_> heheh
[00:00] Action: wtay is kicked for real
[00:01] <ajmitch> lol
[00:01] <omega_> hrm, is that proof that virtual violence leads to real violence then?
[00:01] maYam (mayam at cable-195-162-214-190.upc.chello.be) joined #gstreamer.
[00:01] <ajmitch> wb, maYam
[00:01] <maYam> aah.. true love..
[00:01] <Uraeus> :)
[00:01] <wtay> maYam: sorry 'bout that... couldn't resist...
[00:01] Action: omega_ wants a webcam installed over there...
[00:01] <ajmitch> lol
[00:02] <Uraeus> you like violent movies omega_?
[00:02] <ajmitch> omega_: could you handle some of those scenes? ;)
[00:02] <omega_> depends
[00:02] <maYam> lol
[00:02] <omega_> ajmitch: um, right. nevermind then.
[00:02] <maYam> there's a fine line between pain and pleasure
[00:02] <wtay> rotfl
[00:02] <omega_> oooh, 1.7.3-1 is older than 1.6.4-ximian.1 !
[00:03] <wtay> hmm, I didn't know 1.7.3 was out..
[00:03] Action: omega_ will brb with 1.7.3
[00:03] omega_ (omega at omegacs.net) left irc: [x]chat
[00:03] omega_ (omega at omegacs.net) joined #gstreamer.
[00:03] <omega_> hrm, let's try this again
[00:04] <omega_> nope, same problem still
[00:04] <Uraeus> omega_: you could make set of IRC plugins for GStreamer :)
[00:04] <omega_> um, such as?
[00:04] Action: maYam presents Belgian snuff movies: coming soon
[00:05] Action: omega_ hints wtay to run
[00:05] <Uraeus> omega_: such who works like you want em to work
[00:05] <maYam> damn..  cam battery empty..
[00:05] Action: omega_ suggests to wtay that he hide the power adaptor
[00:06] <ajmitch> hehe
[00:06] Action: Uraeus suggests that wtay fix all bugs today since he might not be here tommorow
[00:06] <maYam> i'll glue that ear back on and film it another time
[00:06] Action: ajmitch knows why wtay wanted to get that mpeg encoding going properly
[00:06] <omega_> erm
[00:06] Action: wtay makes a lot of money on his home made snuff movies
[00:08] <wtay> i'm so stupid
[00:08] <wtay> maYam is such a wonderful person
[00:08] <Uraeus> hmm, gstmediaplay doesn't work for me anymore, crashed when I try to play movies and mp3's are simply silent
[00:08] <wtay> and intelligent
[00:09] <wtay> actually, she programmed everything, not me
[00:09] <Uraeus> ok, night everyone
[00:09] Uraeus (cschalle at c224s9h5.upc.chello.no) left irc: syntax error - user imploded
[00:09] Action: omega_ begs for a floppy
[00:10] <ajmitch> wtay: what's maYam doing to you now? ;)
[00:10] <wtay> hmm, left the kb for a moment
[00:13] Action: omega_ runs memtest-2.5 on some new RAM
[00:14] <omega_> it claims 7500MB/sec L1 and L2 speed, 18.5MB/sec RAM speed
[00:14] Action: wtay notes that he didn't type the above nonsense...
[00:14] <ajmitch> ;)
[00:14] Action: omega_ takes the handcuffs away from maYam so wtay can get some work done
[00:14] Action: wtay is writing more manual pages..
[00:15] Action: ajmitch is hitting head and writing lab report :(
[00:15] <ajmitch> damn, it's due this afternoon, i only started it at 2am ;)
[00:16] <omega_> whoops
[00:16] <wtay> ajmitch: hmm, good luck :)
[00:16] <maYam> omega_: hey hey i'm just minding my own business again, making galeon crash etc
[00:16] <ajmitch> heh, nearly finished, i still got a couple of hours ;)
[00:16] <omega_> ajmitch: remember the 90/10 rule....
[00:16] <thomas> right, i'm off to bed as well
[00:17] <omega_> thomas: ok, l8r
[00:17] <thomas> omega_: do you think the problem is fixable ?
[00:17] <ajmitch> omega_: 90% caffiene, 10% blood? ;)
[00:17] <omega_> as soon as I can figure out what it was again (my machine locked, which is why I had such fun with ximian)
[00:17] <maYam> bye thomas
[00:17] <omega_> ajmitch: um, no, the other 90/10 rule
[00:17] <thomas> bye all
[00:17] <omega_> l8r
[00:18] <thomas> omega_: ok I'll just check the logs tomorrow to see if you could find it
[00:18] <wtay> thomas: cya
[00:18] thomas (thomas at adsl-64078.turboline.skynet.be) left irc: Client Exiting
[00:18] <ajmitch> oh
[00:18] <hadess> back
[00:18] <omega_> uh??
[00:18] <omega_> [omega at omicron gst.incsched1]$ ./tools/gstreamer-register 
[00:18] <omega_> INFO ( 4942:-1) setting INFO categories to 0x00020001
[00:18] <omega_> INFO ( 4942:-1) Initializing GStreamer Core Library
[00:18] <omega_> Gtk-WARNING **: This process is currently running setuid or setgid.
[00:18] <omega_> This is not a supported use of GTK+. You must create a helper
[00:18] <omega_> program instead. For further details, see:
[00:19] <ajmitch> omega_: which one? ;)
[00:19] <wtay> omega_: yup, new gtk cannot run as run...
[00:19] <wtay> s/run/root
[00:19] <ajmitch> hi hadess
[00:19] <omega_> it's not root.  it's setgid by accident, gid is 'gst'
[00:19] <ajmitch> heh
[00:19] <omega_> find gst gst.incsched1/ -type f | xargs chmod g-s
[00:20] <omega_> fixed
[00:22] <hadess> hey ajmitch
[00:23] #gstreamer: mode change '+o omega_' by ChanServ!s at ChanServ
[00:23] #gstreamer: mode change '-o omega_' by omega_!omega at omegacs.net
[00:23] Action: omega_ is testing the xchat counters
[00:24] <hadess> http://home.t-online.de/home/t.walther/linux.jpg <- hehe
[00:24] <omega_> oh man
[00:25] <maYam> off-topic (what else? it's coming from me) question for all americans: $25 for an album is expensive, right?
[00:25] <omega_> yes
[00:25] <maYam> ah, i thought so..
[00:25] <ajmitch> yes
[00:25] <maYam> fortunately i'm using wtay's credit card!
[00:25] <omega_> doh
[00:25] <ajmitch> quite...
[00:26] <maYam> cdnow.com is pretending it's cheap.. tisk tisk
[00:27] <wtay> make that a $10/$15 here in Belgium...
[00:27] <ajmitch> this for a cd?
[00:27] <maYam> hmm.. nono wtay, $18!
[00:28] <wtay> hm ok
[00:28] <wtay> nice price ones are cheaper though..
[00:28] <ajmitch> wtay: don't worry, you can trust maYam with your credit card ;)
[00:28] <maYam> heheh.. 'thanks' ajmitch
[00:28] <wtay> ajmitch: shht, it's not a real one she has :)
[00:29] <maYam> what? a toy card??
[00:29] <maYam> i knew it!..
[00:29] Action: wtay shuts up and continues to write a book..
[00:30] <ajmitch> maYam: no, one listed as stolen so you can explain to the nice policeman how you got it ;)
[00:30] <omega_> um, it seems that if I run gstreamer-register with --help, it invalidates the registry
[00:30] <maYam> so that's why it's in b&w..
[00:30] <omega_> doh
[00:30] <wtay> omega_: uh?
[00:30] <ajmitch> omega_: bit of a bug?
[00:30] <omega_> yeah, I'd say so
[00:30] <wtay> omega_: define 'invalidates'
[00:30] <omega_> next gst command to run has to load all the plugins
[00:30] <wtay> oh
[00:30] <omega_> ah
[00:31] <omega_> it unlinks the registry before doing gst_init
[00:31] <omega_> whoops
[00:31] <omega_> but that's kinda a requirement, sorta
[00:31] <omega_> ick, we need to rethink the way the registry is dealt with, including timestamping and such
[00:31] <wtay> yes
[00:32] <wtay> I didn't know -register was grown that big...
[00:32] <ajmitch> yay, my printer works on small files, it just dies on big ones ;)
[00:32] Action: ajmitch can print assignment ;)
[00:32] Action: omega_ always did his assignments in html and used a mac at school to print them out, since the printers were ethertalk ;-(
[00:32] Action: ajmitch has an old HP DJ670c
[00:33] Action: hadess gave away floppy disks or burnt CDs
[00:33] Action: wtay used plain latex...
[00:33] <ajmitch> wtay: i tried, couldn't get the style right in time
[00:33] <hadess> "up your ass!"
[00:33] <wtay> ajmitch: yeah, it needs some tweaking...
[00:33] <ajmitch> hadess: pity it has on the instructions that it can be in hard copy format only ;(
[00:34] <hadess> ajmitch: yeah :/
[00:34] <ajmitch> wtay: fsckin psychology people and their anal rules about doc styles....
[00:34] <omega_> ajmitch: just means your teacher is a technophobe <g>
[00:34] <ajmitch> omega_: department-wide policy ;)
[00:34] <omega_> even worse
[00:34] <wtay> ajmitch: hmm, latex will show 'em *real* rules..
[00:35] <omega_> I have an idea for debug:
[00:35] <omega_> INFO and DEBUG words themselves change color depending on whether it's core or a plugin
[00:35] <omega_> and could even change color depending on what plugin it is
[00:36] <wtay> cool
[00:36] Action: ajmitch imagines a big pulsating, seething mass of colour on the screen...
[00:36] <wtay> let's hope we don't have to use it :)
[00:36] <omega_> too bad gnome-terminal doesn't implement the blink property
[00:37] <ajmitch> lol
[00:37] Action: hadess is doing crazy componenting cut'n'paste
[00:37] <ajmitch> cya ;)
[00:37] Action: omega_ counts a total of 1467 DEBUG and INFO statements in all of gstreamer
[00:37] Action: wtay can see a gnome-terminal bug report comming...
[00:37] Nick change: ajmitch -> aj_uni
[00:37] <hadess> bye
[00:37] <omega_> wtay: good idea <g>
[00:37] <wtay> <g>
[00:38] <wtay> reason: "gstreamer ran out of colors for it's debug info..."
[00:38] <omega_> doh
[00:38] <wtay> pfff writing docs is not easy
[00:42] <omega_> blink works in text mode
[00:43] <wtay> text mode?
[00:43] <omega_> doesn't work in xterm
[00:43] <omega_> alt-f1
[00:43] <omega_> ctrl-alt-f1
[00:43] <wtay> ah
[00:44] <wtay> an svgasink and I could get rid of X...
[00:44] <omega_> committed
[00:44] <omega_> rather, bug report sent
[00:44] <wtay> heh
[00:46] <wtay> we should have a gst_pad_virtual_connect()...
[00:46] <omega_> yes, that would make life easier for a lot of things
[00:46] <omega_> virtual_connect to a !ALWAYS pad
[00:47] <wtay> maybe also allow it for ALWAYS pads.
[00:47] <wtay> gst_pad_auto_connect()
[00:47] <omega_> yeah
[00:48] <wtay> gst_element_auto_connect is handy too
[00:54] Action: hadess scratches his head
[00:55] <hadess> i'm coding the containers and it's damn messy :P
[00:56] <omega_> containers?
[00:58] <wtay> hmm, example.c has a serious memleak..
[01:00] <omega_> example.c?
[01:00] <omega_> where?
[01:00] <wtay> examples/plugins/
[01:00] <omega_> line?
[01:00] <wtay> gst_buffer_unref on the incomming buffer is missing
[01:00] <omega_> oops
[01:00] <omega_> you can fix that <g>
[01:03] <omega_> hmmmm...
[01:03] <omega_> DEBUG( 9076: 4)gst_bin_loopfunc_wrapper:39: calling loopfunc (null) for element mad
[01:03] <wtay> oops
[01:04] <omega_> appears to just be a bug in the DEBUG_FUNCPTR_NAME routine
[01:04] <wtay> ah
[01:05] <omega_> I have a feeling dladdr doesn't work so well on plugins
[01:05] <omega_> so we have to make sure we make use of the GST_DEBUG_FUNCPTR macro as much as possible
[01:05] <omega_> I just added it to gstmad.c
[01:05] <omega_> there, better
[01:06] <wtay> I guess it doesn't work too wel on static methods.
[01:06] <omega_> oh, that too
[01:06] <omega_> ick
[01:07] <omega_> that would explain why the -inspect of mp3types gives odd results
[01:07] <omega_> try it
[01:07] Action: wtay needs to update the incsched1 branch first
[01:07] <wtay> oooooooooo
[01:07] <omega_> ?
[01:08] <wtay> cothreads.c:202: unterminated macro call
[01:08] <omega_> oops
[01:08] <wtay> hmm
[01:08] Nick change: maYam -> maYam_sleep
[01:08] <wtay> what was that again? compile be fore commit? :-)
[01:08] <omega_> um, I've compiled
[01:09] <wtay> works for you?
[01:09] <omega_> no changes to anything that's relevant
[01:09] <omega_> M gstinfo.c
[01:09] <omega_> M gstscheduler.c
[01:14] <wtay>  GST_DEBUG_LEAVE("",""); fixes it...
[01:14] <omega_> uh?
[01:14] <omega_> you sure you don't have the same I do?
[01:15] <wtay> what do you have then?
[01:16] <omega_>    Repository revision:	1.13.4.9	/cvsroot/gstreamer/gstreamer/gst/gstinfo.c,v
[01:16] <omega_>    Repository revision:	1.13.4.7	/cvsroot/gstreamer/gstreamer/gst/gstinfo.h,v
[01:16] <omega_>    Repository revision:	1.33.4.8	/cvsroot/gstreamer/gstreamer/gst/cothreads.c,v
[01:16] <omega_>    Repository revision:	1.11.4.3	/cvsroot/gstreamer/gstreamer/gst/cothreads.h,v
[01:16] <wtay> 100% the same
[01:16] <omega_> odd
[01:16] <wtay> must be a compiler issue
[01:16] <omega_> what cpp and gcc?
[01:17] <wtay> gcc version 2.95.4 20010319 (Debian prerelease)
[01:17] <omega_> [omega at omicron xchatlogs]$ cpp --version
[01:17] <omega_> 2.95.2
[01:17] <omega_> [omega at omicron xchatlogs]$ gcc --version
[01:17] <omega_> 2.96
[01:17] <wtay> GNU CPP version 2.95.4 20010319 (Debian prerelease) (i386 Linux/ELF)
[01:17] <hadess> omega_: cpp and gcc version are supposed to be the same ...
[01:17] <omega_> hmmm
[01:18] <wtay> cpp -I.. cothreads.c stops the output in the middle of the cothread_stub function
[01:19] <omega_> um, cpp spins for me
[01:19] <omega_> I have the 2.96-69 rpms for both cpp and gcc
[01:19] <wtay>  G_STMT_START{ if ((1<<  31  ) & _gst_debug_categories) _gst_debug_handler(  31  ,TRUE ,"cothreads.c",__PRETTY_FUNCTION__,394,_debug_string, ((void *)0) ,g_strdup_printf(    ""  ": 
[01:19] <wtay>   )
[01:19] <wtay>  ;
[01:19] <omega_> and they both verify correctly
[01:20] <wtay> that's how it expands here
[01:20] <omega_> um, what's the : from??
[01:20] <omega_> g_strdup_printf(    "" ": ) ;
[01:21] <omega_> btw, I'm gonna go to the PLUG meeting tomorrow evening, see if I can get myself scheduled to talk about GStreamer next month <g>
[01:21] <wtay> odd, looks like the colors screw it up
[01:21] <omega_> howso?
[01:21] <wtay>  g_strdup_printf(    "" ": ) ;
[01:22] <omega_> colors don't affect the macros anymore
[01:22] <omega_> or do they
[01:22] <omega_> hmm
[01:22] <omega_> interesting
[01:22] <wtay> just an idea...
[01:22] <omega_> try addig a space before the comma before the ## args
[01:22] <wtay> anyway without GST_DEBUG_ENABLED defined it doesn't even expand
[01:23] <wtay> omega_: tried that
[01:23] <omega_> what if you turn off DEBUG_COLOR ?
[01:23] <wtay> it was turned off..
[01:24] <omega_> um
[01:24] <wtay> hmm, I accidentaly fixed it
[01:25] <wtay> ooh this sucks...
[01:25] <wtay> removing the space in ": entering" fixes it
[01:25] <omega_> huh??????
[01:25] <wtay> yes
[01:25] <wtay> gstinfo.h line 166
[01:26] <hadess> bog!
[01:26] <wtay> hmm, not really
[01:26] <wtay> hmm, ok it doesz
[01:27] <wtay> cothreads.c:202: warning: zero-length format string
[01:27] <wtay> but that's ok I guess
[01:27] <omega_> why is it zero-length?
[01:28] <omega_> it's cat'd with the ":entering\n";
[01:28] <wtay> hmm, yeah...
[01:28] <wtay> G_STMT_START{ if ((1<<  31  ) & _gst_debug_categories) _gst_debug_handler(  31  ,TRUE ,"cothreads.c",__PRETTY_FUNCTION__,202,_debug_string, ((void *)0) ,g_strdup_printf(    ""        )); }G_STMT_END  ;
[01:28] <wtay> expands to that ^^^^
[01:29] <omega_> hmmm
[01:29] <omega_> wonder if we need format ## ":entering\n" ?
[01:29] <wtay> tried that
[01:30] <wtay> ok, got it, you'll need a space before ## args
[01:31] <omega_> yeah
[01:31] <omega_> I remember where that was discovered: in gstinfo.h, in the _builtin stuff (look up)
[01:31] <wtay> if ## args is empty it eats all non whitespace chars
[01:32] <wtay> ok, perfect now
[01:33] <wtay> gotta sleep now, cya all
[01:34] <omega_> committ
[01:34] Nick change: wtay -> wtay-zZz
[01:34] <wtay-zZz> omega_: me or you?
[01:34] <omega_> you
[01:34] <wtay-zZz> ok, sec..
[01:35] <wtay-zZz> commited
[01:35] <omega_> ok
[01:36] <omega_> l8r
[01:37] <omega_> as opposed to automatic changes?
[01:39] <wtay-zZz> ?
[01:39] <omega_> 'manual changes'
[01:39] <wtay-zZz> hmm
[01:40] <wtay-zZz> Small changes to the manual?
[01:40] <wtay-zZz> stupid words <g>
[01:41] <omega_> heh
[01:54] omega_ (omega at omegacs.net) left irc: [x]chat
[01:59] hadess (hadess at pc121-gui14.cable.ntl.com) left irc: mooooh!
[03:07] Nick change: aj_uni -> ajmitch
[03:56] _gst_newt_ joined #gstreamer.
[04:17] Nick change: taaz -> taazzzz
[04:33] _gst_newt_ joined #gstreamer.
[04:35] Nick change: ajmitch -> aj_uni
[05:54] Nick change: aj_uni -> ajmitch