Skip to content
Chris Hold edited this page Mar 17, 2018 · 13 revisions

Possible problems

  1. ecasound not available under Windows
  2. Handling of files is problematic. The posixpathtools.h file needs to be ported
  3. Jack
  4. Multithreading is not working under Windows, instead the dummy_thread_policy is used automatically, which means there is only one audio thread.
  5. Cross-platform make

Possible solutions to the problems

  1. ecasound is responsible for playback of wav files. This is not needed as the audio input could also provided by other means such as a DAW. But I guess this would require that the DAW or whatever we use is able to work together with jack. Ardour might be one solution, as it seems to be available under Windows. ecasound can be switched of by don't defining ENABLE_ECASOUND in the build system.

  2. In order to fix file handling the posixpathtools.h file needs to be ported. In addition, one has to check that the correct implementation is used on each system. Maybe it is more elegant to use an external library for this, like this one from Boost.

    If we wait long enough, we can simply use the filesystem library from C++17: http://en.cppreference.com/w/cpp/filesystem

  3. According to Jack for Windows there are already native Windows applications and it's even working with ASIO audio applications. This means that DAWs could be routed to the SSR for playback, which would be a very powerful replacement for ecasound.

  4. There is SSR #57, which works nicely under Linux and should also work under Windows. However, on the long run this should be solved by APF #7.

  5. The current GNU autoconf/ autotools build system is made for UNIX systems. While it might be possible to emulate a UNIX environment in Windows there are options to platform-independently generate make files. CMAKE might be a good cross-platform solution.

Parts of the SSR already running under Windows

There exist already a few examples of parts of the SSR running under Windows:

Clone this wiki locally