Wrong to enable ALSA in OSS section

[yurivict]

These lines shouldn't mention ALSA in the OSS section:
https://github.com/thestk/stk/blob/master/configure.ac#L148
https://github.com/thestk/stk/blob/master/configure.ac#L150

[garyscavone]

Did you read it? It requires ALSA because RtMidi requires ALSA and realtime support in Stk requires RtMidi.

[yurivict]

You don't understand: RtMidi is a different project. RtMidi should require and link to ALSA. When RtMidi is installed, it ALSA is its re-requisite. stk itself doesn't use ALSA.

When I disable ALSA, stk still works. So ALSA should be an optional dependency in case RtMidi is bundled, and it shouldn't be in OSS section. configure.ac should explain why ALSA is needed or not.

RtMidi also is a separate project: https://github.com/thestk/rtmidi

[radarsat1]

I think you are both right to some degree.
@yurivict, STK includes a copy of RtMidi and therefore has the same compilation requirements as RtMidi. it is using RtMidi as a separate library.
That said, in the future I'd like to look into whether we can weaken that requirement. It should be possible to do some of STK real-time audio-only features without RtMidi. @yurivict the reason it's hard to address your issue is that none of the STK/RtMidi/RtAudio developers use a platform that uses OSS and does not have ALSA. If you are using a *bsd or something, perhaps a PR would be a better way to address this more concretely as it's a bit frustrating to have the issue raised with no suggestion what to do about it, since we are not so familiar with those platforms.

[yurivict]

Can you just unbundle RtMidi to get rid of the issue?
RtMidi exists as a separate package, it has rtmidi.pc, can be discovered with pkg-config. Should be easy.
Bundling is a problem-prone process. This is one example. Looking at RtMidi code, it doesn't even require ALSA. It is optional, along with Jack, etc.

[radarsat1]

That goes against @garyscavone's idea that STK should be a single download, compile, install. In fact the whole reason that RtMidi and RtAudio are formatted as just a single big .h/.cpp combo is so that they can be easily dropped into other projects.

Maybe you can explain better what is "the issue"? Is it that you can't install and run STK on your platform? You haven't mentioned which platform you are interested in. I suggest you file an issue more like "STK doesn't run on X platform because Y.."

[yurivict]

Maybe you can explain better what is "the issue"? Is it that you can't install and run STK on your platform? You haven't mentioned which platform you are interested in. I suggest you file an issue more like "STK doesn't run on X platform because Y.."

I run it fine. I am trying to get rid of the patches in the FreeBSD port that patch places that don't make any sense to me. Particularly:

• ALSA is required to go along with OSS - they have nothing to do with each other. So this section looks wrong when it assumes they are somehow related.
• ALSA is a hard dependency: looking at RtMidi code I only see the optional dependency. In fact, stk builds and works w/out ALSA. So configure.ac shouldn't unconditionally require ALSA, it should define --enable-alsa/--disable-alsa

[radarsat1]

patches in the FreeBSD port that patch places hat don't make any sense to me

can you post these, or links to these, so that we have something to work with?

[yurivict]

Here is the patch in question:

@@ -134,27 +133,27 @@ api="$api -D__UNIX_JACK__"
   AC_CHECK_LIB(jack, jack_client_open, , AC_MSG_ERROR(JACK support requires the jack library!))])
 
   case $host in
-    *-*-linux*)
+    *-*-linux*|*-*-freebsd*)
     # Look for ALSA flag
-    AC_ARG_WITH(alsa, [  --with-alsa = choose native ALSA API support (linux only)])
-    AS_IF([test "x$with_alsa" == "xyes"], [
-    api="$api -D__LINUX_ALSA__"
-    AC_MSG_RESULT(using ALSA)
-    AC_CHECK_LIB(asound, snd_pcm_open, , AC_MSG_ERROR(ALSA support requires the asound library!))])
+    #AC_ARG_WITH(alsa, [  --with-alsa = choose native ALSA API support (linux only)])
+    #AS_IF([test "x$with_alsa" == "xyes"], [
+    #api="$api -D__LINUX_ALSA__"
+    #AC_MSG_RESULT(using ALSA)
+    #AC_CHECK_LIB(asound, snd_pcm_open, , AC_MSG_ERROR(ALSA support requires the asound library!))])
 
     # Look for OSS flag
     AC_ARG_WITH(oss, [  --with-oss = choose OSS API support (unixes only)])
     AS_IF([test "x$with_oss" == "xyes"], [
-    api="$api -D__LINUX_OSS__ -D__LINUX_ALSA__"
+    api="$api -D__LINUX_OSS__"
     AC_MSG_RESULT(using OSS)
-    AC_CHECK_LIB(asound, snd_pcm_open, , AC_MSG_ERROR(OSS support requires ALSA for RtMidi!))])
+    #AC_CHECK_LIB(asound, snd_pcm_open, , AC_MSG_ERROR(OSS support requires ALSA for RtMidi!))])

     # If no audio api flags specified, use ALSA
