Audio Injection Issues with ChanSpy in confbridge Rooms

Hi everyone,

I’m experiencing a curious situation with Asterisk (20.9.0). I have dialplan functions that use a combination of local channels and ChanSpy to inject audio into user channels to play announcements with the Playback application. Generally, I use ChanSpy like this:

same => n,ChanSpy(${DEST_CHAN},BElqw)

It happens that if the destination channel is in a menu, a two-way call, or in an empty confbridge conference room, the injected audio is heard perfectly. But if the user is in a conference room with one or more people, the injected audio will be heard with small pauses (100 to 200 ms).
Similarly, if I use a local channel connected to a dialplan extension to enter a conference room, play audio for everyone in the room and then exit, the injected audio will also have problems. However, instead of pauses, there will be small skips of about 200 ms.
I collected a debug, and at the time of the issues, I receive many lines like these:

[Jul 22 09:59:51] DEBUG[1086][C-0000000c] audiohook.c: Failed to get 160 samples from read factory 0x7fb675981b58
[Jul 22 09:59:51] DEBUG[1086][C-0000000c] audiohook.c: Failed to get 160 samples from read factory 0x7fb675981b58
[Jul 22 09:59:51] DEBUG[1086][C-0000000c] audiohook.c: Failed to get 160 samples from read factory 0x7fb675981b58
[Jul 22 09:59:51] DEBUG[1086][C-0000000c] audiohook.c: Failed to get 160 samples from read factory 0x7fb675981b58
[Jul 22 09:59:51] DEBUG[1086][C-0000000c] audiohook.c: Failed to get 160 samples from read factory 0x7fb675981b58
[Jul 22 09:59:51] DEBUG[1182][C-0000000b] audiohook.c: Failed to get 160 samples from read factory 0x7fb68c053788
[Jul 22 09:59:51] DEBUG[1182][C-0000000b] audiohook.c: Failed to get 160 samples from read factory 0x7fb68c053788

Any tips on what might be wrong or where I should start looking?

Thank you in advance!

This could be a bug – you might want to follow issue #173 and look in to the workarounds offered there as well.

Ah! That could very likely be it… And if that’s the case, I’m in a bit of trouble because I don’t work with C and I don’t even know where to put that code they mentioned.

So, it’s better to set aside my fancy ideas and go back to the old methods of announcing things until one of our good friends takes a look at it to fix it, if possible, of course…

BTW, @jcolp Sorry to bother you, but if you have a moment, could you possibly take a look at this case? It seems there are ongoing changes on GitHub related to Audiohoock, so maybe this one could be given a check too!

I’m not sure what you mean by ongoing changes. I triaged the Github issue over a year ago, and no change (except in a comment) was put up for actual inclusion. Your issue could very well be the same, I don’t know anything further.

By "ongoing changes, i mean someone is working on audiohook.c on this github issue and this PR.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.