Re: [Lmuse-user] Fixed audio stuttering loud repeated segments upon seek

[Tim E. R. <ter...@ro...>]

On April 12, 2013 06:15:15 PM Florian Jung wrote:
> Am 20.11.2012 23:02, schrieb Tim E. Real:
> > Hi. Someone recently asked about this.
> > 
> > With lots of wave tracks, especially with OGG and FLAC files,
> > 
> >  when you move the play cursor around there are brief annoying
> >  non-muted loud repeated segments.
> > 
> > I did a slight readjustment of audio prefetch and midi thread priorities
> > 
> >  (-5 and -1 instead of +1 and +2).
> > 
> > (Robert: Yes I dropped the midi slightly. I felt the audio should have
> > 
> >  the utmost priority over the midi thread. Do you still think it
> >  should be higher as we discussed long ago?  )
> > 
> > The difference is dramatic. Tested with various Jack settings - 'default'
> > 
> >  priority, or priority 50, or no realtime etc.
> > 
> > MusE now mutes the brief times between seeking, with no stuttering.
> > 
> > --------------------------
> > Now, a word about those OGG and FLAC files:
> > I mentioned in the forums that too many of these files can make MusE
> > sluggish,> 
> >  because libsndfile of course takes more time to read them.
> > 
> > Fair enough. Expected. Use a fast machine.
> > 
> > However I just discovered that if you place two parts overlapping in time,
> > 
> >  containing THE SAME ogg or flac file, MusE will choke badly. For example:
> > 		Track1:	====OGG file wave part=====
> > 		Track2:			=====OGG file wave part======
> > 
> > I recognize this as an all-too-familiar-to-me problem.
> > As MusE is playing and attempting to read the same file twice but from
> > 
> >  different locations, the sound file does not like this - it does not like
> >  being forced to go to different locations, rapidly switching between
> >  two locations like this.
> > 
> > The reason (I think) is these are COMPRESSED files, and they do not like
> > 
> >  being forced to new locations rapidly like this.
> > 
> > These files want, and need, to progress forward naturally on their own
> > 
> >  WITHOUT being forced to jump rapidly between two different locations.
> > 
> > Why is this familiar to me?
> > Well, remember I spoke of my attempts to add automatic resampling
> > 
> >  to MusE using SRC and RubberBand and so on?
> > 
> > And how it worked so beautifully.
> > Until I discovered THIS SAME problem.
> > 
> > The resamplers did not like being forced to new locations like this.
> > They wanted, and needed, to progress forward on their own without being
> > 
> >  forced between different locations rapidly.
> > 
> > So... Looks like I may have to bring this issue to the forefront again.
> > I believe the two problems are the same.
> > 
> > Possibly a side benefit being the resampling work could be forced to
> > 
> >  continue, because I'll be forced to deal with this...
> > 
> > But whew, it was tricky, that's why I never completed it.
> 
> Hi,
> 
> Frankly, I haven't read it all nor understood everything.
> But i think the problem is that compressed audio files shall be treated
> as streams, and not as random-accessible wave files!
> 
> I think the whole MusE audio infrastructure is unsuitable for this:
> instead of process_audio(unsigned start_frame, unsigned end_frame), we
> should rather have a function process_audio(unsigned how_many_frames),
> which remembers the current position.
> 
> calls to whatever kind of "seek()" shall happen rarely, and only if the
> user clicks play, stop or moves the playhead cursor manually.

Yes, I know, I think I added a flag for that or something.
That's how my stretcher worked, it let the file+stretcher progress naturally 
 on its own.. 

> 
> Have you fixed this conceptual flaw already? Or is this still a To Do?

No, still on my mind.
I'm sort of buzzing around that area now, meaning to take another look.
Tim.
> 
> greetings
> flo