On Fri, 24 Sep 2010, Paul Braman wrote: > Well, so far no-one has been able to sufficiently answer my inquiry > about how proper default ALSA sound capture should be coded. I've done > enough research to know that my program is getting an underrun > condition on the read. Fine. > > My question remains... > > When I set the hardware parameters, who should I need to set the > period and/or buffer size/time? Isn't the default acceptable? If not, > why not and how do I code around it? > > I've seen "simple capture examples" that just set the period size to > "32" and leave everything else untouched. Is that a good default for > all soundcards? If not, how do I discover what that default should be? 32 is too small. Too many interrupts from hardware and it's usually useless. > Here's my angle ... using OSS I could ask the driver to set its own > block size for best performance and I would just ask for that size and > use it. Never any problem. ALSA doesn't seem to have that concept as > far as I can tell. So, since all I want to do is capture audio from > any soundcard I choose and record it to a file (I don't care much > about perfect latency behavior) what the heck should a generic ALSA > capture program do? Just try to set some reasonable timing values. For you case, buffer size around 1 sec and period size around 0.125sec . snd_pcm_hw_params_set_period_time_near(1000000) and snd_pcm_hw_params_set_buffer_time_near(125000) will help you. (That's reason to have the near like functions.). The problem is that we cannot predict the application usage. What's best settings? All settings which driver allows should work. If you use small periods, there is more processing in kernel, but the latency is smaller. Jaroslav ----- Jaroslav Kysela <perex@xxxxxxxx> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc. ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
