[pulseaudio-discuss] Help with code

[Colin Guthrie]

'Twas brillig, and Jonathan Andrews at 09/01/12 17:54 did gyre and gimble:
> Hi all, hope this is the correct place to ask.

It is the right place. Sorry no one has replied to you yet :(

> I've written some code to distribute 8 channels of 22.05khz mono audio
> over a network via UDP broadcast.
> 
> The receiver decodes packets and sends them to 8 connections to pulse
> audio via pa_simple_write.
> 
> My problem is simple(ish).  Sometimes on some clients the reported
> latency creeps up, read via (pa_simple_get_latency).
> 
> In order to try and bring the latency back down I've tried dropping
> packets and not sending to pa_write for a while as well as various
> combinations of pa_simple_flush.
> 
> My question is two part.
> 
> 1) What is the blocking arrangement for applications?  Can I ask pulse
> if a stream is full before I commit to a pa_simple_write ? sometimes my
> main loop (get latency, write) slows down to a crawl.  strace -c reveals
> a lot of time spent in some futex thingi I don't pretend to understand.
> 
> 2) Once latency has crept up can I force it back down?, i've tried
> pa_simple_free but the latency remains the same.  Im guessing pulse has
> let the playback buffer size creep up, but I need it wound back down
> even at the cost of glitching.
> 
> I'd like to avoid the full API if possible, but if needs must.

I've not got any specific answer to your question, but hopefully but
bringing this thread up to the top of the list, people who understand
thse bits better than me can chip in.

Ultimately the simple protocol, is, as it's name suggests, very simple.
It is kinda designed to replicate the kind of API infrastructure that is
present in a legacy application.

With UDP packets, which do not guarnentee ordering (if my memory serves)
you may be better off using the async API anyway... the write API can
take offsets and you can write your data in any order you like. Assuming
your UDP packages contain some degree of timing information you can
probably put them in whenever they they arrive into the audio buffer.
This might solve all your problems.

But like I say, I'm really not 100% sure on the specifics here.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/