> but it isn't going to be quite so low-bitrate when you
> have IP (or some other) packets encapsulating it.
Most packet systems, such as PPP and SLIP, want at least 9600 baud to play
ball. Traditionally, low bandwidth systems like those are just open
streams. The protocols built on top of those - old stalwarts like YModem/G,
Kermit, and so forth - do admittedly generally chunk data, but the headers
inbetween chunks are often no more than a CRC-32 and a byte allowing
out-of-stream escaping or very simple commands.
> transmit and receive data over a radio link
> what I do know is they are looking at transmitting across a 2400baud
connection
Forgive the presumption, but why don't you just send voice over the radio
link? Short of encryption, which is best handled elsewise anyway, I can't
think of a good reason to create a data stream, losing a lot of the
applicable range of the audio stream to modulation steps, to facilitate the
passing of hugely lossily compressed audio, losing massive fidelity to fit
into the data stream. I mean, the brain's already got some fairly advanced
error correction hardware up and running. Use the radio *as* *a* *radio*.
OTOH, if you're just being allowed ~1/4 of a 9600 baud stream, and the other
7200 baud is going to instrumentation, or something wacky like that, then
I'm just talking for No Good Reason (tm). Would you be so kind as to tell
us more about what you're up to, and why you've chosen a data stream
over an
audio channel for audio signal?
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'speex-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
