Audio issue while transmitting. WebRTC. 4 channels

[CedricEugeni]

Audio issue while transmitting. WebRTC. 4 channels

[shogo4405]

The fix made in #1208 was for the case of 2-channel stereo. It might not work correctly for 3 channels or more. It seems like the iPhone 14 Pro is detecting 4 channels.

[CedricEugeni]

Thanks for your reply @shogo4405 😊

I tried to force the AVAudioSession preferredIntputChannels to 1 or 2 using the setPreferredIntputChannels.
While it seems to work on my iPhone 13mini, it seems it doesn't work on iPhone 14.

So if I have to deal with 4-channels samples. what would be the best way to deal with it inside Haishinkit from your point of view ?
Would I need to "remove" 2 channels from the CMSAmpleBuffer and then give it to the actual Haishinkit code to make it work or have you another idea about something that would make it work ? 🤔

[shogo4405]

I have no idea. We have recently added support for multi-channels in #1273 and #1280. I have also tested it and it seems to work fine with 4 channels.

[leo150]

You can try to discard channels within HK by providing a channel map. Negative value is used to discard an input channel:

myStream.audioSettings.outputChannelsMap = [0: 0, 1: 1, 2: -1, 3: -1]

[leo150]

Also the format descriptions that show on the screenshots look like "input" audio format. HK does conversion from PCM to compressed AAC format. The "output" format can be found in AudioCodecSettings. There's hardcoded maximum number of output channels which is 2. Any extra channels are removed, say you convert from 4 to 2 channels, channels 3 and 4 will be removed.

[shogo4405]

I've made significant changes to the internal audio processing in #1294. There's a possibility that it brings improvements. You can test it on the 'main' branch.

[CedricEugeni]

I'm currently testing it and will tell you if there is improvements or not.
If this does not improve things, I'll take a look and try some things about what @leo150 said earlier to see if it helps.
Thanks for your replies

[CedricEugeni]

Hi,

I took some time to make several tests and waited for the iPhone 15 Pro release to confirm what I thought.
My issue is also happening on the iPhone 15 Pro.

As @leo150 mentioned, I tried to set audioSettings as below:

stream.audioSettings.bitRate = <info given by my backend>
stream.audioSettings.channels = 1
stream.audioSettings.channelMap = [0: 0, 1: 0, 2: -1, 3: -1]

But it seems it doesn't have any effect on the audio.

I also tried to update the library to use the latest code but it also doesn't seem to change anything.

One piece of info I may provide you is that my AVAudioSession is using playAndRecord category & videoChat mode because I have possible audio feedback on speaker and I want echo canceling/voice processing.

If I'm using AirPods or so, I use default mode and it works as expected, but as soon as my AVAudioSession change, sound is behaving in this weird way.

I also tried, when AVAudioSession change, to detach audio from rtmpStream and then reattach it, thinking that maybe it'd get new settings from incoming audio and set things up in a different way that'd be able to handle audio. But it doesn't work either.

Are all of these info giving you any piece of idea or advice for me ?

[asticode]

@shogo4405 @leo150 @CedricEugeni unfortunately we're facing the very same issue. What we've found is that the crackling sound is due to recurring silences or missing samples in the audio. Here are Audacity screenshots :

Here you can see the recurring silences or missing samples.

What we've found is that there's exactly 1024 samples between each recurring silences or missing samples. Therefore we concluded they are either at the beginning or at the end of each audio frame.

We've tried to dig into the resampler and ring buffer but we couldn't find anything that would help us determine where this could come from.

Do the screenshots and/or explanation make you think of anything ? Any help would be greatly appreciated 👍

Cheers
Quentin

[shogo4405]

1. Fork this code and provide logs of the print results showing the occurring symptoms. A log of about 30 seconds should be sufficient.
2. If possible, please provide a simple code snippet for reproduction along with server access details. You can share the reproduction code via a pull request, and the server credentials can be sent via email.

[asticode]

1. We've managed to pin point what is causing the issue : when dealing with WebRTC and 4 channels, CMSampleBuffers sent by the AVCaptureSession sometimes start with 256 "padding/dummy" samples equal to 0 (it happens when the buffer number of samples > 960, there's no problem when the number of samples is exactly 960), the rest of the buffer being fine (here is an example). It leads to 64 silence samples being added per channel, which is exactly the length of silence observed in Audacity.

Unfortunately there doesn't seem to be any information in the CMSampleBuffer informing its user that there's padding to be skipped at the start of the buffer 😱

Do you have any thought on that? Or any idea on how we could go about fixing this issue?

2. It's not easy to provide reproducible steps, but we'll try it when we exhaust all other possibilities 👍

[shogo4405]

Fork this code and provide logs of the print results showing the occurring symptoms. A log of about 30 seconds should be sufficient.

Code is here.
https://github.com/shogo4405/HaishinKit.swift/tree/feature/print-samplebuffer

I'm not interested in the byte sequence of the CMSampleBuffer. I want to know the PTS (Presentation Time Stamp). Please provide the dump result.