[Stk] Improving support for iOS

[Felipe Sateler]

On Wed, Sep 25, 2013 at 11:50 AM, Stephen Sinclair
<sinclair at music.mcgill.ca> wrote:
> On Wed, Sep 25, 2013 at 4:10 PM, Felipe Sateler <fsateler at gmail.com> wrote:
>> On Wed, Sep 25, 2013 at 10:00 AM, Stephen Sinclair
>> <sinclair at music.mcgill.ca> wrote:
>>> Hello all,
>>>
>>> Okay I have re-written my master branch to reflect all previous releases of STK.
>>>
>>> https://github.com/radarsat1/stk/commits/master
>>>
>>> This can become the new STK master branch if you think it is good.
>>
>> I've submitted a few patches we carry in debian as pull requests :)
>>
>> We do carry some more but they should probably be fixed up a bit
>> before inclusion. (Mostly build system cleanup stuff, the curious can
>> look at what we carry at
>> http://patch-tracker.debian.org/package/stk/4.4.4-3)
>
> I think the patches you've submitted so far are good.  However, I'll
> wait to merge any external pull requests until we've agree that the
> master branch isn't going to be further rewritten.

Of course.

>
> As for your 'install target' patch, it's a good idea, but I'm
> wondering how much work it would be to actually just move to
> automake/libtool.  Although, I'm also equally in favour of *not*
> modifying the build system too much, to keep things simple.  I might
> work on automake support in a branch just to see how it goes.

I'm not a big fan of (nor experienced in) autotools, so I can't really
comment. stk/rtaudio are simple enough that automake may be overkill,
but YMMV.

>
> On another subject, as the Debian guy, I'm curious about your thoughts
> on RtAudio's multiple back-ends.

In debian we treat stk and rtaudio as different projects, and stk
links to the system rtaudio. But our team does also maintain rtaudio,
so..

>  I imagine that if you compile it
> simultaneously for ALSA, Jack, OSS and Pulse, then the RtAudio package
> would have to have dependencies on all of these, which can't be very
> convenient.  What would a good solution be?  I suppose ideally you
> would have separate packages, e.g rtaudio-jack, rtaudio-alsa, etc.,
> but then dynamic backend loading/selection would need to be supported
> at run-time.

It isn't terribly inconvenient.
ALSA will exist in pretty much any linux system, certainly any
installed from debian, and of course any intended for audio use. So an
ALSA dependency is no problem.
Pulseaudio will probably exist in most desktop systems. The library
will almost certainly be (it is brought in by pretty much every audio
player).
Jack will probably exist in any audio production environment. Also, it
is already a dependency of libav/ffmpeg, which is used by mplayer,
vlc, and many other audio players.

So ALSA, Pulseaudio and Jack are not practical problems. At runtime,
we only depend on the libraries, which means that the pulseaudio and
jack servers are not installed by default by rtaudio.

We only build the OSS backend in the freebsd and hurd debian ports.
There is an ongoing effort in debian to completely drop OSS support in
linux[1].

[1] https://wiki.debian.org/ReleaseGoals/NoLinuxDevDsp

>
> Which sounds great, but drastically breaks RtAudio's approach to
> simplicity -- i.e., embedding a single .cpp file in your project to
> automagically have a wide range of audio compatibility.  I've thought
> about this problem somewhat but not yet come up with a good solution
> to propose.

>From debians POV it is not a problem, so there is no solution to propose ;)

-- 

Saludos,
Felipe Sateler