`SimplyCoreAudio()` crashes on instantiation in command-line executable due to no bundleIdentifier

[jolonf]

A command-line executable will crash when instantiating SimplyCoreAudio() due to unwrapping nil on the bundleIdentifier here:

SimplyCoreAudio/Sources/SimplyCoreAudio/Internal/AudioObjectPool.swift

Line 13 in 146c818

private lazy var queueLabel = Bundle.main.bundleIdentifier!.appending(".audioObjectPool")

This is because by default command line executables don't have an embedded Info.plist. This can be fixed by setting the Create Info.plist Section in Library option in Build Settings -> Packaging to Yes.

However, when creating a Swift executable from the command line using SwiftPM, there doesn't appear to be a way to invoke that setting.

A possible solution from SimplyCoreAudio would be to provide an alternate static string if the bundleIdentifier is nil.

Alternatively, do you know if there is a way to set the CREATE_INFOPLIST_SECTION_IN_BINARY option for swift build?

This isn't critical, I was just creating a simple test from the command line. But is useful for sharing simple examples.

[rnine]

I don't know about CREATE_INFOPLIST_SECTION_IN_BINARY in Swift builds, but it'll probably be just fine to do:

(Bundle.main.bundleIdentifier ?? "SimplyCoreAudio").appending(".audioObjectPool")

Could you add a PR with something on these lines and verify that works in your command line executable?

p.s. may need something similar in OSLog+Default.swift

[technicalpickles]

I'm using SwiftPM on the command line and ran into this as well. For those googling or doing an issue search, this is the error message:

Fatal error: Unexpectedly found nil while unwrapping an Optional value: file SimplyCoreAudio/AudioObjectPool.swift, line 13

I was manually changing AudioObjectPool.swift as @rnine suggested when I found this.

[jolonf]

p.s. may need something similar in OSLog+Default.swift

I can confirm that it has the same issue (I added an os_log() to SimplyCoreAudio.init() to test).

I've put together a PR #51 which fixes both issues.

Here is an example that plays an audio file to an AudioDevice from the commandline: https://github.com/jolonf/audiodeviceplayer

It currently uses the PR for the Package dependency and works fine.