[PD] packOSC "BLOB"

Daniel Wilcox danomatika at gmail.com
Mon May 11 15:44:42 CEST 2009


> iirc, for the very project the decoding is done outside of Pd anyhow (on
> specialized hardware), so the problem of [unpackOSC] not knowing what to
> do with a blob is a minor issue here. (and the use of specialized
> hardware is the reason why data (low-resolution fixed-point numbers)
> should actually be packed in a blob rather than floating-point).

The decoding should be done on a microcontrollerboard and in puredata
> too. The audio data will be sent over ethernet to the target device,
> there it should be decoded and played back.
> The problem lies at the ethernet layer, where only a 10Mbit/s wire is
> available. At a Samplingrate of 44100Hz and a word width of 32bit are
> only about 7 channels (without overhead,...) possible.
> So it would be fine to reduce the resolution from 32bit floating point
> to maybe 16bit or even 8bit fixed point (while 32bit floating point is
> still selectable in case of better hardware).
> Sending 16bit or 8bit samples over OSC (without losing the gained bit
> width (OSC-data-types are at least 32bit)) will require an arbitrary
> alignment of the bits within each OSC-data-argument, where BLOB comes
> into play.
>
> > i still think (see above) that even [packOSC] cannot provide a
> > consistent interface to pack blobs into an osc message that is
> > sufficiently more simple to use than manually constructing OSC messages.
>
> Thanks
>
> Wolfgang


Sorry if this is a dumb question ... but why would you want to do this in
PD, why not use a hardware solution as it would be much faster?   Something
like Cobranet, ie digital audio over Cat5:

http://www.audioscience.com/internet/products/sound_cards/asi54xx.htm

-- 
Dan Wilcox
danomatika
www.robotcowboy.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20090511/fc8bcf04/attachment.htm>


More information about the Pd-list mailing list