Build has FAILED

Link to build: https://build.enlightenment.org/job/differential_efl_gcc_x86_64/86/
See console output for more information: https://build.enlightenment.org/job/differential_efl_gcc_x86_64/86/console

no, you are using macro that are defined by the configure of the EFL. So if Ecore_Audio.h is used in ANOTHER application, HAVE_WASAPI and HAVE_PULSE are not defined and

#if HAVE_WASAPI

is actually

#if

that is with nothing. In public headers you must not used such macro but only system macro, like (on Windows) :

#ifdef _WIN32
# include <ecore_audio_obj_out_wasapi.h>
# define ECORE_AUDIO_OUT_RENDER_ACTIVATED EINA_TRUE
# define ECORE_AUDIO_OUT_RENDER_CLASS ECORE_AUDIO_OUT_WASAPI_CLASS
# define ECORE_AUDIO_OUT_RENDER_EVENT_CONTEXT_FAIL ECORE_AUDIO_OUT_WASAPI_EVENT_CONTEXT_FAIL
#endif

Build has FAILED

Link to build: https://build.enlightenment.org/job/differential_efl_gcc_x86_64/91/
See console output for more information: https://build.enlightenment.org/job/differential_efl_gcc_x86_64/91/console

now the ifdef HAVE_PULSE problem remains. It is exactly the same problem

One question : is there only 2 possible backends for now (pulseaudio and Windows) ?

if yes, then # ifdef HAVE_PULSE is useless
if no, then follow what is done in Elementary.h.in

How I understand is 2 backend 'audiopulse' and 'wasapi'. in object 'audiopulse' used define HAVE_PULSE. In 'wasapi' no.
When used Ecore_Audio need to understanding, what type of object need to create.
I thinks to need unification of metod create object.
Variant 1: level configuration file of project(efl,...)
Variant 2: level Ecore_Audio of module
Variant 3: level user(edje_multisense ...)

How need to use Ecore_Audio?

i don't understand the question.

Build has FAILED

Link to build: https://build.enlightenment.org/job/differential_efl_gcc_x86_64/223/
See console output for more information: https://build.enlightenment.org/job/differential_efl_gcc_x86_64/223/console

ping

That looks better to me (the public headers don't change based on internal/platform config), but as I mentioned in another patch... I don't think exposing WSAPI or even PULSE in the public headers is good - especially as separate classes and in our future eo based api's because we do try and be portable. there can be rare reasons to expose a platform specific api (because you may need to glue in platform specific data/objects/types) sometimes, but this here is not the case. there just should be a single portable class with portable methods (and maybe feature detection if needed to know if some feature in the api can work or not on the target system).

imagine i'm writing an application in JS and it's now portable. with zero changes the same app runs on windows, osx, linux, tizen and other places... i am not going to have #ifdef's in it as i'm not compiling it, and making me runtime check if a wsapi class works or a pulse one or something else... is pretty silly. i know this is used by edje for audio, but it's ALSO a public api for audio access too.