[MPlayer-dev-eng] Small ao_jack patch

[D Richard Felker III]

On Thu, Oct 07, 2004 at 09:45:35AM +0100, Ed Wildgoose wrote:
> D Richard Felker III wrote:
> 
> >On Wed, Oct 06, 2004 at 09:40:02PM +0100, Ed Wildgoose wrote:
> > 
> >
> >>Ed Wildgoose wrote:
> >>
> >>   
> >>
> >>>Hi, I will be doing a bit of tweaking to the Jack output layer shortly 
> >>>(now that my system is pretty much Jackified now!).  
> >>>     
> >>>
> >>Hmm, interesting.  Just noticed that when you run with "-ao jack 
> >>-channels 4" then every time you fast forward, the front channels 
> >>alternately get mixed in with the rear channels, then back to normal, 
> >>then mixed in again, back to normal, etc... Anyone got any theories on 
> >>this one...?  It's not like the change of driver looks significant...?
> >>   
> >>
> >
> >libaf really REALLY sucks. this type of bug happens all the time with
> >channels>2. the only fix is to rip out that crap and replace it with
> >something with proper design, where all buffer positions are in
> >samples, not bytes.
> > 
> >
> 
> Aha!  Good clue!  So you think that I am seeing something like a 32bit 
> to 16bit mismatch, or something else where byte counting is failing...  

no, it's not quite so broken as to break type alignment. i was
actually unclear in what i said. my point is that the sample
_position_ should be counted, not the byte count or number of samples.
i.e. samples from the same timestamp (but for different channels)
should _always_ be treated together in the buffer and the api should
make it impossible to do differently by counting the whole unit as
"1".

rich