Hi again,
I was a little surprised that your connection couldn't handle the
12.3 Mbit/s for the complex 192ksam/s,
so I had a look at the source code of the fcd_source; that
basically wraps an audio source.
Surprise was mine when I found out that there's no complex
192ksam/s at all... The audio device is set to
deliver 96ksam/s of stereo, that gets converted to 96ksam/s of
complex samples.
Therefore, the data rate is only 6.144Mbit/s for your wifi link...
Not very much.
Anyway, what (due to that being the default data type in GR), the
audio source inside the fcd_source converts
the 16bit adc resolution of your dongle to 32bit floats; so,
instead of streaming those using GR over your network,
you can also just stream raw audio data from your beaglebone to
your receiver computer, something like
arecord --format={try something like S16_LE, U16_LE, see man
arecord} -D beagleboardaudiodev --file-type=raw --channels=2
--disable-resample --disable-channels --disable-format |ncat host
port
and
ncat -l port > rxfifo
on the receiver.
And then reading that file using a file source, converting the
16bit signed/unsigned ints to floats, packing them into complexes
and using that for your receiver; note, however, that a lost
packet is not tolerable in this case, you will end up with corrupt
samples if lost bytes are not multiples of 4...
To the TCP/UDP sources in GR: they do what they were designed for,
dropping samples from an outside source makes sense if your
flowgraph can't handle the load, since there is no such thing as
the infinite buffer or the infinite acceptance of latency; not so
much for your fifos. They start blocking when you ram+swap is used
up...
Greetings
Marcus
On 08/10/2013 03:15 AM, Vanush Vaswani wrote: