2009/1/23 Cristian Morales Vega <cmorve69@xxxxxxxx>: > 2008/6/17 Christian Morales Vega <cmorve69@xxxxxxxx>: >> 2008/6/17 Takashi Iwai <tiwai@xxxxxxx>: >>> At Thu, 12 Jun 2008 20:32:51 +0200, >>> Christian Morales Vega wrote: >>>> >>>> 2008/6/12 Takashi Iwai <tiwai@xxxxxxx>: >>>> > It's unlikely a driver issue but an incompatibility of dmix, I guess. >>>> > But still I don't figure out why this happens. The hwsync is done at >>>> > each snd_pcm_dmix_delay() call (as long as slowptr is set, and it's so >>>> > as default). So, there shouldn't be any difference... >>>> > >>>> > What happens if you use "hw" or "plughw"? >>>> With both plughw and hw works fine. >>>> >>>> If helps, I have simplified the problematic bsnes code into this: >>> >>> The program looks running fine on my machine with another HD-audio >>> codec. What is expected in the output and how wrong on yours? >> >> I knew I should not put it under the code :-p >> "The listened effect is that when fails you listen the noise for just >> buffer_time, and when works the noise never ends." >> >> So the output with the SB Live! is: >> State: 2 >> Delay: 0 >> Passed >> State: 2 >> Delay: 882 >> Passed >> State: 2 >> Delay: 1764 >> Passed >> State: 2 >> Delay: 2646 >> Passed >> State: 2 >> Delay: 3528 >> Passed >> State: 3 >> Delay: 4410 >> Delay/Goal: 4410/3528 >> State: 3 >> Delay: 4410 >> Delay/Goal: 4410/3528 >> State: 3 >> Delay: 4410 >> Delay/Goal: 4410/3528 >> State: 3 >> Delay: 4410 >> Delay/Goal: 4410/3528 >> State: 3 >> Delay: 4409 >> Delay/Goal: 4409/3528 >> >> and so until delay reaches 3528, when a new snd_pcm_writei() is done. >> >> With the AD1988 the buffer is fulled one time. After that never again >> reaches snd_pcm_writei(). The output is: >> State: 2 >> Delay: 0 >> Passed >> State: 2 >> Delay: 940 >> Passed >> State: 2 >> Delay: 1880 >> Passed >> State: 2 >> Delay: 2820 >> Passed >> State: 2 >> Delay: 3760 >> Passed >> State: 3 >> Delay: 4700 >> Delay/Goal: 4700/3764 >> State: 3 >> Delay: 4700 >> Delay/Goal: 4700/3764 >> State: 3 >> Delay: 4700 >> Delay/Goal: 4700/3764 >> >> and so. Delay never decreases. But after some time you see. >> State: 4 >> Delay: 4700 >> Delay/Goal: 4700/3764 >> >> There has been an underrun even if appl_ptr is 4700 frames ahead of hw_ptr??? >> If you uncomment snd_pcm_avail_update() delay decreases and everything is ok. >> > > I still have the same problem with alsa-1.0.19.git20090122-1.1 and > alsa-driver-kmp-default-1.0.19.20090123_2.6.27.7_9.1-3.1 on openSUSE > 11.1. Exactly same behavior: works with emu10k1, works with plughw... > only doesn't works when using AD1988 and "default:1" device. > > Also reading Lennart Poettering discussion about snd_pcm_avail_update, > snd_pcm_delay, etc I see bsnes is wrongly using snd_pcm_delay(). But I > don't understand the snd_pcm_avail() vs snd_pcm_avail_update(). If > snd_pcm_avail_update() doesn't calls hwsync the info it will return > will be outdated/unuseful, will not? And how it is a call to > snd_pcm_avail_update() fixes the problem I'm having here with > snd_pcm_delay()? My problem isn't precisely the lack of a hwsync in > snd_pcm_delay()? > In snd_pcm_avail_update() doc: "The position is not synced with > hardware (driver) position in the sound ring buffer in this function." > isn't a contradiction with "Also this function might be called after > snd_pcm_delay() or snd_pcm_hwsync() functions to move private ring > buffer pointers in alsa-lib (the internal plugin chain)."? Probably > I'm missunderstanding something. If snd_pcm_avail_update() isn't > updating the same thing that snd_pcm_hwsync(), what it is updating? > Forget the last part. I suppose I just need to use snd_pcm_avail() instead of snd_pcm_avail_update() if using mmap, true? Only the "snd_pcm_delay() return value isn't updated" part is important. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
