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
- 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
- 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 :-)
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.
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?
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. :-)
>> 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 would be nice, more projects supporting and indirectly marketing
Eet! Maybe being aware of it people will use it more?
>> 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?
>> > 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.
>> 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
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
------------------------------------------------------------------------------
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
