sox-users

[SoX-users] Real-time input buffering

[<aa...@bo...>]

   I have an application which analyses an audio stream
on the fly.  (You could say real-time).
The analysis can have varying processor load, depending
on the content of the audio stream.

    I CANNOT loose ANY audio data.  However, when processing
gets behind, I need to be able to BUFFER incoming data.
Its OK for my processing to get several SECONDS behind the
real-time stream, but I cannot just dump audio samples when this
happens.  I need to buffer them up, and have the analysis catch up
to the real-time stream later.

     Can anybody provide advise about how to go about this.
Can I use SOX?  Can I modify SoX (make large input buffer?)
to handle this?   Can I learn how to do this from the SoX source?
Should I be looking into Real-Time linux extensions to maintain
a LARGE circular buffer of incoming audio data in Real-Time/Kernel space
shared memory?   If so...  any suggestions about where to learn
about this?

    SoX must have SOME buffering in order to be able to operate
under -t ossdsp.  How does this work?  Could my problem be solved
simply by increasing the size of this buffer?

                   aaron

Re: [SoX-users] Real-time input buffering

[Leigh S. <le...@to...>]

You may want to consider portaudio.com which is a cross platform streaming 
audio API that has some Linux support.
--
Dr. Leigh Smith
tomandandy
mailto:le...@to...
http://www.tomandandy.com

Re: [SoX-users] Real-time input buffering

[Chris B. <Chr...@fn...>]

Aaron Birenboim wrote:
> 
>    I have an application which analyses an audio stream
> on the fly.  (You could say real-time).
> The analysis can have varying processor load, depending
> on the content of the audio stream.
> 
>     I CANNOT loose ANY audio data.

If you must write a custom program then you might look on freshmeat.net
for the program called wavrec.  It is a threaded application and so uses
1 thread for reading audio data and 1 for writting audio data.  This
allows the reading portion to start queueing buffers when the writing is
not fast enough.


>     SoX must have SOME buffering in order to be able to operate
> under -t ossdsp.  How does this work?  Could my problem be solved
> simply by increasing the size of this buffer?

Unfortunately, SoX does not use any buffering beyond what the OSS driver
supports and what libc provides for I/O.  This just happens to be good
enough for coping from disk<->soundcard on most modern fast computers in
most cases.

Re: [SoX-users] Real-time input buffering

[Aaron B. <aa...@bo...>]

Chris Bagwell wrote:
> 
> Aaron Birenboim wrote:
> >
> >    I have an application which analyses an audio stream
> > on the fly.  (You could say real-time).
> > The analysis can have varying processor load, depending
> > on the content of the audio stream.
> >
> >     I CANNOT loose ANY audio data.
> 
> If you must write a custom program then you might look on freshmeat.net
> for the program called wavrec.  It is a threaded application and so uses

Thanks.  I will look that way.  I can see that reading from
ossdsp is really, really easy, and that would be easy enough to do.

If I can bother you again, just a little....
Perhaps borrow from your linux audio experience...

Will a reader theread with a large FIFO be sufficient?
Might I be forced to go to RT-Linux and use an rt-fifo?
(I hope not.  I'm tempted to just implement the multi-threaded
approach and show emperically that it is "good enough", even if
its not guaranteed to avoid data loss in ANY situation)

It might be neat-oh to add the reader thread to SoX, so that
it could still be used as a front-end to an app like mine.
However, I can understand that it might be contrary to the
goal of keeping SoX as simple as possible.

-- 
Aaron Birenboim | Black holes are where G-d divided
Albuquerque, NM |      by zero.
aa...@bo...  |
boim.com/~aaron |                      -Steven Wright

Re: [SoX-users] Real-time input buffering

[Enrique V. <ev...@it...>]

On Fri, 4 May 2001, Aaron Birenboim wrote:

> Will a reader theread with a large FIFO be sufficient?
> Might I be forced to go to RT-Linux and use an rt-fifo?
> (I hope not.  I'm tempted to just implement the multi-threaded
> approach and show emperically that it is "good enough", even if
> its not guaranteed to avoid data loss in ANY situation)

A large FIFO *is* sufficient.  For pourposes similar to yours, 
I have been using for years a modified version of "brec/bplay", 
an old popular FIFO-based stream audio front-end.  Even with 
old, heavily loaded P100 machines, I have never experienced 
any problem working at 41khz sampling rates, stereo.

> It might be neat-oh to add the reader thread to SoX, so that
> it could still be used as a front-end to an app like mine.
> However, I can understand that it might be contrary to the
> goal of keeping SoX as simple as possible.

Given that the idea of splitting SOX into small, specialiced
programs (like netpbm) was discarded long time ago,  I also 
support the idea of adding some circular buffering to SoX! 

Best,

Enrique.