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

[Bruno Hertz]

Hi

I'm using ant-phone with my Fritz USB card, and everything works
pretty great (Thx!) apart from latency issues which have been
mentioned on this list before. More specifically, like other users
I too get about 0.5 seconds sound latency, which is a bit annoying.

In that earlier thread it was mentioned that this might relate to
sound driver buffers and their sizes, so without knowing too much
about sound I took a look at the ant code since buffer sizes seem to
be requested by the application.

As I gather from this Alsa list posting
http://www.geocrawler.com/archives/3/251/1998/6/0/1357864/
fragment number and sizes are set via
  ioctl(audio_fd, SNDCTL_DSP_SETFRAGMENT, &param)
where param is e.g.( 0x0200 << 16) + 0x0008 for 8 fragments
of size 512 bytes.

In ant-phone src/sound.c on the other hand I find in function
init_audio_device the lines
  /* set fragment size */
  fragment_arg = 0x7FFF0000 + logb(*fragment_size);
where fragment_size amounts to a default of 1024 and fragment_arg
is later used as parameter to the aforementioned ioctl.

Now, compared to the calculation in that Alsa list posting, the
way ant-phone sets fragment number and sizes looks pretty obscure
to me. Could somebody please shed some light on this?

When looking into /proc/asound/card0/pcm0c/sub0/hw_params I see
on the other hand the parameters set by ant

 access: RW_INTERLEAVED
 format: S16_LE
 subformat: STD
 channels: 1
 rate: 8000 (1572864000/196608)
 period_size: 512
 buffer_size: 32768
 tick_time: 10000
 OSS format: S16_LE
 OSS channels: 1
 OSS rate: 8000
 OSS period bytes: 1024
 OSS periods: 64

While not knowing what those 'periods' exactly mean I guess they
relate to fragments, and the 1024 period bytes might just be the
fragment size set OK, while the 64 periods could be the fragment
number (?). If so, for the low 8000 sample rate, could it then
be that 64 is way too much and might cause those latencies?

I'm going to check those things myself fiddling the code, but would
sure appreciate some input/hints.

Thanks, Bruno.