osalp-dev

[Osalp-dev] aflibMpgFile

[Darrick S. <da...@dc...>]

Happy New Year -

I'm curious what plans there are for improving the aflibMpgFile module.  I've 
been playing around with it and added the ability to seek to a sample within 
the Mpeg file.  I also rewrote the open routine so you get the total_sample 
length.  It works well but It's kind of goofy.  It doesn't work well when you 
do a lot of seeks.  Currently I'm taking advantage of mpg123 ability to skip 
frames and just reopening the pipe when the position changes from the last 
read.  This is quite slow though.

However, I got some mpeg file specs and was planning on opening the mpeg file 
with fopen and then opening a pipe to mpg123.  Then seek to what frame I need 
in the mpeg file and running that through the pipe.  

Also regarding magic and AFLIB_AUTO_TYPE.  I think magic works well.  If a 
programmer wants to use a file type which can't be determined by magic then 
I'm sure they don't want to use be able to auto detect as there is usually 
other things which need to be done to handle the file.  

However, concerning all the aflibAudioType enums.  I think as opposed to this 
the module file should generate the list of supported audio types.  So rather 
then:

static aflibFile *
   open( 
aflibFileType type_enum, 
const string& file, aflibConfig* cfg = NULL, aflibStatus* status = NULL);

you'd have:

static aflibFile *
   open( 
const string& audio_type, 
const string& file, aflibConfig* cfg = NULL, aflibStatus* status = NULL);

And for writing you should be able to open the file based on extension.  That 
way you could save files similiar to how the gimp saves files.  Also the 
programmer won't have to worry about adding new types.

-Darrick

Re: [Osalp-dev] linking troubles

[<for...@ad...>]

Darrick Servis wrote:

> Got it.  I've worked on the program some more and do feel I have a buffer
> overun somewhere.  I'll see what using Electric Fence brings up tonight.
> 
> About the module I wrote.  Well at first I thought the library chose what
> module to use via extension.  Guess not.  So right now the CDR file module is
> what is used if a file type can't be determined.  I've noticed if Magic is
> NONE then that will match any file.   I was using the Raw file module to open
> Gus patch files which have a header I can search.  So i'm doing that now.

Here is what you could do. 

1) Modify aflib.h - Add an enum type for aflibFileType. Such as
AFLIB_RAW_TYPE and
   AFLIB_CDR_TYPE. 

2) Modify aflibFile.cc - Add to function allocateModuleFile two cases
for each enum
   according to the format given.

Doing this should allow you to use these enums instead of
AFLIB_AUTO_TYPE.

I think you have brought up a good problem. I need to create a way to
load a file
format module without having to depend on a magic number.

Bruce Forsberg

Re: [Osalp-dev] linking troubles

[Darrick S. <da...@dc...>]

On Thursday 28 December 2000 14:43, for...@ad... wrote:
> Darrick Servis wrote:
> I am not to sure what you mean by "the linking in my app gets corrupted"
> ?
> I would also recommend you try Electric Fence (a memory debugger) and
> make
> sure you don't have any memory problems. I have used it with the player
> app
> and it works great.

Got it.  I've worked on the program some more and do feel I have a buffer 
overun somewhere.  I'll see what using Electric Fence brings up tonight.

About the module I wrote.  Well at first I thought the library chose what 
module to use via extension.  Guess not.  So right now the CDR file module is 
what is used if a file type can't be determined.  I've noticed if Magic is 
NONE then that will match any file.   I was using the Raw file module to open 
Gus patch files which have a header I can search.  So i'm doing that now.

Thanks
Darrick

Re: [Osalp-dev] linking troubles

[<for...@ad...>]

Darrick Servis wrote:

> I first set out to write modules to load Raw and CDR audio files.  I don't
> have any experience writing modules.  But I copied the Wav module and just
> made changes to some of the functions.  Compiled, installed and updated the
> modules_list file.

Good. 

> 
> I've rewritten a program I have to use aflib and it is linked with -lqt
> -lpthread -ldl -lm -lc -laflib and the -rdynamic switch.  Problem I'm having
> is when I use my new aflibRawFile.so module the linking in my app gets
> corrupted.  I've never debugged anything like this before and I'm kind of at
> a loss on how to do so.  Tonight I'll use the example player code to check to
> see how well my module is working.

I am not to sure what you mean by "the linking in my app gets corrupted"
?
I would also recommend you try Electric Fence (a memory debugger) and
make
sure you don't have any memory problems. I have used it with the player
app
and it works great.

