Transmission latency

[alejolp]

Sending a packet may not be synchronized with the PTT.

[SQ6NTI]

It seems that the PTT issue is still valid. I was recently testing serial port PTT and discovered that the transmission window is too short for a frame to be properly sent. Furthermore, PTT time seems to vary, but I don't yet know the basis. When I first noticed the issue, I tried to change audio sampling rate from 48000 to 9600. The result was that PTT time changed from "a bit too short" to "almost none" - TX LED on the trx barely blinked. This may as well be a coincidence and thus I will be doing more tests.

[alejolp]

Hi, and thanks on your input. Yes, we need a clock syncronized to the sound card that after a number of samples the TX goes to false. Having the sound card buffering data makes it tricky, we need to update the sound card abstraction (audiosource).

[SQ6NTI]

I tried to find a callback function in Portaudio to detect 'idle' buffer, but there seems to be no such thing. The only callback available is 'stream finished', but it is only called when the stream is stopped. So indeed time tracking there seems to be the only way. Unfortunately it is quite complex.

[alejolp]

I like the concept. PortAudio allows some degree of configuration for latency. We know how many frames we send to PortAudio and we can do the math for the latency, therefore we can know how long until all the audio patterns were played. Some random information: http://stackoverflow.com/questions/23214614/time-between-callback-calls

[SQ6NTI]

I added on-the-fly rquired ptt time calculation using chrono and timeInfo->outputBufferDacTime and the time seems to be at least closer to what is really required to transmit the whole packet.
https://github.com/SQ6NTI/extmodem/tree/ptt_timing

There is another (original) problem however - audio playback starts with quite a long delay after ptt is turned on. And the problem does not seem to be in the latency returned by PortAudio, or this latency is incorrect, because I included it in required ptt time.

[SQ6NTI]

There is now output latency taken into consideration and PTT sleep timer added in a separate thread, all in my "ptt_timing" branch. At least now some of the packets manage to get through PTT window, but it still seems that PTT is started and ended too early, and I have no idea what else should be considered.

What I discovered by the way is that timeInfo->currentTime inside portaudio_out_callback always returns 0. It looks like it is not properly implemented in portaudio itself. Without stream time it is hard to do proper synchronization.

https://github.com/SQ6NTI/extmodem/tree/ptt_timing