Can libsox read from other sources besides named files & stdin/stdout?

[Philippe Chaintreuil-2]

Note: this question is about libsox, not the sox command line program.

        Can libsox read from other sources besides named files and
stdin/stdout?  Is there a way to get it to read from a memory buffer or
some non-file base mechanism?

        Thanks!

                                -- Philippe Chaintreuil

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Sox-users mailing list
Sox-users@...
https://lists.sourceforge.net/lists/listinfo/sox-users

[robs-5]

--- On Fri, 11/9/09, Philippe Chaintreuil >     Can libsox read from other sources
> besides named files and
> stdin/stdout?  Is there a way to get it to read from a
> memory buffer or
> some non-file base mechanism?

Not currently, but it's coming very soon -- it's already in CVS.
Only proviso is POSIX 200x libc.

Cheers,
Rob


     


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Sox-users mailing list
Sox-users@...
https://lists.sourceforge.net/lists/listinfo/sox-users

[Philippe Chaintreuil-2]

On 9/12/09 6:37 PM, robs wrote:
> --- On Fri, 11/9/09, Philippe Chaintreuil>       Can libsox read from other sources
>> besides named files and
>> stdin/stdout?  Is there a way to get it to read from a
>> memory buffer or
>> some non-file base mechanism?
>
> Not currently, but it's coming very soon -- it's already in CVS.
> Only proviso is POSIX 200x libc.

        Hmm, interesting, I've never used fmemopen() or open_memstream()....

        Can these be used for actual streams (ie, like a pipe/FIFO; "unlimited"
memory incrementally passing through a fixed memory pool), or are they
just inheriting that moniker from FILE*'s "file stream" name?

--
    .----------.    ,----------== Peep ==----------,
   /  .-.  .-.  \   `-== (Philippe Chaintreuil) ==-`
  /   | |  | |   \   On The Other Side Of The Wall!
  \   `-'  `-'  _/      FidoNet Netmail Address:
  /\     .--.  / |             1:2613/118
  \ |   /  /  / /          InterNet  Address:
  / |  `--'  /\ \        peep@...
   /`-------'  \ \  --PiCTuRe By aN uNKNoWN aSCii aRTiST--
      "We're just two lost souls swimming in a fish bowl..."

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Sox-users mailing list
Sox-users@...
https://lists.sourceforge.net/lists/listinfo/sox-users

[robs-5]

--- On Sun, 13/9/09, Philippe Chaintreuil <sox-users_sourceforge-list_peep@...> wrote:
>     Hmm, interesting, I've never used
> fmemopen() or open_memstream()....
>
>     Can these be used for actual streams
> (ie, like a pipe/FIFO; "unlimited"
> memory incrementally passing through a fixed memory pool),
> or are they
> just inheriting that moniker from FILE*'s "file stream"
> name?

Well you don't need to use them directly; their use is internal to libSoX, but their behaviour is pretty much exposed by libSoX:
 * fmemopen creates a FILE object stored in a fixed-size buffer.
 * open_memstream creates a FILE object in a buffer whose size is limited only in the same way that realloc is limited.

HTH,
Rob


     


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Sox-users mailing list
Sox-users@...
https://lists.sourceforge.net/lists/listinfo/sox-users

[Douglas Cook-2]

>>     Can these be used for actual streams
>> (ie, like a pipe/FIFO; "unlimited"
>> memory incrementally passing through a fixed memory pool),
>> or are they
>> just inheriting that moniker from FILE*'s "file stream"
>> name?
>
> Well you don't need to use them directly; their use is internal to libSoX, but their behaviour is pretty much exposed by libSoX:
>  * fmemopen creates a FILE object stored in a fixed-size buffer.
>  * open_memstream creates a FILE object in a buffer whose size is limited only in the same way that realloc is limited.

Could probably be simulated internally to SoX if fmemopen isn't
available using tmpfile (relatively easy), or externally to SoX using
mktmp.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Sox-users mailing list
Sox-users@...
https://lists.sourceforge.net/lists/listinfo/sox-users

[Philippe Chaintreuil-2]

robs wrote:

> --- On Sun, 13/9/09, Philippe Chaintreuil
> <sox-users_sourceforge-list_peep@...> wrote:
>> Hmm, interesting, I've never used fmemopen() or
>> open_memstream()....
>>
>> Can these be used for actual streams (ie, like a pipe/FIFO;
>> "unlimited" memory incrementally passing through a fixed memory
>> pool), or are they just inheriting that moniker from FILE*'s "file
>> stream" name?
>
> Well you don't need to use them directly; their use is internal to
> libSoX, but their behaviour is pretty much exposed by libSoX: *
> fmemopen creates a FILE object stored in a fixed-size buffer. *
> open_memstream creates a FILE object in a buffer whose size is
> limited only in the same way that realloc is limited.

Hey Rob,

        I was playing around with this code you added in CVS, and I found
something a little odd.
        In open_write() you pass the mode as "w+b":

-----------------------------------------------------------------
       ft->fp =
#ifdef HAVE_FMEMOPEN
         buffer? fmemopen(buffer, buffer_size, "w+b") :
         buffer_ptr? open_memstream(buffer_ptr, buffer_size_ptr) :
#endif
-----------------------------------------------------------------

        On my system, this does not actually open the buffer as binary (even
though I would think it would), and the man page for fmemopen kind of
backs that up:

-----------------------------------------------------------------
"Since glibc 2.9, the letter 'b' may be specified as the second
character in  mode.   This  provides  "binary"  mode[...]"
-----------------------------------------------------------------

        It appears that it's not in binary mode, as I get libsox to write 2048
samples out as a-law (1 byte = 1 sample) and even after an fflush,
ftello(out->fp) says it's at 2047, and the last entry in the buffer
contains a '\0'.

        If I change the mode to "wb+" it acts as I would expect: 2048 samples
returns an offset of 2048.

        So I'd say, that for some reason there exists a libc (the one I'm
using) that actually does require that the "b" is the 2nd character in
the string, even if fopen() doesn't care if the "b" is in the 2nd or 3rd
position.

        Is there a reason for the "+" (read-write)?  You didn't use it in
open_read().

        Thanks.

                                -- Philippe Chaintreuil


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Sox-users mailing list
Sox-users@...
https://lists.sourceforge.net/lists/listinfo/sox-users