Jaroslav, I am working on a conferencing application, and need to deal with audio packets of various sizes (in sample).
> > It's software only limit for read/write transfers. The direct transfers > > (mmap) don't take care about this limit. The idea is to avoid using very > > small transfer chunks which are inefficient. Application might change > > this value from 1 (no control) to buffer_size (in samples), but values > > bigger than period_size hasn't any sense anyway. The application writer who chooses to send audio in chunks of any size then must (and can) also set xfer_align to 1. Which is what I would do to avoid having: 1) audio systematically dropped at the end of each chunk, and 2) writei() return a value different from the number of frames passed to it (which is usually treated as an error) > The physical size of xfer_align * frame_size_in_bits must be multiple by 8, > of course. Adding bit copying in the kernel or library will cause a lot of > overhead. Agreed. To me, this only means that period_size must be a multiple of min_align. Any number of samples given to write1() in alsa-kernel/core/pcm_lib.c should be supported already by the current code, except for the xfer_align check at the top of the function. > I've added this function to library: > > snd_pcm_sframes_t snd_pcm_hw_params_get_min_align(const snd_pcm_hw_params_t > *params) That certainly is helpful, thank you. Regards, Guilhem. __________________________________________________ Yahoo! - We Remember 9-11: A tribute to the more than 3,000 lives lost http://dir.remember.yahoo.com/tribute ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
