Hi Halley, > I know little of ALSA or Bluez, so I don't know the detail inside.> 1. attached log files:> Blue-startup.log: the log information when "hcid -d -n" start to run> Bluez-play.log: during a helix based player playback an audio stream, the log information from hcid.> > 2. ALSA api > snd_pcm_hw_params() --> snd_pcm_prepare() --> pcm->fast_ops->prepare(pcm->fast_op_arg)> I guess it will call to (from printf log, it does)> File: audio/pcm_bluetooth.c > Function: bluetooth_prepare()> And in this function, it will use the return value from write(data->pipefd[1],&c,1) as its (bluetooth_prepare) return value.---- I think the positive return value "1" was create here; > but I don't know whether there should be some place to translate this value to a valid return value of ALSA API. And I also don't what "1" is valid return value from the write() function. good catch. It is our fault and actually a stupid oversight on our side.We have to do this writing 1 byte into the pipe to wakeup the clients.So writing one byte successfully doesn't give us 0. It gives us 1 and sothere you got your wrong value. I fixed this in the CVS now. Thanks for the analysis. Regards Marcel -------------------------------------------------------------------------This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________Bluez-devel mailing listBluez-devel@xxxxxxxxxxxxxxxxxxxxxxxxxx://lists.sourceforge.net/lists/listinfo/bluez-devel
