On Tue, 15 Nov 2011 11:28:28 -0200 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> said:
> On Tue, Nov 15, 2011 at 6:42 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Tue, 15 Nov 2011 04:13:32 -0200 Gustavo Sverzut Barbieri > > <barbi...@profusion.mobi> said: > > > >> I really don't know why I bother to explain these things I know will > >> get nowhere. > > > > i've already said we can support it. i just disagree that that is a first > > port of call or the only port of call. i disagree that we totally reply on > > PA for everything we need audio-wise. > > As I said, maybe not clear enough: "we can't rely on PA" is the worse > part. We use that to motivate us to create something new out of > nowhere instead of helping other freesoftware projects. The "excuse" > is often no time and higher priority things. > > I know the history, if it was not this behavior then E would never exist, etc. > > But this is a bad practice: > > - what first looks like simple (20% of the work that maps to 80% > of requirements), will end consuming our already scarce time (the 80% > of the time that maps to 20% of requirements). This results in more > work to do in the long run for a minimal initial save. If you stop to > think, Embryo is an example of this, now we figured out it was better > to use Lua. :-S actually i've spent more time on lua than embryo. much more. embryo still is massively smaller and leaner too. lua also still can't abort execution with infinite loops. embryo can. and let me be clear... EMBRYO WAS BASED ON ANOTHER OPEN SOURCE PROJECT... EXACTLY YOUR ARGUMENT. i didn't write it. the compiler is sill 99% the same as where it came from. i did almost rewrite the entire runtime vm though. and it got a lot smaller in the process. my REQUIREMENTS were "i need something that does: if (x) then do y else do z." that was it. embryo met and exceeded that by a vast vast vast margin. at the time it was a choice of write my own mini logic engine inside edje or re-use another one. i re-used an open source project. i chose the one that had the lowest footprint and least intrusiveness as i wasn't in the mood for having a big fat execution environment. > - this mindset plays against out own project. If we stimulate > people to play Not-Invented-Here syndrome, we suffer as one day we'll > be the other peer. We need more people to collaborate on our code > base, right? But we keep telling people it's better to start something > from scratch instead of helping others! Then we have examples like > turran's enesim/eon, instead of incrementally helping Evas he decided > to go a different new route and we've lost a developer. :-S that has nothing to do with this topic at all. > - relations with other projects. If you go to conferences, many > developers hates us for multitude of ways (when they care to know what > is E/EFL). One of the reasons is that we play the bitch and do not > report or send patches, instead recreating stuff. This keeps away > possible contributors as well "they're not helping me, I'm not helping > them". Maybe it was the case with Xrender, I don't know. Maybe it was > with glib? But I'm seeing it now with PulseAudio/Canberra and I'm > saying it loud :-) and for audio we're using another open source projct that actually DOES have the features we want. in fact using 4 of them. libogg, libflac, libsndfile and libremix... if you didn't notice. maybe you're just upset we're not using your project of choice. as for xrender... that'd involve a massive detour into the internals of x - at the time pixman wasn't even a library. making any changes would involve recompiling and restarting xservers. no better way for e to have been delayed by years. not to mention having to work on multiple drivers too. > Particularly about the last point: I know we don't live in the > wonderland. Some project maintainers are very hard to work with and > changes are just rejected for no reason (hummmm... reminds me of our > last behaviors?) and in this cases it may be worth to fork, do and > prove it's right, having the possibility to merge back someday, or at > least get more developers on bandwagon. and if we fork pulse and then require the new features we have - we have a competing pulse that people have to replace their existing installation of, which invariably no one will do, so we're stuck with the lowest common denominator. i'm sitting and staring at a library that already meets our needs. you just don't like that. > Technically (I'm ignoring bureaucratic and personal reasons) maybe if > it was done this way, we'd be using glib and had avoided all the work > on ecore/eina, with a faster glib that could be speeding up gnome apps > as well? after having fought day in and out within the gnome dev world i wasn't going to touch it. i spent a year of my life being told i was wrong only in the end to be told "shit. you're right. help!". too late. i wasn't going to use glib at all because i already saw things i didn't like - i didn't like the timers using sec+msec vals - a double was much more convenient. there ae no constructs like idle enterers in ecore. there were no animators. i disagreed with other parts of glib i know i'd have to ignore, wrap, or change. i didn't want to bother dealing with that. this has nothing to do with NIH. this has to do with me wanting specific capabilities and the best way of getting them is not depending on PA as of today. it is easier to use a library that already has them. like remix. remix's output can go to PA. it happens to via alsa anyway. > But as the world is not 100% technical, we have to deal with persons > and the line is blurry. But if we always use the excuse "I'be been > burned before" and applying the same old rules to different people, > we'll suffer. > > At least for Lennart, he is bit like you raster. He is hard to get > along, but he does listen and will accept help. :-) lennart is a good guy. i actually like him. what i DON'T want to do is go implement a higher level feature DEPENDING on changes in a lower level library that may take months or years before everyone has it. not only that we have to convince him of a feature that has yet to be used by anyone. we implement it high up first and THEN push it down. THEN convince lennart these features are worth it - provide patches to make his life easy. then hope he agrees. in the meantime we still have a working feature anyway - even without PA... just on good old alsa ... or on jack.. or OSS... or whatever other audio layer is required. > >> Saying that what you want could be easily worked with them is also out > >> of question, there is always the "no time" and "bigger fish to fry", I > >> know the drill... > > > > i've been burned before. i waited so long for xrender to go nowhere. luckily > > i didn't make it a core required rendering back-end. not going to depend on > > something like that again. if PA doesn't have the feature today - i think > > it's unwise to depend on it maybe having it some time in the future. > > PA does what a generic sound system is supposed to do. The track > programming and sequencing should be done on your side, otherwise > you'll be increasing complexity. But loading the samples there and > requesting properties should be fine. If not, then why not help there? > It is not more work, it is less. It's like sound loading. We could > submit loading samples from eet. it is being done "our side". it just so happens the output from an existing open source library is an audio stream already mixed. > It would be nice, more projects supporting and indirectly marketing > Eet! Maybe being aware of it people will use it more? do it AFTER we have it working to demonstrate why we need it. > >> that we don't provide sound feedback and he is waiting it since forever. > > > > oh that's all - yes. because no one has stepped up and done it. someone > > did. i said i wasn't going to do it before e17 release because i didn't > > want to be distracted by it. :) > > I did and was immediately rejected because it was not a dream-way. > Maybe it is the reason it was never done before? by the same token if i didn't reject what i thought was not what i wanted, e would not be what it is. it'd be gtk or qt based. so.. shall we now move to qt? it'd also by in python now if we did everything your way. it's my job to make e what it is. > >> > that is true, but we have a much bigger problem already with that and > >> > images. > >> > >> having a problem does not justify to introduce another ;-) Before you > >> had 1 problem, now you'll have two. > > > > unless PA is going to get sequenced multi-track audio... we can't do > > everything via PA. we have a requirement for a more general solution. > > well.. i have a requirement. we can use PA when and where appropriate. we > > can use canberra when and where appropriate. i'm not going to limit designs > > to just what these happen to do. well not limit, because i care a lot about > > audio. > > Not asking you to limit. Just get the required bits at the correct > places. PA already does sample loading, playback and mixing. All you > need in your side is control of such playback. Likely you can specify > a sequencing playback, but that may be more subtle to discussions and > can be left out for now, merging it when you prove you're right. and PA does not do: * sequencing (timing N channels to have synchronous playback - PA's api can only play a sample at request, not at a timepoint). * variable playback speed (only can play at samples samplerate) * envelopes (volume, pan) * compression for large samples > >> for instance PA allows for sound what you'd like to have with images > >> (central daemon to load stuff), but we're not using it as there is no > >> time. Then we create something else that then we need to create > >> something else again to match. That rule of "we can always solve a > >> problem by creating another abstraction layer". PA would not work > >> everywhere, so create a layer to abstract it away, but that would be > >> the role of PA :-S > > > > but it doesn't do what i want from an audio subsystem - not everything. so > > either i decide to limit what edje does to just what canberra does... or PA > > does, or i can do more if i just deal with the audio mixing locally in edje > > and just punt out audio stream data. this is moot if we support both paths - > > powerful/complex path and simple one, so where is the argument? i want to do > > the powerful one first as the simple one is a subset case. > > Fortunately you're only into graphics and audio. If you were into > kernel, bluetooth, networking... we'd never be able to run in on Linux > :-D if i was into networking ... we'd have a network control gadget that could set static ip's, auto-configure proxies, vpn's, etc. :) and bluetooth would actually be able to not just pair devices but do obex transfers and more. :) are you volunteering to add all these features to PA? you're going to find that a hard push - pa as an api itself doesn't handle file containers at all. it simply allows you to provide "pcm" audio (varying pcm/ulaw formats. to do this through client uploads, the pa server would now have to load them back-door from the file directly. will this be acceptable to lennart? i suspect it won't without a lot of convincing and examples. or then you have to add it to the pa library client api.. and for the same reasons it probably will get rejected too. then you have to do synchronised playback - eg play sample x at timepoint y and have the pa server handle that. in addition you'll have to add playback speed control on play start as well as envelopes per sample. again - it'll add more api and will lennart accept? and at this point there still isn't a working example of why it's needed. i can go on... are you willing to do this though? remix already does most of this. maybe pa should use remix to accomplish this and then o a lot of the code done that uses remix can be transplanted? -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
