At Wed, 17 Sep 2003 20:01:36 +0100, James Courtier-Dutton wrote:
Takashi Iwai wrote:
At Wed, 17 Sep 2003 19:33:29 +0100, James Courtier-Dutton wrote:
Output from sending stereo sound to the "dmix" device. bash-2.05b# cat status state: RUNNING trigger_time: 1063822024.640173000 tstamp : 1063822060.456968000 delay : -1719463 avail : 1731463 avail_max : 1731463 ----- hw_ptr : 1719463 appl_ptr : 0 bash-2.05b#
Output from sending stereo sound to the "front" device. bash-2.05b# cat status state: RUNNING trigger_time: 1063823309.038609000 tstamp : 1063823320.869677000 delay : 14161 avail : 2223 avail_max : 3586 ----- hw_ptr : 567983 appl_ptr : 582144
As you can see, the "front" device acts correctly, with all the pointers acting as they should.
But with "dmix", all the pointers are wrong.
This is particularly problematic for me, as I need a properly functioning "delay" value for my application.
This is using alsa from 2.6test5 kernel.
is it through the rate plugin? there was a bug about rate plugin together with dmix, which was fixed recently on cvs.
Takashi
How do I tell if it is using the "rate" plugin? I am outputing a single stereo signal at 48khz, 16 bits. Where do I configure the rate that dmix works at natively?
at best you can dump the pcm status to the error log from your app. to check the rate conversion, comparing the status in /proc/asound/card0/pcm0p/sub0/hw_params would be enough, though. if the hardware uses a different sample rate, surely the rate plugin is working.
anyway, if you're using the cvs version of yesterday/today, it must be ok.
Takashi
"rate" is not being used. application outputting at 48khz, hw_params set at 48khz. I have tested with latest alsa-lib anon cvs.
So, this is a new bug.
Cheers James
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
