On Sun, 3 Oct 2010, Paul Braman wrote: > Paul Braman wrote: >> >> I guess therein lies some of the fundamental difference with how I was >> previously thinking. I figured I could just ask the driver/device for >> some basic defaults that should work but, instead, I should *tell* it >> what basic defaults I can live with. (Set buffer size near 1s and >> period size near 125ms.) > > I've come to the conclusion that this is stupid as hell. ALSA is > fundamentally flawed if it requires me to set anything more than the > access/format/channels/rate to make basic recording work. I should be > able to ask what the period size is it uses by default for the > hardware and do reads of that size without fear of "xrun" conditions > on my otherwise-unloaded 533MHz CPU. You replied yourself. ALSA is HAL. ALSA does not and cannot determine the system latencies, CPU power and any other system parameters which can influence the processing latency. It's almost impossible. If you don't want to bother with xruns, set the DMA buffers to maximum in the driver (this parameter is configurable using procfs) and ask for these sizes in your application (set buffer size to maximum value and use period size with something like buffer_size / 4). 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
