Re: [Ant-phone-devel] Latency, fragments and their sizes.

[Bruno Hertz]

Roland

thanks very much for your reply. I too verified that
the Alsa list posting wasn't accurate by changing the
fragment sizes in your application and checking the results.
Sorry for the confusion :)

Anyway, I'm still not sure what causes the latencies. Changing
the fragment sizes and/or number didn't have a noticable
effect, and I suspect they might have other reasons too.

One observation from last evening: I had a 1.5 hour
conversation with my brother, and right from the start
I heard my voice echoing with about 0.5 sec delay.
Interestingly, the time I heard the echo was exactly
(about?) the time my voice arrived at the other end.
I verified this by alternately counting numbers with
my brother :)

Moreover, the echo delay (and hence the latency) increased
over time up to some 2 seconds. Plus, after about 40
minutes, my brother started to hear his voice echoing too,
corresponding to a latency resp. delay on his side. I.e.
towards the end of the phone call his voice too reached me
with about 2 sec delay.

For the sake of completeness, I should mention that the
latencies seemed to increase after xscreensaver jumped
in at one time. It was about to blank the screen, and I
moved the mouse to stop it. Interestingly, during the time
xscreensaver was active ant's sound completely vanished
and I couldn't hear neither me nor my brother (while
e.g. my TV application xawtv just rattled away). Plus,
the ant gui didn't properly refresh any more after this
incident, i.e. it kind of froze but not completely, the
refresh just was incredibly slow. Also, if I remember
right, the time my brother started to hear an echo too
was just after this short screen blanking.

Anyway, the refresh might be a Gtk or whatever issue and
not first priority, but I'm starting to wonder wether the
reason for the latencies also lies on the application
and not on the driver/kernel side. Without delving too
much into your app (especially, I don't know much about
gui programming) I noticed that the (local and remote) voice
input handling is done via Gtk callbacks, so I guess
this rather critical and desirably realtime component
of your app heavily relies on Gtk properly handling it?
If so, maybe there's a source for trouble?

Another issue: at one point during yesterday's call I mixed
my xawtv sound into the conversation. I tried that
before when calling myself and it worked OK, but yesterday
I got heavy acoustic feedback and I don't know why. It
most likely was not a local headphone <-> microphone
feedback.

OK, sorry for the long posting, but your application is
great and I'd love to use it. If you don't mind, I might
try to do some debugging and maybe track those latencies down,
although of course it involves some work and I'm not sure
I can do it right now. Anyway, I'll try, and if
you have any additional pointers for me I'd very much
appreciate them (e.g. what is that 'switchboard' you
use for debugging and mentioned in another posting?)

Thanks, Bruno.



On Sat, 2004-02-14 at 10:25, Roland Stigge wrote:
> Hi Bruno,
> 
> The above mentioned posting by Jarolav seems to be the obscuring point
> here. He writes: "[lower 16 bits] 0x0008 means that ring buffer for
> playback will be separated to 8 fragments[...]".
> 
> But look at the official OSS documentation[1]: "0xMMMMSSSS [...] The 16
> least significant bits determine the fragment size. The size is 2^SSSS.
> For example SSSS=0008 gives fragment size of 256 bytes (2^8). [...]".
> Therefore my logb().
> 
> (I think this should resolve the confusion here.)
> 
> IMHO, at least some latency problems with ANT result from different
> handling/initialization of input/output data of the respective OSS
> implementations (OSS, Kernel, ALSA, ...). The number of fragments
> shouldn't be an issue since the latency is determined by the fragment
> size.
> 
> Unfortunately, I still don't have the time (and maybe enough different
> hardware) at the moment to fiddle around with that. :( Feel free to
> contribute your results/code.
> 
> Thanks.
> 
> bye,
>   Roland
> 
> [1] http://www.opensound.com/pguide/oss.pdf