pulsely / PulseModemA

"PulseModem A" is an iOS APRS client, that reads and reports APRS location and messages.
https://www.pulsemodem.com/
GNU General Public License v3.0
40 stars 6 forks source link

Crash when turning on headset input on iOS 13.1 #3

Closed n8henrie closed 4 years ago

n8henrie commented 4 years ago

Runs with https://github.com/pulsely/PulseModemA/pull/2 on iOS 13.1, but crashes on toggling on audio input via "headset microphone." Xcode shows:

PulseCQTNC[1211:318993] invalid mode 'kCFRunLoopCommonModes' provided to CFRunLoopRunSpecific - break on _CFRunLoopError_RunCalledWithInvalidMode to debug. This message will only appear once per execution.
Error: Failed to fill complex buffer in float converter ('insz')

EDIT: Added what may be the actual error.

n8henrie commented 4 years ago

https://github.com/syedhali/EZAudio/issues/246

n8henrie commented 4 years ago

Tried changing streamDescription.mSampleRate to 44100 but still get various freezes, often at this line in multimon-ng.

AURemoteIO::IOThread (20): EXC_BAD_ACCESS (code=1, address=0x10c580000)
n8henrie commented 4 years ago

Actually looks like it's only crashing when I turn on headset input; works okay through the built-in microphone.

