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 - 05:33:22 EDT
Hello Erik and Nicola. Hello all.
I think my messange has been partially misunderstood (due to my poor
english! :).
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 *);
...
word_t *resample(word_t *, size_t, double, double);
so that an application needn't to link two libraries for doing the same
operation in different contexts? Depending on your implementation this
may require little or no modifications.
I donwloaded last version of libsndfile.
Is the documentation of your API up to date?
If yes I'd like to point some things that, as far as I understand, are
important:
1) There is no format-independent way to know the file length (/duration
in seconds) other than waiting for EOF.
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).
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?
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 think you should decide about 4) now that libsndfile is still no so
popular... :)
This is just one of the two way I'd like to help libsndfile. The other
will be WRITING THE C++ API. Not now, because I have to finish some
other stuff but I'll first start discussing details with Erik.
About channel mixing/splitting:
I could adapt and send some code from Abstract Audio.
It works this way: the library stores a mixer pointer, defined as a NxM
matrix where N is the virtual channel number and M is the real channel
number.
mixer[i][j] is the contribute from the source channel j to the virtual
channel i
vchannel[i] = mixer[i][j] * rchannel[j] (using Einstein notation)
During a read or write operation the library calls the mixing routine if
the channel numbers don't match. If at open time the application don't
indicate a mixer (that is, the mixer pointer in the handle structure is
NULL), the library creates a default mixer that mixes channels in equal
parts.
I should have code for mixing and for default mixer generation. The
mixing routine has code to handle efficiently common cases like 2x1 or
1x2 mixers and general code for the remaining cases.
Of course, I'd add a general mix_buffer() call too.
Yes, it is straightforward but it is done once for all and having a
"standard" way to mix, someone out there could think of, say, writing a
Gtk/Gtk-- widget that handles mixers matrix elements visually.
A presto,
Maurizio Umberto Puxeddu
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:52 EST