> 
> So what are the steps in dealing with this.  The module works fine the first
> couple of times.  When I call the qt file dialog the program usually crashes.
>  I've looked at info sharedlibrary in gdb and it shows that aflibRawFile.so
> is loaded but the symbols aren't read.  This is after loading a couple of raw
> files.  Got any debugging tips?
> 
> I just read the man dlopen and my feeling is a symbol from aflib is getting
> resloved to a symbol in qt.  Possible?

I don't see how since your aflibRawFile class should be unique. Make
sure that
if you call any outside libraries from your module that you link against
the
.a for that library so that the module stands on its own.

> 
> Sorry I can't be more specific.  This is all on the cutting edge of my
> knowledge.
> 
> Couple other things:
> 
> in the makefiles for the format libraries.  why is the module sometimes
> linked to libaudiofile.a and sometimes not.  i.e. aflibAifcFile.o is
> aflibDevFile.o is not.  neither are the mp3 encoders linked to libaudiofile.a
>  I took the line out on all the files and didn't have a problem.

libaudiofile.a is used for reading and writing AIFC, AIFF, AU, and WAV
file formats.
When one makes a dynamic loaded module it should stand on its own and
not need
any other libraries except maybe libc and libC. They will all compile
without it but
it should fail when to try to read from one of these formats.

> 
> I have more questions but I'll figure out my linking problem first.  Overall
> I like the library.  It seems to do what I need it to do.  What's the word on
> Effect plugins?

I have no plans as of yet. When I get a chance I will probably work on
filters.
But I need to come up with some kind of framework for filters first.

Bruce Forsberg

[Osalp-dev] linking troubles

[Darrick S. <da...@dc...>]

Hello -

I'm new to the list and just started experimenting with the library about a 
week ago.

I first set out to write modules to load Raw and CDR audio files.  I don't 
have any experience writing modules.  But I copied the Wav module and just 
made changes to some of the functions.  Compiled, installed and updated the 
modules_list file.

I've rewritten a program I have to use aflib and it is linked with -lqt 
-lpthread -ldl -lm -lc -laflib and the -rdynamic switch.  Problem I'm having 
is when I use my new aflibRawFile.so module the linking in my app gets 
corrupted.  I've never debugged anything like this before and I'm kind of at 
a loss on how to do so.  Tonight I'll use the example player code to check to 
see how well my module is working.

So what are the steps in dealing with this.  The module works fine the first 
couple of times.  When I call the qt file dialog the program usually crashes. 
 I've looked at info sharedlibrary in gdb and it shows that aflibRawFile.so 
is loaded but the symbols aren't read.  This is after loading a couple of raw 
files.  Got any debugging tips?

I just read the man dlopen and my feeling is a symbol from aflib is getting 
resloved to a symbol in qt.  Possible? 

Sorry I can't be more specific.  This is all on the cutting edge of my 
knowledge.  

Couple other things:

in the makefiles for the format libraries.  why is the module sometimes 
linked to libaudiofile.a and sometimes not.  i.e. aflibAifcFile.o is 
aflibDevFile.o is not.  neither are the mp3 encoders linked to libaudiofile.a 
 I took the line out on all the files and didn't have a problem.

I have more questions but I'll figure out my linking problem first.  Overall 
I like the library.  It seems to do what I need it to do.  What's the word on 
Effect plugins?

Thanks 
Darrick   

[Osalp-dev] MP3 and command line example changes

[Bruce F. <for...@ad...>]

I made two changes into the CVS repository.

1) Made changes so that file names with spaces in them get passed
correctly to the applications that the library calls.

2) Changes command line example prog to osalp. Also added README file
to osalp describing how to use it. Added a convert mode to the osalp
sample command line application that will allow one to convert one audio
file format to another.

Bruce Forsberg

[Osalp-dev] More Solaris changes

[<for...@ad...>]

I have checked into CVS a couple more Solaris Sparc fixes.
One is for record mode to the Solaris audio device. It turns
out that the buffering is very poor for the Solaris audio
device. I have added a aflibBufferDev class in the solaris_dev
directory which performs buffering. I also fixed some big
endian problems with the aflibData class.

Bruce Forsberg

[Osalp-dev] Solaris Sparc now supported

[<for...@ad...>]

