Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Native OSX Decoder using CoreAudio APIs #191

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

Conversation

opcon
Copy link
Contributor

@opcon opcon commented Jan 21, 2017

This is the native OSX audio decoding implementation.

Overview:

  • There is the CSCore.OSX project containing the OSX CoreAudio implementation for IWaveSource as OSXAudioDecoder, as well as MP3DecoderOSX and AACDecoderOSX classes.
    • A linked MonoMac library which wraps the CoreAudio API is also provided. This only contains the relevant code needed for CSCore.OSX, and hence is only ~24K in size. This library is merged with the final CSCore.OSX.dll at compile time, so the final output is a single dll.
  • There is the CSCore.OSX.Test project, which currently contains a single test for the creation of an IWaveSource from an mp3 file.
  • The CodecFactory class has been made more cross-platform:
    • Windows only codecs are now only registered if the program is running on Windows
    • Platform independent codecs are always registered
    • The default codec is now customizable via a delegate, allowing other decoders (e.g. the OSX decoder) to register one of their codecs as the default
    • A helper method is provided as OSXAudio.RegisterCodecs() which registers the relevant OSX decoders in the Codec Factory.

opcon added 6 commits January 21, 2017 20:29
Add a static platform detection class that detects Windows, Mac and Linux.

Only register Windows specific codecs if running on Windows.

Provide a RegisterDefaultCodec method in the Codec Factory that allows customization of the default codec. This makes use of the DefaultCodecAction delegate.

These changes mean that on startup for e.g. Mac, only cross-platform codecs are registered in the Codec Factory. It is up to the user of CSCore to call OSXAudio.RegisterCodecs() which then registers the OSX CoreAudio api with the Codec Factory.
@opcon
Copy link
Contributor Author

opcon commented Jan 21, 2017

A few notes/questions, semi-related to this pull request:

  • The master branch does not build correctly on Linux/OSX without a few changes (case sensitive filenames etc). This was fixed on the linux branch, are you planning to merge that into master or just make the small fixes again?
  • What's the status on merging the openal branch into master?
  • Let me know if you are not happy with the changes to CodecFactory and we can work out a better way to do it.
  • The current version of Mono only supports compiling for .NET 4.0 and up, which means that CSCore needs to be changed from .NET 3.5 to .NET 4.0 in order to compile on Linux. I saw that you already mentioned the reasons for staying on .NET 3.5 in CSCore still uses .NET 3.5 #52, is this still the case?

Cheers :)

@filoe filoe self-requested a review January 21, 2017 11:31
@filoe filoe added this to the CSCore 1.3 release milestone Jan 21, 2017
@filoe
Copy link
Owner

filoe commented Jan 21, 2017

First of all really, really big thanks for your effort! 👍

  • I'll merge the osx and linux branch into the master branch after releasing cscore 1.2. We could also create a new cscore 1.3 branch and merge openal, linux and osx into that branch.
  • As mentioned above, I'll merge openal into master as soon as cscore 1.2 is released.
  • I'll have a look at it. I'm planing to rework the CodecFactory more or less completely. Allowing the detection of the correct format by using just a Stream, allowing to integrate some custom factories (for example ffmpeg,...).
  • I'm currently planing to stay on .net 3.5. Maybe we have to think about that decision once again. There are a few possibilities: keep CSCore on .net 3.5, move CSCore.Linux / OSX to .net 4.0 and so on; move all projects to .net 4.0 (or even heigher??). I have to think about it. For now, I'm going to release cscore 1.2 and with the next version, I'll have to make a few decisions.

But thanks again for your really great effort!!

@opcon
Copy link
Contributor Author

opcon commented Jan 21, 2017

No worries, thank you for all your effort too!

@opcon
Copy link
Contributor Author

opcon commented Feb 19, 2017

Hi @filoe, in the process of figuring out how to deploy my game on OSX I've realised that Xamarin.Mac.dll should be used over MonoMac.dll, as it is newer and has some bug fixes. I'll update this pull request to use Xamarin.Mac.dll instead.

I think creating a cscore 1.3 branch is a good idea rather than merging this straight into master.

@filoe
Copy link
Owner

filoe commented Feb 19, 2017

Merging into master is definitly not an option.
Is Xamarin.Mac.dll the same as MonoMac.dll? Are there any possible problems with any licences?
For me, Mono is not the same as Xamarin. That's the reason why I'm asking.

@opcon
Copy link
Contributor Author

opcon commented Feb 19, 2017

Xamarin.Mac.dll is basically the successor to MonoMac.dll and is updated regularly (see https://github.com/xamarin/xamarin-macios).

It is licensed under the MIT license now (LICENSE), same as MonoMac.dll, so there are no issues there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants