Date: Fri, 5 Jan 2007 09:34:18 -0200 From: Ricardo Nabinger Sanchez <rnsanchez@wait4.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: freebsd-multimedia@FreeBSD.org Subject: Re: kern/107516: emu10k1 - skips, clicks and lag after a day of heavy usage Message-ID: <20070105093418.a4622c72.rnsanchez@wait4.org> In-Reply-To: <20070105092343.aeywvr2jack4oc0w@webmail.leidinger.net> References: <200701041640.l04GeNAk043403@freefall.freebsd.org> <20070105092343.aeywvr2jack4oc0w@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 05 Jan 2007 09:23:43 +0100 Alexander Leidinger <Alexander@Leidinger.net> wrote: > > Repeatable both with emu10k1 and emu10kx (from ports) drivers, using > > "play" command (audio/sox), and either with the 4 KB buffer or larger. > > Please download the appropriate stuff from > http://people.freebsd.org/~ariff/lowlatency/ and try if to reproduce > the problem. Please report back how it works. I've just installed it, and got *much* better results now. My test case consisted on playing 50 times in a row a short wav file I'm very used to hear. The files: [1] RIFF (little-endian) data, WAVE audio, Microsoft PCM, 8 bit, mono 22050 Hz [2] RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 22050 Hz [3] 2 seconds of mute (in Audacity) [4] 2 seconds of 0.1 amplitude sine wave (Audacity) [5] Audacity, 22050 Hz, 16 bit, mono, with 0.05 s of silence followed by 1 second of 0.1 amplitude sine The results: [1] 10 out of 50 were slightly different from the original/expected sound, but without randomness (the 10 sounded like it had higher tones filtered out) [2] No differences perceived throughout the 50 playbacks, very hard to tell if there are glitches in the very beginning, due to the nature of the sound played (I'd say there wasn't any glitches). [3] Pure mute. [4] Glitch (sounding like a very quick "click") in the very beginning, no distortions after. [5] No glitches like in [4] -- very good. The 0.05 s offset from the beginning avoided the glitch. With XMMS, I couldn't notice anything weird, neither glitches in the very beginning of playback (perhaps XMMS does a better job preparing for playback?). With Psi (Jabber client), the sounds played suffer from the [4] issue. It's using sox's play command as the player. Relevant sysctl output as of now: % sysctl -a | egrep 'snd|pcm' hw.snd.latency_profile: 1 hw.snd.latency: 5 hw.snd.report_soft_formats: 1 hw.snd.feeder_buffersize: 16384 hw.snd.feeder_fmt_downmix: 0 hw.snd.feeder_rate_round: 25 hw.snd.feeder_rate_max: 2016000 hw.snd.feeder_rate_min: 1 hw.snd.verbose: 1 hw.snd.sndstat_isopen: 0 hw.snd.maxautovchans: 4 hw.snd.default_unit: 0 dev.pcm.0.%desc: Creative EMU10K1 dev.pcm.0.%driver: pcm dev.pcm.0.%location: slot=10 function=0 dev.pcm.0.%pnpinfo: vendor=0x1102 device=0x0002 subvendor=0x1102 subdevice=0x8061 class=0x040100 dev.pcm.0.%parent: pci0 dev.pcm.0.eapd: 1 dev.pcm.0.buffersize: 4096 dev.pcm.0.vchans: 1 dev.pcm.0.vchanrate: 48000 dev.pcm.0.vchanformat: s16le % kldstat Id Refs Address Size Name 1 15 0xc0400000 691928 kernel 2 2 0xc0a92000 1aff0 linux.ko 3 1 0xc0aad000 71ac snd_emu10k1.ko 4 3 0xc0ab5000 3c330 sound.ko 5 1 0xc0af2000 4a59d4 nvidia.ko 6 1 0xc0f98000 58554 acpi.ko 7 1 0xc3a8e000 e000 ext2fs.ko 8 1 0xc3bd0000 2000 blank_saver.ko Hope that helps. :) Regards. ps: please keep me in Cc: as I'm not subscribed to multimedia@. -- Ricardo Nabinger Sanchez <rnsanchez@{gmail.com,wait4.org}> Powered by FreeBSD "Left to themselves, things tend to go from bad to worse."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070105093418.a4622c72.rnsanchez>