Re: [Traverso-devel] Re: JIT Audio File Conversion

[Remon]

Hi,

> Hmmm... looking at ReadSource and MonoReader I notice a few things
> that look odd:
>
> - It looks like the audio files are opened once per channel, and
> during read on a channel, it keep that channel's data and dumps the
> other channels' data.  Is that what's happening?  If so, isn't that
> kind of inefficient?

Yes, and yes.

Note though that internal data only has one channel per audio file, so for 
recorded audio it's no problem.

Imported stereo audio of course is a different issue, and the data is read 
twice. However, the overhead from a disk io pov is negligible, since the data 
is still in memory, so the only overhead is converting it to normalized float 
for the second channel (in case it's a non float audio format)

I've tried to get rid of this 'overhead', but there were massive sync 
problems, besides that on my PIII 800 Mhz the cpu drop was barely visible, at 
least for 1 stereo file.

> - Also, it looks like it seeks on every read.  Should we just start
> reading at a specific frame, and then just keep asking for the next N
> bytes without reseeking.  

Hmyeah, but if the internal file pointer is allready at the correct position, 
the seek doesn't do anything as far as I know.
So it makes for easier and always correct code.. (we don't have to do the 
bookkeeping for file seek / read position.

> And then only reseek when we mean it?  (This 
> will make a big difference when decoding formats like mp3 for which
> seeking will be slower.)

And yes, for compressed audio it's very usefull if we can get rid of the 
mentioned limitations!
That is, at least re-using the audiodata for the n+1 channels.

I would be glad to assist in making it work, though be warned, it could be 
difficult to do it right!


Greetings,

Remon



>
> Ben
>
> On 6/27/07, ben levitt <address@hidden> wrote:
> > Hi devs,
> >
> > I've been thinking about how to handle working with audio files other
> > than those that can be de/encoded by libsndfile, and have the same
> > samplerate as the audio driver.
> >
> > I think that we should allow working natively with other formats,
> > decoding/resampling them as needed, Just In Time.
> >
> > To do this, I'm thinking that ReadSource and MonoReader should not use
> > libsndfile directly.  (Same with WriteSource?)  And should instead
> > keep one of a new set of AudioFile classes that would handle reading
> > in and decoding/resampling the audio. Something like:
> >
> > + AudioFile
> >   - AudioFileLibSndFile
> >   - AudioFileMp3
> >   - AudioFileOgg
> >   - AudioFileAac
> >   - AudioFileFlac
> >   - AudioFileResample
> >
> > All AudioFile classes would know how to:
> >  |- open some kinds of audio files, for either read or write
> >  |- set write parameters (specific to each AudioFile class)
> >  |- read N frames of audio from it
> >  |- write N frames to it
> >  |- seek to frame X
> >  |- close
> >
> > AudioFile would additionally have a static method that could take a
> > filename, and return a new instance of the correct AudioFileXX class.
> > (Purely by extension?  Looking at the file's header?)
> >
> > AudioFileResample would exist in order to change the sample rate of an
> > audio file to match the audio driver's sample rate.  It could take
> > another AudioFile class instead of a file, so any audio file could be
> > resampled after being decoded.  It could have super-efficient
> > passthrough when the sample rates are the same, so other AudioFiles
> > could always get wrapped by one of these...
> >
> > For the formats like mp3 where position in the encoded file does not
> > necessarily map linearly to position in the decoded file, it looks
> > like we can fairly quickly build a mapping, when we import the file,
> > of uncompressed audio position to each encoded "frame" (chunk of
> > audio)'s position, so that we could quickly seek to an exact
> > uncompressed frame.
> >
> > Being able to work directly on compressed files, instead of having to
> > decompress them first will be great!  And of course, I'd want to set
> > up an option to bypass all of this and just convert on import to a wav
> > file of the samplerate of the audio driver for people who notice a
> > slowdown by working with compressed audio natively, like anyone
> > working on a large, complex project.
> >
> > Thoughts?
> >
> > Ben
>
> _______________________________________________
> Traverso-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/traverso-devel