On Oct 31, 2012, at 10:36 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-10-31 15:11, Hans-Christoph Steiner wrote:
What about taking it in this direction fully and making it possible to encapsulate the entire implementation for a given audio API in a single file? Then having it so s_audio.c is never modified.
in theory it is like that... in practice it's almost like that: the entire implementation of a given backend is contained within a single file. however, we still have references of the "built-in" audio-APIs in s_audio.c.
why?
well the target platform is Pd-vanilla.
i assume that it will take some time util Pd-vanilla itself will make all the "default" audio-backends as loadable modules. personally i would prefer it that way, but Pd has a history of keeping a number of functionality "built-in"; e.g. most objects could/should be loaded a runtime rather than being statically linked into the Pd binary ... see your attempts with the "vanilla" library)
so until then all audio-apis that "come with Pd" will continue to be "built-in". now all audio-apis have to register themselves, similar to how each objectclass has to register itself. if you check the code for how e.g. "metro" gets added, you'll see that the relevant code is called in metro_setup(), which in turn gets called by x_time_setup() which in turn gets called by conf_init(), pd_init(), sys_main(), main(). the same holds now true for audioapi_oss() (which registers the OSS API), getting called by audioapi_register(), sys_set_audio_api(),...
i could have moved the "#ifdef USEAPI_OSS" from s_audio.c to s_audio_oss.c. but given that s_audio_oss.c is only compiled with HAVE_OSS is set, it seemed easier to do it that way.
Would it be possible to provide an alternative implementation for the same API as a built-in using this? So for example, an alternate Jack or ALSA implementation in a loadable module?
.hc