[PD-dev] separate the audio-backends

[IOhannes m zmoelnig]

-----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.



> I think this is how it is for libpd, but I suppose that's easier
> there since libpd assumes there is some other program that will
> handle that stuff.
> 
> If there was a "register" function like how loaders are registered,
> and a very simple load path like a pre-defined folder like pd/lib,
> then pd -audioapi jack could just look for libaudio-jack.so there
> and load it.  Or maybe it would be better to use the normal Pd
> search path.  This would have the extra benefit of making it easy
> for people to distribute and use alternate implementations of the
> various APIs.
> 

that's actually how it is (meant to be).

all audio-backends register themselves via a a call to
"audioapi_new()". and that's about it.

i haven't implemented anything like default loading of binaries in a
given path, since i think this another problem.

to dynamically add new backends at runtime, i'd suggest to re-use the
library loading mechanism.
#1 manually loading, using something like "-lib jackAPI".
#2 automatic loading, by putting stuff into a special folder the
content of which Pd will dlopen at startup (something like the
~/pd-externals/*-plugin/ mechanism for gui-plugins)

either way, Pd would just open jackAPI.pd_linux as an ordinary
library/external but the setup function would register the new
audio-api rather than new object-classes.


> 
> The symbolic values make a lot of sense.  We should leave in the
> code in Pd that reads the numeric values to support old files, but
> just have it always write out the symbol values.  That should make
> the transition easier.

yes definitely.


> 
> I tried this on Mac OS X, it builds and runs.  Jack works, but
> portaudio does not.  It does not give me any audio devices when I
> try to configure portaudio (see attached pic):
> 


i'll check.

fgmasdf
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlCRN3cACgkQkX2Xpv6ydvSDFwCfdHgyanWF/u836sDC4zgJYhIi
KIwAoOUrwZsQOam5+kKdL85jxC3P4BD1
=QPuJ
-----END PGP SIGNATURE-----