Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library comments

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library comments
From: Maurizio Umberto Puxeddu (umbpux_AT_tin.it)
Date: ke elo    18 1999 - 15:16:59 EDT


Erik de Castro Lopo wrote:
>
> Maurizio Umberto Puxeddu wrote:
> [...snip...]
> > 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 *);
>
> I will consider it if other people think it is a good idea. At the moment
> I cannot see why anybody would want to do either endian swapping or ulaw
> encoding/decoding in any place other than reading from or writing to a
> file. Under what circumstances would you want to perform either of these
> two operations resident in memory?
endianess: in a networking audio application
sample format: connecting code that uses different sample format, such
as in a cut and past between different applications in a Windows-like
fashion. (ulaw encoding is probably a bad example, because it's the less
common sample format conversion, but please take the idea and throw away
me!)
 
> > 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).
>
> At the moment libsndfile only works with regular files. That is, it does
> not work with pipes. When a file is opened for write and is closed using
> sf_close, the library fseeks() to the start of the file and fills in the
> header information correctly.
>
> One of the things I have on my TODO list is to make libsndfile work
> so it can read and write pipes. Unfortunately, once one has started
> writing a large amount of data to a pipe it is not possible to fseek ()
> back to the beginning of the file and correct the header like one can
> with regular files. I see no way around this problem.
But I *was* speaking of regular files. 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 while during the synthesis. (You
probably sets the file length to the maximum value before the close
operation, but this is a bit dangerous.)

> > 3) Some functions in audio editors are easy to implement in "direct
> > mode" if the file is accessible in read/write mode.
> > 3bis) It is possible to append data to a file with your API?
> Neither of these two things are currently possible. I have just had a
> look at SGI's libaudiofile documentation and it has similar restrictions.
> That does not mean it will never be possible with libsndfile, just that
> I did not think it was important yet. Give me a real example where these
> operations are really necessary and I'll look into it.
Say, I want to apply a filter to a segment of audio file without
creating a new copy of it ("direct mode"). With your API I

1) create a buffer
2) open the file in read mode
3) fill the buffer
4) close the file
5) filter the buffer
6) open the file in write mode
7) write the buffer to file
8) close the file
9) reopen the file
10) seek and again from 3)

With read/write access and separate file locators I

1)create the buffer
2)open the file
3)seek write locator and read locator
4)fill buffer
5)filter buffer
6)write buffer and again from 4)

 
> > 4) Why don't you make the I/O operations frame-based instead of
> > requiring that
> > "items" to be an integer times the channels number? (you did it for seek
> > but not for read and write)
>
> I did have my reasons for this but maybe you have found something that
> needs correcting. The reason I use items for sf_read_XXX and
> sf_write_XXX is so that there is no chance of over-running the end of
> array pointer to by the pointer that has been passed into the library.
Excuse me but I don't understand!

> > About channel mixing/splitting:
> [...snip...]
> I'd prefer not to rush into this. I am by nature a rather conservative
> coder and I think there are a number of issues in libsndfile that need
> to be resolved before features like you have proposed. As I have
> suggested, this does not mean that you cannot work your ideas into
> a library that wraps libsndfile. Your work can bypass completely the
> complexities of file header parsing and other file I/O issues while
> providing feedback and ideas for the development of libsndfile.

Ok, this seems to be the better way to work. I agree.
And I agree with you also when you say that you would like to hear
opinions from audio application developers.

Maurizio Umberto Puxeddu


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:52 EST