I have checked into CVS the initial support for the Solaris
Sparc (Big Endian) platform. This was performed on an
Ultra 5 using Solaris 8. The only new addition, except for 
big endian support, is a new library under formatlib called
solaris_dev. The Makefile in the formatlib directory will now
call either linux_dev or solaris_dev depending on the platform
used. The library installed in both cases will be aflibDevFile.so.

Bruce Forsberg

[Osalp-dev] Makefile changes

[Bruce F. <for...@ad...>]

I have trashed the automake and autoconf experiment. After about 3 weeks
of tearing my hair out trying to understand it I have given up. Instead
I have replace it with a SIMPLE Makefile system. Since only Linux is
supported at the present this should be sufficient. To build you will
need to perform the following at the src directory:

make depend
make
make install (as root)

This will now only build the libraries and not the sample applications.
This has been checked into CVS. Also added is a version of the audiofile
library with modifications to make it work. Using the original one will
not work since it has been tailored to work for GNOME. It will build an
archive library and only use it for the libraries under formatlib. It
will
not install the audiofile library on your system. 

I will now start on a Solaris on Sparc port since I have obtained an
Ultra 5 workstation.

Bruce Forsberg

[Osalp-dev] automake and autoconf

[Bruce F. <for...@ad...>]

I have been trying the last couple of weeks to convert the
library over to the autoconf and automake GNU way of building
the library. I am having a very difficult time. The documentation
in my opinion is very bad. Most of it seems to consist of giving
the reason for this software existing instead of explaining how
it works. Several things I can't figure out.

1. I am including a local copy of libaudiofile library. I need to
   link a .a version with the formatlib libraries that use this library,
   wav, au, aifc, aiff. When I try to do this I get the error:
   /usr/bin/ld: .libs/libaflibWavFile.so.0.0.0: undefined versioned
symbol name clog@@GLIBC_2.1
/usr/bin/ld: failed to set dynamic section sizes: Bad value
collect2: ld returned 1 exit status
make: *** [libaflibWavFile.la] Error 1

   Anyone know what this means?                                       


2. I want the libraries under formatlib to only build .so files.
   I can't figure out how to do this. It also creates one shared
   object file and then several links to it with version numbers
   on the library such as .0 and .0.0.0. I don't want these
   version versions. How do I get rid of these?

Or better yet is there anyone that would like to fix up the library with
autoconf automake and libtool? I could check in what I have. I am not
really
up to fighting with these tools another month.

Any help would be appreciated.

Bruce Forsberg

[Osalp-dev] Revised Programmers Manual

[<for...@ad...>]

I have placed on the web page an updated version of the
Programmers Manual. It is available in both pdf and
Star Office formats.

Bruce Forsberg
http://osalp.sourceforge.net

Re: [Osalp-dev] Would like to join the project..

[<for...@ad...>]

Raphael Bossek wrote:
> 
> Hi,
> 
> I'm 23 years old and an official Debian GNU/Linux developer, so
> sometimes I intent to package this library ;) Why I intent to join this
> project? The answer is simple, we need a C++ stream-based audio
> library for our telephony products based on Linux (www.speech-
> design.com).
> 
> I know SOX and would like to port they C implementation to C++.
> 

I would be glad to have you as a developer. The project is hosted at
sourceforge so you will need to setup an account with them. It is
free. Then let me know your login name and I will add you as a
developer.

Right now the project is at the alpha stage and is close to going beta.
The Makefile structure needs to be completely redone as well I would
like to have a Solaris port before before going beta. 

One thing to keep in mind is that anything that goes into the main
library
must be able to be licensed as LGPL. Therefore only public domain or
LGPL
code can be used to put into the library. We can't even use GPL code.

Thanks,
Bruce Forsberg

[Osalp-dev] Would like to join the project..

[Raphael B. <rap...@so...>]

Hi,

I'm 23 years old and an official Debian GNU/Linux developer, so 
sometimes I intent to package this library ;) Why I intent to join this 
project? The answer is simple, we need a C++ stream-based audio 
library for our telephony products based on Linux (www.speech-
design.com).

I know SOX and would like to port they C implementation to C++.

--
Raphael Bossek <rap...@so...>

[Osalp-dev] More changes

[<for...@ad...>]

I have made more changes to the library. I fixed some more bug fixes
for the aflibAudioEdit class. This is for multiple inputs that are at
different sample rates. I have also fixed several memory bugs with
the library. This is thanks to the Electric Fence memory checker
tool. It works very well with C++ code. 

Since I have made so many changes since the last release I thing I
will be making another alpha release real soon.

