Subject: Re: [linux-audio-dev] The future of libsndfile
From: Maurizio Umberto Puxeddu (umbpux_AT_tin.it)
Date: su elo 22 1999 - 11:24:18 EDT
Erik de Castro Lopo wrote:
>
> Hi all,
>
> I've been a little overwhelmed with the recent discussion about what
> features people would like. Rather than trying to answer each email
> separately I will try to respond to all the issues in one go. If
> I have missed anything please point it out.
>
> Maurizio Umberto Puxeddu had the following suggestion:
> > > > 2) Some applications (see Csound) may need to update the file header
> > > > each time you perform a write operation (so that B can read while A is
> > > > writing).
> <snip>
> > Csound can rewrite continuously
> > the header while writing a sound file (-R switch), so that you can use
> > an audioplayer to move through the file during the synthesis. (You
> > probably sets the file length to the maximum value before the close
> > operation, but this is a bit dangerous.)
>
> Yes I think this is a good idea. I have been thinking about cleaning up
> the
> header writing code and when I do this I will add an interface something
> like sf_update_header () which will rewrite the header with the number
> of samples written at the time it is called.
An alternative could be setting an "Auto header updating" property at
open time and
conditionally rewriting the header each write call. Don't know what it's
better.
> Another of Maurizio's suggestions was:
> > I was not (not only) asking Erik to insert one or two features. I meant:
> > you have the code for doing this operation while reading/writing a file
> > but an application may have to do the same with audio data resident in
> > memory. Why
> > don't include in your API functions like
> >
> > swap_word_endianess(word_t *, size_t);
> >
> > convert_double_to_ulaw8(double *, size_t, byte_t *);
>
> These functions in libsndfile are slightly different but I will expose
> whatever may be useful. The exposed functions will all be named sf_* ().
> In order to minimise the size of the libsndfile headers, I will use two
> header files sndfile.h which will be similar to the current one and
> sndfileex.h which contains the extra utility functions and includes
> the first header.
This is the best solution. I'll also adopt a similar habit.
[...snip...]
> I have also been having some thoughts along the lines of non-destructive
> editing with edit lists etc. My conclucion was that none of the formats
> libsndfile currently supports is all that well suited to this problem.
I think that basically (but still in a general way) non-destructive
editing can be done using just a playing list of audio fragments, that
supports
fragment insertion/deletion and splitting a fragment in two, seeking and
reading samples.
I think I'll post a C++ API proposal in a week or two.
Erik, do you think you (or I) could do little changes to libsndfile
_internals_ to allow a better code sharing between C and C++ interfaces?
I'm speaking about moving some code in a separate file, splitting a
function call in two or so.
Thank you,
Maurizio Umberto Puxeddu
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:52 EST