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. All of the documentation and examples I've found on the ALSA wiki and in various other places have yet to state this basic premise, which I consider another great flaw in ALSA. Examples show how to make basic settings but never explain that you can't expect reliable behavior without doing so. I'm almost afraid to venture into this realm of basic S/PDIF recording with ALSA, but I have to because that's my job. Paul Braman ------------------------------------------------------------------------------ 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