Bruce Forsberg

[Osalp-dev] More changes

[Bruce F. <for...@ad...>]

I have made more changes. They are:

1) Added setItem and getItem as virtual to the aflibFile base class. It
   can be used to access file format specific data. Currently only one
   is implemented. It is AFLIB_DEV_ITEM_BUFFER. This will allow one
   to set the amount of buffer used in the driver. Currently for the
   linux device the buffer lengths are set to 0.5 seconds for record
   and 0.2 seconds for play. It can be changed with a call to setItem
   and should be made after the device is openned.

2) Fixed mulaw writing for au format in the audiofile library. Also
added
   mulaw and alaw support for WAV format in audiofile library and made
   changes in aflibAuFile and aflibWavFile for these. To support these
   will require a new audiofile library. These changes have been
forwarded
   to the author of the library and he is working on the changes.

3) For all file formats that create a pipe to a seperate process I now
   route stderr to /dev/null now. It was being printed out. 

4) Made bug fixes for aflibAudioEdit class and aflibAudio for when two
   parents are used for aflibAudioEdit. Also made fixes to editor sample
   program.

Bruce Forsberg

[Osalp-dev] More changes

[Bruce F. <for...@ad...>]

I have made more bug fixes and changes in preparation for 
going beta. These have been checked into CVS:

1) Fixed the dumpChain function in aflibChain so that it works again.

2) Fixed the mixing option in the example program prog

3) Fixed the passing of aflibConfig data in the aflibAudio base class.
It was not working correctly when an object in a chain was disabled.

4) Added the aflibAudioStereoToMono convience class. It is derived from 
class aflibAudioMixer and will convert a stereo to a mono signal. It
will convert both channels, channel 1 or channel 2. It will also pass
a mono signal straight through.

Bruce Forsberg

Re: [Osalp-dev] configure

[<for...@ad...>]

Tim Lorenz wrote:
> is there a special reason that osalp does not take use of configure?
> At last i didn't find any configure-stuff neither in release nor in
> cvs. O.K. - not strictly necessary, would just be a nice feature.
> 
> For example i don't want to install the patched version of audiofile
> in /usr/local and patching the makefile is OK for one person but in
> general i would be better to have a configuer-like mechanism, wouldn't
> it?
> 

The entire Makefile structure will be redone. I am probably going to
purchase a used Sun Sparc system so that I can do big endian testing
of the library and when I get the Sun system the Makefile system
will be redone. I have not decided if I am going to do the GNU
configure type of system or Imakefile type of system. Any ideas
anyone has would be appreciated. Also the "global" include files
will be moved to another directory instead of aflib and installed
to a install directory. An installer program is definitely on the
list with the Makefiles.

About the audiofile library. The author is busy and is not actively
maintaining the program. He also mentioned something about the Gnome
project with the audiofile library. I need to determine who if
anybody is going to support this library. If nobody steps forward
then I will have to. There are many forms of existing audio formats
in the library that are not supported. For instance for the au
format they don't support all the popular compression formats. I will
have to add these over time. This is the reason why I have a
copy with the library since bug fixes are not getting into the
audiofile library since they have not released a new version in a
while.

Bruce Forsberg

[Osalp-dev] configure

[Tim L. <Tim...@st...>]

Hello all,

is there a special reason that osalp does not take use of configure?
At last i didn't find any configure-stuff neither in release nor in
cvs. O.K. - not strictly necessary, would just be a nice feature.

For example i don't want to install the patched version of audiofile
in /usr/local and patching the makefile is OK for one person but in
general i would be better to have a configuer-like mechanism, wouldn't
it? 

bye
	/Tim

-- 
gpg-key key available at any openpgp-key-server
or simply write an email to: <mod...@ex...>

[Osalp-dev] Many more changes into CVS

[<for...@ad...>]

I have made many more changes in preparation for going beta. They have
been checked into CVS. Here is a list of new changes:

1) Moved reading of MP3 files to a seperate file called aflibMpgFile. 
The reading of mp3 was duplicated in both the blade and lame modules.
These now only encode mp3 files.

2) Changed the name of the aflibAudioClip object to be aflibEditClip.
Now all aflibAudio derived objects that can be used in a chain start
with aflibAudio.

3) Changed the comment formats in source files in library. This is so
the doxygen tool (www.doxygen.org) can be used to generate both html and
man pages for the library.

