At Wed, 21 Feb 2007 15:33:35 -0800, Michael K. Edwards wrote: > > I'm writing an application to run on an embedded ARM with very little > hardware buffering capacity on its audio interface. I also wrote an > ALSA driver (to be released under the GPL) for this interface, which > works rather nicely with aplay as long as I tune the period size and > thresholds and so forth, more or less like so: > > aplay -C -t wav -c 1 -d 3600 -f s16_le --period-size=40 > --buffer-size=160 --start-delay=3500 | aplay -P -c 1 --period-size=40 > --buffer-size=160 --avail-min=5500 --start-delay=10500 > > (That's with alsa-lib 1.0.14rc2, unaltered, and alsa-utils 1.0.14rc2, > with a patch to support real-time scheduling and fix all the places > where output that should go to stderr is sent to stdout. That patch > is attached.) I think putting the usage and the information to stdout is normal. > Now, an earlier version of the application was implemented against a > one-off driver for different hardware, and just used read()/write() to > deliver data to the driver. It would be nice to be able to open the > /dev/dsp OSS emulation device, ioctl it into the right format and > tunings, and leave the read()/write() alone, saving the rework for a > callback model for another day. > > Does snd_pcm_oss have reasonable ioctl's to force renegotiation about > period size and start/stop thresholds, roughly equivalent to the > parameters above? It should. There are some mangles with buffer and period sizes because of the limitation of OSS (sizes must be power-of-two), but the lowlevel driver doesn't have to take care about it. If you have problems actually, let us know :) Takashi ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel