Commits
Stefan Knoblich committed a856d81a069
ftmod_misdn: More reworking of b-channel audio tx handling.
Use the amount of audio data received in misdn_read() to determine how many
bytes we need to send to the b-channel (= how much free space is left
in the b-channel tx queue). (This is how libosmo-abis and LCR handle it too.)
A pipe is used as a poll()-able audio tx buffer (filled in misdn_write()):
FTDM_WRITE wait requests are currently poll()-ed on the input side of the pipe,
whereas FTDM_READ and _EVENT requests are poll()-ed on the b-channel socket itself.
For every N-bytes of audio data read from the b-channel in misdn_read(),
we try to get as much out of the tx pipe, convert it into the ISDN_P_B_RAW
format and send it to the b-channel socket.
If there's less than N-bytes left in the pipe, we fill the remaining buffer
with silence to avoid buffer underflows.
B-Channel handling overview:
- misdn_wait(FTDM_WRITE) on audio pipe
- misdn_write() put audio data into pipe
- misdn_wait(FTDM_READ) for next incoming mISDN
message on b-channel socket
- misdn_read() handle mISDN event, for PH_DATA_IND:
- Write data into channel buffer and convert
to a/u-law using misdn_convert_audio_bits()
- Try to fetch N-bytes from audio pipe
- If not enough bytes in pipe: fill remaining space with silence
- Convert audio to raw format
- Send to b-channel (PH_DATA_REQ)
Known problems / bugs / further investigation:
1. Bridge aborted by "Write Buffer 0 bytes Failed!" error from switch_core_io.c.
This is "fixed" by _not_ setting the b-channel sockfd to non-blocking mode.
2. Audio glitches (maybe caused by FTDM_WRITE misdn_wait() handling or blocking I/O on sockfd?)
3. misdn_read() EBUSY error messages from sending data to b-channel sockfd after enabling channel.
Signed-off-by: Stefan Knoblich <stkn@openisdn.net>