AudioConverterFillComplexBuffer not working for (E)AC3 in tvOS 18

Question

Created Oct ’24

Replies 3

Boosts 2

Participants 2

Since upgrading to tvOS 18, the above function isn't working for me in converting a stream with these formats. It does work in decoding AAC, however.

https://developer.apple.com/documentation/audiotoolbox/1503098-audioconverterfillcomplexbuffer?language=objc

I pass a valid ioOutputDataPacketSize in, but it always comes out as zero.

Has anyone else observed this too?

I wonder if this is related to the issue being discussed widely about 5.1 sound being broken for many people after upgrading to tvOS 18?

https://discussions.apple.com/thread/255769102?login=true&sortBy=rank

EDIT: further information; the callback gets called once, asking for 1 packet (which is ok). I give it one packet and return noErr. However, after this, the callback is never invoked again. Must be a bug?

EDIT2: the same code continues to work correctly on macOS in decoding the same audio stream.

Boost

Answer 1

Engineer OP

Apple

Oct ’24

Hello @oviano, thank you for your post. Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software.

Please use Feedback Assistant to submit a bug report, include a sysdiagnose, and post the FB number here for my reference.

If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why?

0

Answer 2

oviano OP

3w

Hello, yes I did report this via the Feedback Assistant back on Oct 1st, its FB15344866.

I've not yet had a response though.

PS I also discovered the issue is present on iOS 18 too. The exact same piece of code can decode a 5.1 EAC3 stream on macOS Sequoia, iOS 17 and tvOS 17, but fails on both iOS 18 and tvOS 18.

0

Answer 3

oviano OP

2w

So an update to this, in case anyone is remotely interested!

I added some sample code to the Feedback Assistant report which illustrates the problem.

However I have since discovered that the equivalent objective C API - AVAudioConverter does not suffer the same problem. i.e. the same exact packets are decoded successfully on all platforms when using this API instead of the lower-level AudioConverterFillComplexBuffer API.

If anything I would have expected the higher-level API to be using the lower-level one so this is a bit surprising, but may help someone else who has come across the same issue.

0