From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: dmix, pause, and snd_pcm_delay Date: Tue, 13 Jul 2004 11:39:35 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <40EA58EA.2080005@helixcommunity.org> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <40EA58EA.2080005@helixcommunity.org> Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Ryan Gammon Cc: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org At Tue, 06 Jul 2004 00:46:50 -0700, Ryan Gammon wrote: > > I've tried to implement this in a couple of different ways: > 1. Using mmaped timestamps, and converting the time interval between now > and when playback triggered into bytes. > 2. Using bytes_written - snd_pcm_delay() > 3. Using bytes_written - (initial snd_pcm_avail_update() value - current > snd_pcm_avail_update() value > 4. Using the snd_timer api (still figuring this out) > 5. Something with snd_pcm_sync_id_t (not sure what this is, or how to > use it) (2) should be the proper way to work. > 2. This works well until I try to pause. dmix claims support for > hardware pause, but when I pause, the hw.ptr seems to keep marching on, > and when I unpause, snd_pcm_delay() returns a negative value, as the > hardware pointer has become greater than the software pointer. Ok, it's a bug. A workaround is to disable pause/resume as your patch. I'll apply it cvs. A better fix would be the proper implementation, though... Takashi ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com