kern/107516: emu10k1 - skips, clicks and lag after a day of
ariff at FreeBSD.org
Fri Jan 5 12:17:37 PST 2007
On Fri, 5 Jan 2007 09:34:18 -0200
Ricardo Nabinger Sanchez <rnsanchez at wait4.org> wrote:
> On Fri, 05 Jan 2007 09:23:43 +0100
> Alexander Leidinger <Alexander at 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:
>  RIFF (little-endian) data, WAVE audio, Microsoft PCM, 8 bit,
> mono 22050 Hz  RIFF (little-endian) data, WAVE audio, Microsoft
> PCM, 16 bit, stereo 22050 Hz
>  2 seconds of mute (in Audacity)
>  2 seconds of 0.1 amplitude sine wave (Audacity)
>  Audacity, 22050 Hz, 16 bit, mono, with 0.05 s of silence
> followed by 1 second of 0.1 amplitude sine
> The results:
>  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)
>  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).
>  Pure mute.
>  Glitch (sounding like a very quick "click") in the very
> beginning, no distortions after.
>  No glitches like in  -- 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 
> issue. It's using sox's play command as the player.
Please upload all your test samples somewhere so it can be analyzed.
Few of these are probably due to specific driver issues (snd_emu10k1).
How about snd_emu10kx ? There are still few pending fixes that need to
be applied for snd_emu10kx (Yuriy Tsibizov is the current maintainer
for this driver)
I'm particularly interested in  (need a serious double blind test
to rule out placebo effect caused by hearing tardiness) and 
(specific driver issue).
Thanks for your effort on doing various of these tests.
> 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. :)
> ps: please keep me in Cc: as I'm not subscribed to multimedia at .
... Recording in stereo is obviously too advanced
and confusing for us idiot ***** users :P ........
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-multimedia/attachments/20070105/b1d1b134/attachment.pgp
More information about the freebsd-multimedia