On Sun, Aug 09, 2009 at 08:36:12AM -0400, Paul Davis wrote: > *if* the h/w can resample (and if any device could, this would be the > one i would guess it would be), its probably just a poor resampling > implementation, and possibly some interaction between that and the > driver. by "poor" i refer to code quality, not the resampling algo > itself. this card dates from roughly the switchover point when it > started to become "the rule" that cheap h/w ran at a single SR and its > driver resampled when necessary. they could just have done a poor > implementation before eventually making their newer cards rely on > driver resampling. I agree. This seems the most likely explanation. I've had a look at sound/pci/emu10k1/emupcm.c in the kernel source, and there's certainly no resampling going on there ... the card is given the marching orders, and has to provide the data stream at that rate. The maximum rate snd_emu10k1_capture.rate_max is 48000, so that's probably the native rate in the card, and when we ask for it to run at 44100 the card is probably doing the resampling ... and the xruns suggest it is doing it badly. ... in one system I test on, the motherboard audio is SiS SI7012, and it doesn't run at anything but 48000. I'll run a test to see if it is the input or output stream of the emu10k1 that is causing an xrun. -- James Cameron http://quozl.linux.org.au/ _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
