On Fri 12 Jun 2009 01:15, Cai, Cliff pondered: > > >From: Robin Getz [mailto:[email protected]] > > > > On Thu 11 Jun 2009 21:41, [email protected] pondered: > >> > >> --- branches/2008R1/sound/blackfin/ad1836.c 2009-06-12 > >> +++ branches/2008R1/sound/blackfin/ad1836.c 2009-06-12 > >> @@ -215,7 +215,7 @@ > >> /* Chip level */ > >> #ifdef CONFIG_SND_BLACKFIN_AD1836_TDM > >> > >> -#define AD1836_BUF_SZ 0x40000 /* 256kb */ > >> +#define AD1836_BUF_SZ 0x80000 /* 512kb */ > >> /*In 2 channels mode, the buffer is quadrupled */ > >> #define PCM_BUFFER_MAX (AD1836_BUF_SZ / 4) > >> #define CHANNELS_MAX 8 > >> > > > >I don't see how this really solves anything? > > > >If interrupts are comming in too late - they are comming in > >too late. Changing the buffer size just changes the > >frequency/probability. - it wouldn't appear to solve anything > >(does it?) > > > >A better test would be to turn off exact hardware errors > >(which inserts two SSYNCs on every interrupt - under kernel > >hacking) - to see if this is slowing things down too much for audio... > > > > The bug was introduced by my previous fix for another bug, > I only changed the buffer size related stuf.So this is a quick > way to make things work by adjusting an appropriate buffer size > for the two bugs.it's really werid that why smaller buffer size would > Cause sport receive overflow.
I guess after all these USB issues - I'm less accepting of what appear to be random changes fixing weird problems. :) Do we know - beyond a reasonable doubt - why this is needed? -Robin _______________________________________________ Linux-kernel-commits mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits
