From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: full/half duplex support Date: Mon, 22 Nov 2004 12:35:20 +0100 Message-ID: References: <1100801204.490.4.camel@wonder> <1100896171.237.15.camel@wonder> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <1100896171.237.15.camel@wonder> Sender: alsa-devel-admin@lists.sourceforge.net Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Luuk van Dijk Cc: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org At 19 Nov 2004 21:29:31 +0100, Luuk van Dijk wrote: > > On Fri, 2004-11-19 at 13:13, Takashi Iwai wrote: > > > Hmm, I don't understand your proposal here. > > > > AFAIUC, the problem is that the trigger callback is called twice, for > > playback and capture, on the full-duplex mode. Basically ALSA assumes > > that the playback and the capture streams are accessible > > independently, so no such restriction is implemented (yet). > > no it looks like the callback is called multiple times for the second > stream that is started. so: hwparams() and prepare() and trigger() for > the first, say the capture substream works fine. then I start the > playback substream. my prepare() knows to reconfig the dma when either > channel is running, so that goes well too, and the trigger() knows that > if either substream is running it doesn't need to start the dma i/o, but > then the mid-layer queries the current dma pointer for the capture > stream with the pointer() callback, and I think it doesn't like the > answer (my interpretation), because I see that it calls trigger() again > and again. Then something wrong in the callback routines. Perhaps the pointer callback doesn't return the proper expected position, and the core or the application tries to stop/restart the stream. The trigger(START) callback is called only in the three places. One is the SND_PCM_START ioctl, one in the write, and one in the read to start the stream. In any cases, the current status is checked before the callback is called. So, the fact that the trigger callback is called many times implies that the PCM state remains PREPARED even after the first call. Takashi ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/