В Ср, 22/04/2020 в 20:55 +0200, Gregor Pintar пишет:
> On Wed, 22 Apr 2020 Alexander Tsoy wrote:
> > В Вт, 21/04/2020 в 21:31 +0200, Takashi Iwai пишет:
> > > I wonder, though, whether we can correct the rounding error in
> > > the
> > > driver code, too.
> >
> > I'm not sure if it's possible with currently used Q16.16
> > arithmetic.
>
> Maybe calculate fixed correction shifts (like it would be feedback)?
> Something like leap year.
>
> In endpoint.c:
> static inline unsigned get_usb_high_speed_rate(unsigned int rate)
> {
> return ((rate << 10) + 62) / 125;
> }
> I guess 62 tries to round it, but exact number is needed. So exact
> value for
> 44100 should be 361267.2. For 48000 it is 360448.
> If only we can deliver that 0.2 by shifting rate somehow?
>
> At least maybe it would be better to disable sample rates that do not
> divide
> by 1000 on SYNC playback endpoints, if there are others sample rates.
>
> But I'm not familar with the code or USB.
I think instead of accumulating the fractional part of fs/fps in Q16.16
format we should accumulating remainder of division fs/fps.
So for 44100 Hz and High Speed USB the calculations would be:
fs = 44100
fps = 8000
rem = 44100 % 8000 = 4100
accum = 0
packet_size_min = 44100 / 8000 = 5
packet_size_max = 44100 + (8000 - 1) / 8000 = 6
1. accum += rem = 4100
accum < fps => packet_size = packet_size_min = 5
2. accum += rem = 8200
accum >= fps => {
packet_size = packet_size_max = 6
accum -= fps = 200
}
3. accum += rem = 4300
accum < fps => packet_size = packet_size_min = 5
...
80. accum += rem = 8000
accum >= fps => {
packet_size = packet_size_max = 6
accum -= fps = 0
}
...