4) Changed the algorithm in the aflibDevFile module for the buffering
times used during record and playback. A default of 0.2 seconds is used
for playback and 0.5 seconds is used for record. I hope to make this
a user selectable value in the future. Different buffer sizes are used
depending on sample rate used.

5) Made changes to the editor sample application to get it working
again.

6) Changed the auto recognition when reading an audio file. Now one can
enter more than one MAGIC line per entry. This is since some formats
can have different signatures like MP3s. Also added two new flags to
be used in a MAGIC line. A -1 indicates that the data following can be
at any location in the file. It will now search for the following
character sequences. A -2 stops the search mode. For instance in some
MP3 files they have a header of RIFF WAVE, the same as WAV format. Now
somewhere else will be a "data" field followed by the MP3 data. Thus
we can enter -1(d) 1(a) 2(t) 3(a) -2(a). The other numbers after a -1
are all relative fields to where the -1 character is found. The
character
after -2 is ignored. 

More changes will be comming.

Bruce Forsberg

[Osalp-dev] Memory caching improved

[<for...@ad...>]

I have checked into CVS the following files:

aflib/aflibMemCache.cc
aflib/aflibMemCache.h
aflib/aflibMemNode.cc
aflib/aflibMemNode.h

These files improve the performance of the memory
caching capability substantially. This will go into
the next release which is a ways off but these are
available from CVS.

Bruce Forsberg

[Osalp-dev] documentation generator

[<for...@ad...>]

I have started work on documentation for the library. I am 
currently looking at a tool called doxygen (www.doxygen.org).
It will generate man pages and html as well as others. The
html output looks pretty impressive with hyper links to take
you to base classes and stuff. Once this documentation is in
place to document the member functions then they will be removed
from the programmers manual and the manual will become more
of what it is suppose to be. The member functions may be an
appendix in the manual. 

If anyone has any suggestions on a tool to generate man pages
from comments in C++ source code then let me know. I believe
that someone emailed me awhile ago about something but that was
when I was using Star Office to read my email and it decided one
day to eat my email.

Thanks,
Bruce Forsberg

[Osalp-dev] Mixing class checked in

[<for...@ad...>]

I have finished work on the Mixing class. It is called
aflibAudioMixer. It will mix one or more inputs into
one output with as many channels in the output as
desired. Also different inputs can be added to the
mixing class. It will use the aflibAudio base class
and will automatically convert endian, data size, and
sample rate. The sample rate choosen will be the
greatest of all the inputs. In order to support this
the aflibAudio base class process function was changed
to support objects will multiple parents. The mixing
class uses this.

By popular request I have also started work on a sample
program in the prog directory. It is a command line
program. Currently it has just been started. It will
play, record, mix two audio signals, and printout
info for an audio file. If anyone would like to take this
up as a project let me know. Otherwise if no one comes 
forward I will add a little to it each release.

Bubble help was added to the player sample application.
Also some other small changes were made. This has all been
checked into CVS. I will test and soon have a 0.5 release.

Thanks for everyones patience with this library. I am close
to going Beta.

Thanks,
Bruce Forsberg

[Osalp-dev] V 0.4 released

[Bruce F. <for...@ad...>]

V 0.4 has been released and any bug fixes found during testing have
been checked into CVS. I am now starting on a mixing base class
derived from aflibAudio.

Bruce Forsberg

[Osalp-dev] Memory Caching checked into CVS

[Bruce F. <for...@ad...>]

I have finished the memory caching work. It is not an efficient
algorithm but I will improve it with time. The aflibAudioSampleRateCvt
class now uses this new memory caching mechanism by default. It is
not as efficient as the built in mechanism. The old built in
method can still be accessed by disabling the memory caching for
this object by a call to the base class setCacheEnable(FALSE). I
will now test these changes and make a release 0.4 alpha. When this
is done I will start work on a mixing base class and several
derived classes from this. After this a Makefile restructuring will
occur with the possibility of a Solaris port. When this is done I
will go beta with this library and fix alot of little things left
undone. Then a 1.0 release.

For more information on the memory caching changes done see the CHANGES
file in the CVS repository. I will also update the programmers manual
and will release it in wordperfect and pdf format instead of StarOffice.

Bruce

[Osalp-dev] FFT class

[Bruce F. <for...@ad...>]

I have changed the FFT algorithm in the aflibFFT class. The previous one
was
GPL and not LGPL. I have found a public domain algorithm and used this
one
instead. This changes the license of the library and makes it completely
LGPL
now. These have been checked into CVS.

Bruce Forsberg