[openal] OpenALSoft on Android, how to handle suspend/resume of application

[Olle Hedman]

> Was the capture issue a problem with compiling, or a problem running the
app even if it doesn't attempt to create a capture device?

I looked a bit closer at it, as is, the ALCcoreAudioCapture_open code does
not compile, the problem is AudioObjectGetPropertyData and AudioDeviceID is
not available on iOS, and we need to use kAudioUnitSubType_RemoteIO instead
of kAudioUnitSubType_HALOutput
Shouldn't be too hard to fix I think. I could see if I can get it to work...

I don't think there would be any permission issue as long as you do not
attempt to capture. If I read the documentation right, the system will
automatically display a permission dialog when the recording audio unit is
created, or the user of OpenALSoft can first call
[AVAudioSession requestRecordPermission:]

> For this, there may be another option.

Loopback is interesting, you're probably right I could've used this
instead. I have no good explanation why I didn't :)


On 5 September 2018 at 05:34, Chris Robinson <chris.kcat at gmail.com> wrote:

> On 09/03/2018 06:24 AM, Olle Hedman wrote:
>
>> coreaudio-ios-buildfix.diff
>> -
>> This small patch is to make coreaudio backend build and run on iOS.
>> Capture
>> is disabled. (I have no use for it, and there was some issue with it, I
>> don't remember exactly. Possibly it's not available on iOS, or there was
>> some sandbox/entitlement issue)
>>
>
> Was the capture issue a problem with compiling, or a problem running the
> app even if it doesn't attempt to create a capture device?
>
> ios-bundle-config.diff
>> -
>> Another minor iOS fix, this makes it possible to keep the config file in
>> the application bundle.
>> This might not be needed, but it was how I solved it at that time.
>> Possibly
>> you could also just "chdir()" in your app to the bundle path and it would
>> also work.
>> I'm not using a config file now, but I thought I should include this patch
>> anyhow.
>>
>
> This looks like it may be worth adding regardless.
>
> wave-output.diff
>>
>
> For this, there may be another option. By the looks of it, you want to
> write out the mix to a wav file as the corresponding video frames are
> processed, in non-real-time (then compress and mux the audio with the video
> afterward). What you can do instead is use OpenAL Soft's ALC_SOFT_loopback
> extension to mix the audio in non-real-time, and you then write it to a wav
> file however you can (or encode it directly).
>
> <http://kcat.strangesoft.net/openal-extensions/SOFT_loopback.txt>
>
> The alloopback example shows the extension in action, using SDL to play
> the resulting mix (though you can of course do whatever else you want
> instead with the rendered mix, as fast or as slow as you want).
>



-- 

*Best regards,*
*Olof Hedman*

Mobile:

+46 (0)708 - 42 28 76
Office:

+46 (0)40 - 644 44 95
Web:

www.illusionlabs.com
Twitter:

twitter.com/illusionlabs

Illusion Labs AB
Kalendegatan 25
SE-211 35 Malmö, Sweden


"The information in this e-mail, and attachment(s) thereto, is strictly
confidential and may be legally privileged. It is intended solely for the
named recipient(s), and access to this e-mail, or any attachment(s)
thereto, by anyone else is unauthorized. If you are not the intended
recipient please inform the sender by replying to this transmission, and
delete the e-mail, its attachment(s), and any copies of it, without
disclosing it."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openal.org/pipermail/openal/attachments/20180905/5af8d622/attachment.html>