I can get it not to crash with headset input by changing streamDescription.mSampleRate to 24000 (half of 48000, which it looks like this is the sample rate per syedhali/EZAudio#246, whereas the microphone sample rate is still 44100).

pulsely commented 4 years ago

We are working on replicating the "Error: Failed to fill complex buffer in float converter ('insz')" crash.

The sample rate is 22050 mostly because that's how Multimon seems to sample by default at raw.

Will do a test on a few APRS samples to see revising to 24000 affect the performance.

n8henrie commented 4 years ago

To be clear, the only occurrance of streamDescription.mSampleRate that I've changed to 2400 is here, and it's working well by headset when I do so.

This is on an iPhone X btw.

However, after this change, it crashes if I unplug the headset and use microphone input.

In the logs, I noted that with the headset plugged in, when I turned on audio input (and the app crashed), I saw:

2019-10-01 15:20:06.762008-0600 PulseCQTNC[1560:810355] INTULocationManager: Location Request added with ID: 1
2019-10-01 15:20:08.893503-0600 PulseCQTNC[1560:810355]   Sample Rate:              48000
2019-10-01 15:20:08.893676-0600 PulseCQTNC[1560:810355]   Format ID:                 lpcm
2019-10-01 15:20:08.893734-0600 PulseCQTNC[1560:810355]   Format Flags:                21
2019-10-01 15:20:08.893782-0600 PulseCQTNC[1560:810355]   Bytes per Packet:             4
2019-10-01 15:20:08.893828-0600 PulseCQTNC[1560:810355]   Frames per Packet:            1
2019-10-01 15:20:08.893873-0600 PulseCQTNC[1560:810355]   Bytes per Frame:              4
2019-10-01 15:20:08.893916-0600 PulseCQTNC[1560:810355]   Channels per Frame:           1
2019-10-01 15:20:08.893965-0600 PulseCQTNC[1560:810355]   Bits per Channel:            32
2019-10-01 15:20:08.903780-0600 PulseCQTNC[1560:810355]   Sample Rate:              22050
2019-10-01 15:20:08.903996-0600 PulseCQTNC[1560:810355]   Format ID:                 lpcm
2019-10-01 15:20:08.904075-0600 PulseCQTNC[1560:810355]   Format Flags:                 C
2019-10-01 15:20:08.904123-0600 PulseCQTNC[1560:810355]   Bytes per Packet:             2
2019-10-01 15:20:08.904171-0600 PulseCQTNC[1560:810355]   Frames per Packet:            1
2019-10-01 15:20:08.904257-0600 PulseCQTNC[1560:810355]   Bytes per Frame:              2
2019-10-01 15:20:08.904334-0600 PulseCQTNC[1560:810355]   Channels per Frame:           1
2019-10-01 15:20:08.904377-0600 PulseCQTNC[1560:810355]   Bits per Channel:            16

whereas if I had the headset unplugged and used microphone input, I saw:

2019-10-01 15:22:29.390236-0600 PulseCQTNC[1566:811054]   Sample Rate:              44100
2019-10-01 15:22:29.390331-0600 PulseCQTNC[1566:811054]   Format ID:                 lpcm
2019-10-01 15:22:29.390369-0600 PulseCQTNC[1566:811054]   Format Flags:                21
2019-10-01 15:22:29.390397-0600 PulseCQTNC[1566:811054]   Bytes per Packet:             4
2019-10-01 15:22:29.390425-0600 PulseCQTNC[1566:811054]   Frames per Packet:            1
2019-10-01 15:22:29.390450-0600 PulseCQTNC[1566:811054]   Bytes per Frame:              4
2019-10-01 15:22:29.390476-0600 PulseCQTNC[1566:811054]   Channels per Frame:           1
2019-10-01 15:22:29.390545-0600 PulseCQTNC[1566:811054]   Bits per Channel:            32
2019-10-01 15:22:29.399293-0600 PulseCQTNC[1566:811054]   Sample Rate:              22050
2019-10-01 15:22:29.399365-0600 PulseCQTNC[1566:811054]   Format ID:                 lpcm
2019-10-01 15:22:29.399407-0600 PulseCQTNC[1566:811054]   Format Flags:                 C
2019-10-01 15:22:29.399443-0600 PulseCQTNC[1566:811054]   Bytes per Packet:             2
2019-10-01 15:22:29.399471-0600 PulseCQTNC[1566:811054]   Frames per Packet:            1
2019-10-01 15:22:29.399497-0600 PulseCQTNC[1566:811054]   Bytes per Frame:              2
2019-10-01 15:22:29.399523-0600 PulseCQTNC[1566:811054]   Channels per Frame:           1
2019-10-01 15:22:29.399550-0600 PulseCQTNC[1566:811054]   Bits per Channel:            16

The only difference being the first line. With the change as described above (and headset input working but microphone input broken), unsurprisingly:

2019-10-01 16:07:55.401348-0600 PulseCQTNC[1643:826388]   Sample Rate:              48000
2019-10-01 16:07:55.401520-0600 PulseCQTNC[1643:826388]   Format ID:                 lpcm
2019-10-01 16:07:55.401581-0600 PulseCQTNC[1643:826388]   Format Flags:                21
2019-10-01 16:07:55.401632-0600 PulseCQTNC[1643:826388]   Bytes per Packet:             4
2019-10-01 16:07:55.401677-0600 PulseCQTNC[1643:826388]   Frames per Packet:            1
2019-10-01 16:07:55.401722-0600 PulseCQTNC[1643:826388]   Bytes per Frame:              4
2019-10-01 16:07:55.401772-0600 PulseCQTNC[1643:826388]   Channels per Frame:           1
2019-10-01 16:07:55.401821-0600 PulseCQTNC[1643:826388]   Bits per Channel:            32
2019-10-01 16:07:55.413874-0600 PulseCQTNC[1643:826388]   Sample Rate:              24000
2019-10-01 16:07:55.414038-0600 PulseCQTNC[1643:826388]   Format ID:                 lpcm
2019-10-01 16:07:55.414097-0600 PulseCQTNC[1643:826388]   Format Flags:                 C
2019-10-01 16:07:55.414147-0600 PulseCQTNC[1643:826388]   Bytes per Packet:             2
2019-10-01 16:07:55.414192-0600 PulseCQTNC[1643:826388]   Frames per Packet:            1
2019-10-01 16:07:55.414235-0600 PulseCQTNC[1643:826388]   Bytes per Frame:              2
2019-10-01 16:07:55.414278-0600 PulseCQTNC[1643:826388]   Channels per Frame:           1
2019-10-01 16:07:55.414321-0600 PulseCQTNC[1643:826388]   Bits per Channel:            16

Will do a test on a few APRS samples to see revising to 24000 affect the performance.

Sounds good. Unfortunately I'm having a few issues verifying that it still works for my use case.

pulsely commented 4 years ago

Your input is really fantastic. Tried to unplug from Baofung with iPhone 6 before and saw the app crashed.

We thought it was the Baofung sending some unfiltered voltage changes that caused the crash. Kindly give us 2 days to

Thanks a lot.

pulsely commented 4 years ago

Tried changing to 24000, and app still crashes on iPhone XS with lightning headset. The fix by IlyaBlinov does work. A new build has been submitted to the AppStore, and see if there are any feedbacks on reduction on performances.

On the other hand, the best fix for the headset unplug crash, would be detecting "headset unplug" event and stop the EZAudio thread. A fix will be checked within in a week.

Both codes will be checked in, after merging your changes with Homebrew in a few days. Sorry for the delays.

n8henrie commented 4 years ago

No worries about delays.

As you've described, the most recent app store release runs without crashing from headset input, but crashes when the headset is unplugged -- this is different behavior than I was describing, where it would crash as soon as the headset input was toggled on.

Have you made some local changes that have not yet been pushed to GitHub?

pulsely commented 4 years ago

The changes to stop crashing on iOS 13.1 has been pushed via the newest commit c052e856f9ff6d376f4c905de3b91429f3eeb709.

Once I tested the Homebrew on Catalina, I will also check your Homebrew fix in, too.

Still need to write some code to handle the headset unplug events, as well as resetting the audio to the first available audio source. The new codes should be ready in a couple of days.

harshshah1992 commented 4 years ago

@pulsely Do you get time to handle pending cases?

pulsely commented 4 years ago

@harshshah1992 yeap, figuring out how to work on the "audio channel" switch case. It's a bit hard to debug on an iPhone XS + dongle, but this is definitely the priority.

If you have any inputs, questions or requests, please let us know.

pulsely commented 4 years ago

No worries about delays.

As you've described, the most recent app store release runs without crashing from headset input, but crashes when the headset is unplugged -- this is different behavior than I was describing, where it would crash as soon as the headset input was toggled on.

Have you made some local changes that have not yet been pushed to GitHub?

New code has been added to detect handset changes event with the latest commit 0152fbbffa907eb4b870a7ab6f4dadcd7cd161cb.

More improvement will be made @n8henrie as:

  1. The handset events only trigger issues with lightning based adaptors & handsets, so iPhones with old school audio plug should work. The latest code commits will only limit to iPhone X and above on next build.
  2. The audio waveform EZAudio GUI seems to be a bit off after interruption.
n8henrie commented 4 years ago

Thanks for the updates! It seems to be working with lightning connector on my iPhone X now, and without crashing. I consider this issue resolved.