With rate, sample and channels defined, each incoming sample of data has a precise moment when it should be played.
data_received reads incoming data and puts in a buffer, then into a queue.
packetize() reads this data eagerly and marks with a time - based on the moment of READING, not the stream queue.
Instead, it would be better to track the STREAM TIME. This creates a problem with input underflow which will have to be handled.
This is mostly fine when the source is streaming audio in it's natural time. If the pulseaudio sends as a bigger chunk od data "to be played later" - weird things can happen. This wasn't problem when I used it with spotify/mopidy though.
I've implemented this approach in the "2.0" release. It seems to work in my environment, but I tested with only one client (which had huge problems before implementation and now it's certainly better in some ways)
With rate, sample and channels defined, each incoming sample of data has a precise moment when it should be played.
Instead, it would be better to track the STREAM TIME. This creates a problem with input underflow which will have to be handled.
This is mostly fine when the source is streaming audio in it's natural time. If the pulseaudio sends as a bigger chunk od data "to be played later" - weird things can happen. This wasn't problem when I used it with spotify/mopidy though.