-    AS_IF([test "$api" == ""], [
-      AC_MSG_RESULT(using ALSA)
-      AC_SUBST( api, [-D__LINUX_ALSA__] )
-      AC_CHECK_LIB(asound, snd_pcm_open, , AC_MSG_ERROR(ALSA support requires the asound library!))
-    ])
+    #AS_IF([test "$api" == ""], [
+    #  AC_MSG_RESULT(using ALSA)
+    #  AC_SUBST( api, [-D__LINUX_ALSA__] )
+    #  AC_CHECK_LIB(asound, snd_pcm_open, , AC_MSG_ERROR(ALSA support requires the asound library!))
+    #])

     AC_CHECK_LIB(pthread, pthread_create, , AC_MSG_ERROR(RtAudio requires the pthread library!))
     ;;

If AC_ARG_WITH(alsa, [ --with-alsa isn't removed, it still finds alsa. It should be the way to cleanly disable alsa separately. This line api="$api -D__LINUX_OSS__ -D__LINUX_ALSA__" shouldn't combine OSS and ALSA.

The code should have sections:

• enable/disable Jack
• enable/disable ALSA
• enable/disable OSS

[radarsat1]

Okay thanks that's a lot more clear. I agree that it would be best if upstream doesn't need to apply such patches, so I'll re-open this. I can't promise to work on it for the next little while as both myself and @garyscavone just spent quite some time handling the current issues, but I agree that this could be improved so it's worth leaving it to hang around for a bit and we'll see what we can do.

I suspect that it's possible that it might take more work than you suggest, as it might mean carving out dependencies on RtMidi in the situation where only audio support is detected. Out of curiosity, what is the favourite MIDI API on FreeBSD, and is it supported by RtMidi?

[garyscavone]

Realtime support in STK assumes the existence of both RtMidi and RtAudio. Currently, the only MIDI APIs in Linux supported by RtMidi are ALSA and Jack. I think you might find OSS support in very old versions of RtMidi but it was probably removed because we could no longer support it (and perhaps I could not make its implementation conform to the API I wanted).

A while back, I seem to recall that ALSA had been incorporated into the core Linux distribution, thus, I went with the assumption that ALSA would be available. If you are running a version of unix that does not have ALSA, then you will need to create a new host case in configure for that. Please don't try to wedge freebsd in with linux, as they seem to be incompatible. Create a new freebsd case, in which you subsequently modify the realtime build to omit RtMidi. But you still won't be able to compile most of the realtime project examples, as they all depend on RtMidi.

[yurivict]

Currently, the only MIDI APIs in Linux supported by RtMidi are ALSA and Jack.

Ok, so they should be enabled separately in configure.ac

I went with the assumption that ALSA would be available.

There are a lot of linux distros nowadays. Some of them might not have ALSA, for example Linux for Raspberry Pie, or for routers, or some proprietary or minimalistic versions of Linux might choose to remove alsa. So it's not a very good idea to assume things that don't have to be assumed.

Please don't try to wedge freebsd in with linux, as they seem to be incompatible.

For the purposes of STK, the differences are negligible, and such wedging will work just fine. How do I know, you might ask? I created hundreds of FreeBSD ports, and I can assure you that adding this case of *freebsd* plus fixing those enable/disable items will work perfectly on BSDs.

[garyscavone]

Again, most of the realtime projects expect RtMidi. Thus, to create a release of STK that is supposed to have only realtime audio support, without MIDI support, will require a lot of changes to projects such as demo, effects, ragamatic and eguitar.

If you only want the library, without the example code, that is fine. But in that case, you should configure things such that only the library is built.

[yurivict]

Thus, to create a release of STK that is supposed to have only realtime audio support, without MIDI support, will require a lot of changes to projects such as demo, effects, ragamatic and eguitar.

On Linux, the default is --with-jack --with-alsa. Nothing changes on Linux. I am only asking to make these configurable, not to change defaults. On BSD - --with-jack --without-alsa will work fine. I didn't ask to remove MIDI support.

[garyscavone]

Sorry, I thought you wanted OSS support. Yes, Jack will provide a complete realtime solution and should not require ALSA.

[radarsat1]

I wonder if selecting the RtMidi dummy configuration works in this case.. will have to investigate. Like I said, I'm interesting in helping with this issue, just don't have time at the moment. I think for example that it might be okay to check for both OSS and ALSA and just enable whatever is found, regardless of their dependencies, and default to DUMMY for RtMidi if no supported backend is found. That should basically solve it, no?

Anyways, when I do get a solid moment, I'll have a closer look at that freebsd patch above and see what can be proposed.

[radarsat1]

Also, adding a FreeBSD-compatible backend to RtMidi might be interesting, could be raised as a separate issue/PR if anyone is interested. It seems like it basically uses a device-node-based interface, not really any particular library, if I understand correct from glancing over a few blog posts. i.e. open a device file and read from it / write to it. That's pretty generic and should be possible to implement.

[yurivict]

Also, adding a FreeBSD-compatible backend to RtMidi might be interesting

But with Jack it is supposed to already work, isn't it?

[radarsat1]

But with Jack it is supposed to already work, isn't it?

As far as I know, yes. I moved "check for Jack" section outside of the hosts case in configure.ac because I realized it seems to be available on all platforms now. I haven't tested it on FreeBSD, but some other users have, I believe.

That said, I assume there is some more basic MIDI api for FreeBSD/OpenBSD in existence. A quick look just now only turned up some kind of interface accessing files in /dev. I don't know if there is another library on top of that that people use that I am not aware of.