On Mon, Mar 07, 2011 at 06:21:32PM +0530, Bedia, Vaibhav wrote:
On Monday, March 07, 2011 5:39 PM, Mark Brown wrote:
This means that applications won't be constrained by the current settings so can't automatically choose the required rate. ALSA is just fundamentally racy here, if you want to reliably open bidirectional streams you need to serialise the startup of the two directions.
When a custom application is written then the race condition can be avoided.
However right now a simple test like "arecord -f dat | aplay -f dat" fails. One way to make it work is to make sure that a call to arecord/aplay (or some dummy app which just sets some valid rate and returns) has been made before both are invoked simultaneously.
For command line testing you can do something like:
arecord -f dat | (sleep 1; aplay -f dat -)
to insert a delay if required. Obviously not all systems will hit the race.