> 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
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
