Re: [Ekiga-list] A comparison ALSA-PULSE

Andrea wrote:
Alec Leamas wrote:
It is at the beginning of the 2 files (the same):

Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 1764
  period_size  : 441
  period_time  : 10000
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 441
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 1764
  silence_threshold: 0
  silence_size : 0
  boundary     : 1849688064

Actually, I thnk I'm wrong. If  the buffer is 1764 frames:. Time for 1
frame = 1/44100 sec = 1000/44100 ms. Time for buffer 1764 * 1000/44100=
40 ms. So, it really not that small, and increasing  it is a problem.

Looking at the code in PSoundChannelALSA::Write(), where len=1764

    /* the number of frames to read is the buffer length
       divided by the size of one frame */
    r = snd_pcm_writei (os_handle, (char *) &buf2 [pos], len / frameBytes);

I would say 1764 is a number of bytes.

The header file confirms this

    virtual PBoolean Write(
      const void * buf, ///< Pointer to a block of memory to write.
      PINDEX len        ///< Number of bytes to write.
There are really two things here: the total size of the hw buffer, and the size of a period. Data is transferred in chunks of one period, that's what's called buffer size in this code as I see it. The buffer is actually four periods, period time is 10000 ns = 10ms. So everything seems to adjust to this model. To summarize, a period is 1764 bytes == buffer above, the total buffer is 1764 frames i. e., 7056 bytes. If I'm right, that is...

After some serious googling I found a document I've used before. Maybe it could be of interest: . Note the hostname, it looks bad, but I actually trust these docs.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]