High Delay between Go-Routines using channels (Audio Streaming App)

[Tobias Wellnitz]

Hi,

I'm seeking for advice on a non-deterministic delay when communicating via channels.

I'm writing an application which streams Audio bi-directionally in order to operate my Amateur Radio station remotely from home. Think of this application as a sort of "Walky-Talky" application.

https://github.com/dh1tw/remoteaudio

The software compiles and works, but I have some latency problems within the go-routines in my app. I have measured up to 300ms of delay between writing to a channel and then the data being processed (played on the speakers) at the other end of the channel. This only happens when audio data arrives for the first time but IS NOT deterministic. It only happens every now and then.

Once the data keeps streaming in, the data gets passed instantly to the go-routine responsible for playing it. 

A (non deterministic) 300ms delay at the beginning of a transmission is obviously very annoying.

My "main" go routines are: 

1. Network handling

2. Audio Player

3. Audio Recorder

4. Event Bus

5. Webserver (for control only)

6. Monitoring System events (for graceful exit)

There are about 15 - 20 go routines running (the remaining ones are created by 3rd party packages).

The basic flow for playing audio is: 

Network -> ch -> Audio Ring Buffer -> Play

CPU and Memory profiling haven't shown anything suspicious. CPU usage is between 15 - 20% on a Raspberry Pi3. GC executes every 15 seconds.

This is a Trace when the long delay happened:

http://pastebin.com/D54BH4Da

This is the main routine of the server: 

https://github.com/dh1tw/remoteAudio/blob/master/cmd/serve_mqtt.go

This is the main routine of the client: 

https://github.com/dh1tw/remoteAudio/blob/master/cmd/connect_mqtt.go

This is the go routine for handling network:

https://github.com/dh1tw/remoteAudio/blob/master/comms/comms.go

This is the go routine for reading/writing the ring buffer and playing the Audio:

https://github.com/dh1tw/remoteAudio/blob/master/audio/player.go

I would very much appreciate any hints or advices which could help me to bring the application to a more deterministic behaviour.

Thanks,

Tobias

[Sokolov Yura]

Did you try GOMAXPROC=1 ?

[Tobias Wellnitz]

Hi,

I did some more tracing and I could narrow down the problem to the call when writing data synchronously to the sound card. 

When the sound card does not receive the data in time, it will cause an "Underflow". I read that the underlying, platform specific sound card drivers handle Underflows differently.

Alsa on Linux apparently closes the audio stream and reinitializes it - and this of course takes some time and blocks in the meanwhile my go-routine.

Apparently what I should do is to write empty audio buffer samples to the sound card when no data is received from the network to avoid underflows.

Let's see if this fixes the problem :-)

Tobias

On Sat, Jan 21, 2017 at 8:31 AM, Sokolov Yura <funny....@gmail.com> wrote:

Did you try GOMAXPROC=1 ?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.