mirror of
https://github.com/alsa-project/alsa-lib.git
synced 2025-11-01 22:58:49 -04:00
dsnoop: The delay presented to snd_pcm_status_delay() was incorrect
This was the original bug that caused me to start looking at the ring buffer functions. In the API this is documented as: "Delay is distance between current application frame position and sound frame position. It's positive and less than buffer size in normal situation, negative on playback underrun and greater than buffer size on capture overrun. " Because dsnoop was returning the buffer space available to the hardware the return value was always quite large, and moved in the wrong direction. With this patch, dsnoop now gives results which are comparable to using the "hw" device directly. My test case was with snd-echo3g (Layla3G). Signed-off-by: Mark Hills <mark@xwax.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit is contained in:
parent
a510754af2
commit
1a169c21af
1 changed files with 1 additions and 1 deletions
|
|
@ -589,7 +589,7 @@ static inline snd_pcm_uframes_t snd_pcm_mmap_playback_delay(snd_pcm_t *pcm)
|
|||
|
||||
static inline snd_pcm_uframes_t snd_pcm_mmap_capture_delay(snd_pcm_t *pcm)
|
||||
{
|
||||
return snd_pcm_mmap_capture_hw_avail(pcm);
|
||||
return snd_pcm_mmap_capture_avail(pcm);
|
||||
}
|
||||
|
||||
static inline snd_pcm_sframes_t snd_pcm_mmap_delay(snd_pcm_t *pcm)
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue