Re: [Traverso-devel] on the fly resampling

[Remon]

> Hi remon,
>
> Ahhh, of course.  I understand.  How annoying!  :P

:D

> I agree that there's not much reason to allow this.  Although I would
> love to have a timestretch feature!  :)  We could also use
> libSoundTouch to alter tempo and pitch separately...  But I guess, not
> for this release!  :)

Yeah, it's not an easy feature to deal with.... 

> But back to the current issue:  I think it would be fine to force
> resampling.  I don't think it's worth the effort to keep supporting
> the non-resampling pathway.  There would be a lot of bugs to work
> around...

Hmm, OK. Well, we also could just leave it as it is now, the default is to 
convert to the proper samplerate anyways, and if a user wants to disable it, 
the audio does playback at the wrong speed, and will sound a bit choppy....

Thanks for the feedback,

Remon

>
> Ben
>
> On Nov 8, 2007 10:26 AM, Remon <address@hidden> wrote:
> > Hi Ben,
> >
> > > Plus, it can probably be worked around by pretending that the source's
> > > sample rate is the same as the current playback rate.  :)  Which I
> > > think would give the old behavior...
> >
> > I've done that, but that doesn't work. Point is that the current play
> > position is translated into a position relative to the file.
> > So, when the samplerates don't match, the reading into the audio buffer
> > happens at the wrong position, well actually the correct position.
> > Argh, don't know how to explain it ....
> >
> > Ehm, when you play at 48 Khz and the audio file is 44 KHz, then before
> > the playcursor reaches the end of the clip, the audioclip would have
> > stopped playing previously, obviously, since we were playing more samples
> > per second then the file really has.
> > But now, due 'universal samplerate logic' in Traverso, we continuously
> > calculate the 'correct' position in the audiofile, which means we jump
> > back a little bit in the audiofile every time we read in the next chunk
> > of it....
> >
> > It probably could be made to 'work' more or less, (then of course the
> > audio plays to fast, and stops playing before the end or after the end of
> > the clip) but the question is do we want such a 'feature' ?
> >
> > I don't see a use for it, such a feature would be more appropriate as a
> > time-stretch feature....
> >
> > Greetings,
> >
> > Remon
> >
> > > benjie
> > >
> > > On Nov 8, 2007 9:16 AM, Nicola Döbelin <address@hidden> wrote:
> > > > On Thursday 08 November 2007 16.13:33 Remon wrote:
> > > > > Does anyone know a solution to this? (other then simply forcing
> > > > > onthefly resampling :) )
> > > >
> > > > What happens if on-the-fly resampling is active, but source and
> > > > hardware samplerate are equal? If the algorithm is smart enough to
> > > > bypass resampling in that case, I would say forcing on-the-fly
> > > > resampling would be just fine. Or are there realistic cases where
> > > > users want to play back with the wrong s.r.?
> > > >
> > > > Nic
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Traverso-devel mailing list
> > > > address@hidden
> > > > http://lists.nongnu.org/mailman/listinfo/traverso-devel
> > >
> > > _______________________________________________
> > > Traverso-devel mailing list
> > > address@hidden
> > > http://lists.nongnu.org/mailman/listinfo/traverso-devel
> >
> > _______________________________________________
> > Traverso-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/traverso-devel
>
> _______________________________________________
> Traverso-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/traverso-devel