9 Aug
2009
9 Aug
'09
9:37 p.m.
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/