Inconsistent audio decoding between the C and Python clients.

[pclov3r]

It appears for some reason I am getting more decoded audio written wav file then the normal output to the C client app.

Perhaps from awhile ago the elastic buffer introduced this issue? maybe a buffer is not being fully consumed or something.

I can post example if needed but it seems pretty easy to reproduce.

Take a short I/Q file and compare the normal program audio output vs the output you get written into a wav file.

[pclov3r]

It appears if i go all the back to d0d91d0 the issue is mostly solved.

If you look really hard it seems like there is maybe a split second more audio in wav but MUCH MUCH better.

[pclov3r]

It looks like when i move from d0d91d0 to c5ab4cc is when the issues start. So hopefully makes it a bit easier to narrow down.

[pclov3r]

It also looks like at least in Linux there is cases where you can have zero audio output from a i/q file but if you write it out to a wav file it's there.

[pclov3r]

Okay, Upon further testing it appears the python client decodes all the audio correctly without writing to a wav file but the C client does not.

[TheDaChicken]

From a quick look at the c cli vs the python cli, I think I can see whats going on. The python cli writes decoded audio right when its received straight to a wav file.

The C CLI does something different. It gets sent to the audio playback queue. It either plays the audio or writes it to a file. When playback is stopped, it should halt until the audio queue is empty and exit. It may not be saving all the decoded audio?

[pclov3r]

That seems possible.

In the past @argilo had some concerns with the C client vs the python client. Perhaps those are showing now.

[pclov3r]

I've gone ahead and renamed the issue.

It appears the issue does exist on Windows too but it's behavior it's sporadic of when it will trigger or not. It seems to only trigger again with weak signals and packets missing.

https://gofile.io/d/gHZy5k here is a case to test. If you test all methods of wav or normal audio output on Linux and windows with both the python and C client you will see it's inconsistent for actual audio playback.

[pclov3r]

Playing around i got a separate client going with the C API with miniaudio and the issue is not present.

So perhaps this is audio buffer issue or libao being bad.

I did have a brief discussion with @argilo perhaps libao needs to be replaced with portaudio or something else. It looks abandoned with no development effort since Early 2014

[TheDaChicken]

https://gofile.io/d/gHZy5k here is a case to test. If you test all methods of wav or normal audio output on Linux and windows with both the python and C client you will see it's inconsistent for actual audio playback.

Could you send another file for me to test? I missed the download period for this to do some testing.

[pclov3r]

https://gofile.io/d/WHpaXv

here is anothre example. Not the same one but it reveals more information

It gets more bizarre.

the C nrsc5 produces the least amount of decoded audio packets, python cli produces more and meanwhile using the NRSC5 pipe samples in my own app gives the most audio here?

[TheDaChicken]

Alright. I was able to reproduce this issue. i did some quick testing with a headache. I put a quick count of all audio frames in both clients. Both decode the same amount of audio frames.

I think I have confirmed that this is due to libao causing this issue. All decoded audio frames in your recording were sent to libao. It decided to not play all of it for some reason. This may be due to buffering in libao.