Re: [Discuss-gnuradio] Streaming IQ File Compression

[Dave NotTelling]

Marcus,

 Thanks for the idea anyway :)  It sounded like a really neat outside
the box idea.


I ran some quick tests with FLAC and found that it does a really good job
compressing a constant filtered gaussian noise output.  I just created a
flow graph with:

 fast noise source [float] -> low pass filter [float] -> float to short
-> file sink

The filter was just there so that the spectrum wasn't completely flat.
Running the signal through FLAC with little endian, 16 bit, single channel
resulted in a 2GB file ending up at ~ 400 MB.  But, that was just a
constant signal.  I need to throw some 900 MHz captures through to see how
that works.

I also found someone who modified FLAC to be multithreaded [1] as well as a
CUDA implementation (windows only) [2]

[1] https://www.akalin.com/parallelizing-flac-encoding
[2] http://www.cuetools.net/wiki/FLACCL

On Sun, Jul 17, 2016 at 7:49 AM, Marcus Müller 
wrote:

> Well, having wasted a couple of hours of sleep time on this, maybe you
> shouldn't do the logarithmic storage... at its core its the same idea as
> storing floating point, but with a fixed mantissa.
>
> The mathematical effects of the "rounding to the nearest exponential step"
> on superimposed sinusoids of different amplitude are … funky.
>
> Best regards,
>
> Marcus
>
> On 16.07.2016 21:57, Juha Vierinen wrote:
>
> Can you reduce the number of bits that you are using?
>
> With radar signals, the receiver noise most of the time excites only about
> 8 bits out of 16. Ground clutter or meteor echoes excite nearly all of the
> bits occasionally, so I can't just truncate to 8 bits. In this case, bzip2
> actually does a pretty good job of getting rid of the 8/16 most significant
> bits that are zero most of the time. Thus, I get a compression ratio close
> to 50% when using sc16. pbzip2 is a good tool for doing parallel
> compression on files.
>
> juha
>
> On Sat, Jul 16, 2016 at 3:59 AM, Dave NotTelling 
> wrote:
>
>> Anyone have experience with streaming 100+ MSPS of 16 bit IQ data through
>> a compression tool and then to disk?  I'd like to be able to take really
>> wide band snaps for several minutes.  Currently that would take up 16 * 2 *
>> SAMP_RATE bits per second.  So, for 200 MSPS that would end up being 800
>> MBytes/s.  That rate eats up a hard drive pretty quickly.  Running it
>> through gzip by way of pigz was my first thought, but even on an 8 core
>> Intel machine pigz just can't keep up.  I can sustain maybe 300 MBytes/s
>> but that's it.  And I know it's not a hard disk limitation as the M.2 drive
>> I am using can easily sustain 800 MBytes/s of uncompressed data.
>>
>> Thoughts?
>>
>> Thank you!
>>
>>
>> -Dave
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Streaming IQ File Compression

[Marcus Müller]

Well, having wasted a couple of hours of sleep time on this, maybe you
shouldn't do the logarithmic storage... at its core its the same idea as
storing floating point, but with a fixed mantissa.

The mathematical effects of the "rounding to the nearest exponential
step" on superimposed sinusoids of different amplitude are … funky.

Best regards,

Marcus


On 16.07.2016 21:57, Juha Vierinen wrote:
> Can you reduce the number of bits that you are using?
>
> With radar signals, the receiver noise most of the time excites only
> about 8 bits out of 16. Ground clutter or meteor echoes excite nearly
> all of the bits occasionally, so I can't just truncate to 8 bits. In
> this case, bzip2 actually does a pretty good job of getting rid of the
> 8/16 most significant bits that are zero most of the time. Thus, I get
> a compression ratio close to 50% when using sc16. pbzip2 is a good
> tool for doing parallel compression on files. 
>
> juha
>
> On Sat, Jul 16, 2016 at 3:59 AM, Dave NotTelling  > wrote:
>
> Anyone have experience with streaming 100+ MSPS of 16 bit IQ data
> through a compression tool and then to disk?  I'd like to be able
> to take really wide band snaps for several minutes.  Currently
> that would take up 16 * 2 * SAMP_RATE bits per second.  So, for
> 200 MSPS that would end up being 800 MBytes/s.  That rate eats up
> a hard drive pretty quickly.  Running it through gzip by way of
> pigz was my first thought, but even on an 8 core Intel machine
> pigz just can't keep up.  I can sustain maybe 300 MBytes/s but
> that's it.  And I know it's not a hard disk limitation as the M.2
> drive I am using can easily sustain 800 MBytes/s of uncompressed
> data.
>
> Thoughts?
>
> Thank you!
>
>
> -Dave
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Streaming IQ File Compression

[Dave NotTelling]

Chris,

 Excellent, then I will start benchmarking tomorrow :)

Thanks!

On Sat, Jul 16, 2016 at 9:35 PM, Chris Kuethe 
wrote:

> Flac doesn't really need to know what the actual sample rate is; you
> could tell it 500e3 and you should get the same data out after
> compressing and decompressing it.
>
> On Sat, Jul 16, 2016 at 11:20 AM, Dave NotTelling 
> wrote:
> > Marcus & Dan,
> >
> >  Thank you very, very much for the detailed information!
> >
> > Dan: That's exactly what I thought when going into this at first.  But, I
> > decided to give gzip a shot just to see how well it did.  Turns out that
> (at
> > least for bursty environments) it almost halves the size of the original
> > file.  It should be noted that the file was in fc32 format so there were
> > likely a lot of unused bits there (or so I guess).
> >
> > Marcus: I have been giving thought to truncating some of the bits.
> Going as
> > far as thinking about dropping from sc16 to sc8.  I have worked with 8
> bit
> > sample files before and had plenty of success demodulating, so I'm
> thinking
> > that it might be an okay path to go down.  Dynamic range goes to hell,
> but
> > it it's worked in the past...  I think that re-packing as 12 bit would
> give
> > considerable space savings without a lot of CPU overhead.  I'll have to
> give
> > that one a go :)  I really like your idea of using FLAC.  Just a quick
> > Google search netted
> http://www.rtl-sdr.com/compressing-filtering-iq-data/.
> > What concerns me is that when I tried to use the command line flac in
> Ubuntu
> > it said that the sample rate must be between 1 and 655349 Hz.  I'll have
> to
> > poke around at it to see what happens when I set an incorrect bit rate
> > (maybe a multiple of will be fine?).
> >
> > Thank you both!
> >
> > -Dave
> >
> > On Sat, Jul 16, 2016 at 5:14 AM, Marcus Müller  >
> > wrote:
> >>
> >> Ah!
> >>
> >> On 16.07.2016 11:04, Marcus Müller wrote:
> >> > and maybe, but this is really speculation, you can just modify the
> >> > error calculation to just ignore the 4 lower bits of the actual sample
> >> > data, and safe another few percents of data volume.
> >> Yeah, there's a FLAC__stream_encoder_set_bits_per_sample[0] function--
> >> guess that you don't need to modify anything. Also, there's a whole
> >> listing of things .._set_compression_level[1] sets internally. This
> >> approach (using FLAC as lossless waveform encoder) might be really
> >> interesting.
> >>
> >>
> >>
> >> [0]
> >>
> >>
> https://xiph.org/flac/api/group__flac__stream__encoder.html#gabfa3c989377785cda7c496b69dcb98cb
> >> [1]
> >>
> >>
> https://xiph.org/flac/api/group__flac__stream__encoder.html#ga07fc8c7806381a055a1eef26387e509f
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
>
> --
> GDB has a 'break' feature; why doesn't it have 'fix' too?
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Streaming IQ File Compression

[Chris Kuethe]

Flac doesn't really need to know what the actual sample rate is; you
could tell it 500e3 and you should get the same data out after
compressing and decompressing it.

On Sat, Jul 16, 2016 at 11:20 AM, Dave NotTelling  wrote:
> Marcus & Dan,
>
>  Thank you very, very much for the detailed information!
>
> Dan: That's exactly what I thought when going into this at first.  But, I
> decided to give gzip a shot just to see how well it did.  Turns out that (at
> least for bursty environments) it almost halves the size of the original
> file.  It should be noted that the file was in fc32 format so there were
> likely a lot of unused bits there (or so I guess).
>
> Marcus: I have been giving thought to truncating some of the bits.  Going as
> far as thinking about dropping from sc16 to sc8.  I have worked with 8 bit
> sample files before and had plenty of success demodulating, so I'm thinking
> that it might be an okay path to go down.  Dynamic range goes to hell, but
> it it's worked in the past...  I think that re-packing as 12 bit would give
> considerable space savings without a lot of CPU overhead.  I'll have to give
> that one a go :)  I really like your idea of using FLAC.  Just a quick
> Google search netted http://www.rtl-sdr.com/compressing-filtering-iq-data/.
> What concerns me is that when I tried to use the command line flac in Ubuntu
> it said that the sample rate must be between 1 and 655349 Hz.  I'll have to
> poke around at it to see what happens when I set an incorrect bit rate
> (maybe a multiple of will be fine?).
>
> Thank you both!
>
> -Dave
>
> On Sat, Jul 16, 2016 at 5:14 AM, Marcus Müller 
> wrote:
>>
>> Ah!
>>
>> On 16.07.2016 11:04, Marcus Müller wrote:
>> > and maybe, but this is really speculation, you can just modify the
>> > error calculation to just ignore the 4 lower bits of the actual sample
>> > data, and safe another few percents of data volume.
>> Yeah, there's a FLAC__stream_encoder_set_bits_per_sample[0] function--
>> guess that you don't need to modify anything. Also, there's a whole
>> listing of things .._set_compression_level[1] sets internally. This
>> approach (using FLAC as lossless waveform encoder) might be really
>> interesting.
>>
>>
>>
>> [0]
>>
>> https://xiph.org/flac/api/group__flac__stream__encoder.html#gabfa3c989377785cda7c496b69dcb98cb
>> [1]
>>
>> https://xiph.org/flac/api/group__flac__stream__encoder.html#ga07fc8c7806381a055a1eef26387e509f
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Streaming IQ File Compression

[Marcus Müller]

Hello Juha,

idea: if Dave's distribution of amplitudes was a little more benign than
the Radar near/far problem, and he would favor full resolution when the
signal is weak, but could live with a bit of degradation due to
quantization when the signal is strong, what about storing a logarithm
of the I and Q magnitudes instead of their linear value? That way, he
could get the same weak-signal-resolution with less bits, and only
suffer inaccuracies due to quantization for situations where signal is
strong, anyway.

Best regards,
Marcus

On 16.07.2016 21:57, Juha Vierinen wrote:
> Can you reduce the number of bits that you are using?
>
> With radar signals, the receiver noise most of the time excites only
> about 8 bits out of 16. Ground clutter or meteor echoes excite nearly
> all of the bits occasionally, so I can't just truncate to 8 bits. In
> this case, bzip2 actually does a pretty good job of getting rid of the
> 8/16 most significant bits that are zero most of the time. Thus, I get
> a compression ratio close to 50% when using sc16. pbzip2 is a good
> tool for doing parallel compression on files. 
>
> juha
>
> On Sat, Jul 16, 2016 at 3:59 AM, Dave NotTelling  > wrote:
>
> Anyone have experience with streaming 100+ MSPS of 16 bit IQ data
> through a compression tool and then to disk?  I'd like to be able
> to take really wide band snaps for several minutes.  Currently
> that would take up 16 * 2 * SAMP_RATE bits per second.  So, for
> 200 MSPS that would end up being 800 MBytes/s.  That rate eats up
> a hard drive pretty quickly.  Running it through gzip by way of
> pigz was my first thought, but even on an 8 core Intel machine
> pigz just can't keep up.  I can sustain maybe 300 MBytes/s but
> that's it.  And I know it's not a hard disk limitation as the M.2
> drive I am using can easily sustain 800 MBytes/s of uncompressed
> data.
>
> Thoughts?
>
> Thank you!
>
>
> -Dave
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Streaming IQ File Compression

[Juha Vierinen]

Can you reduce the number of bits that you are using?

With radar signals, the receiver noise most of the time excites only about
8 bits out of 16. Ground clutter or meteor echoes excite nearly all of the
bits occasionally, so I can't just truncate to 8 bits. In this case, bzip2
actually does a pretty good job of getting rid of the 8/16 most significant
bits that are zero most of the time. Thus, I get a compression ratio close
to 50% when using sc16. pbzip2 is a good tool for doing parallel
compression on files.

juha

On Sat, Jul 16, 2016 at 3:59 AM, Dave NotTelling 
wrote:

> Anyone have experience with streaming 100+ MSPS of 16 bit IQ data through
> a compression tool and then to disk?  I'd like to be able to take really
> wide band snaps for several minutes.  Currently that would take up 16 * 2 *
> SAMP_RATE bits per second.  So, for 200 MSPS that would end up being 800
> MBytes/s.  That rate eats up a hard drive pretty quickly.  Running it
> through gzip by way of pigz was my first thought, but even on an 8 core
> Intel machine pigz just can't keep up.  I can sustain maybe 300 MBytes/s
> but that's it.  And I know it's not a hard disk limitation as the M.2 drive
> I am using can easily sustain 800 MBytes/s of uncompressed data.
>
> Thoughts?
>
> Thank you!
>
>
> -Dave
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Streaming IQ File Compression

[Dave NotTelling]

Marcus & Dan,

 Thank you very, very much for the detailed information!

Dan: That's exactly what I thought when going into this at first.  But, I
decided to give gzip a shot just to see how well it did.  Turns out that
(at least for bursty environments) it almost halves the size of the
original file.  It should be noted that the file was in fc32 format so
there were likely a lot of unused bits there (or so I guess).

Marcus: I have been giving thought to truncating some of the bits.  Going
as far as thinking about dropping from sc16 to sc8.  I have worked with 8
bit sample files before and had plenty of success demodulating, so I'm
thinking that it might be an okay path to go down.  Dynamic range goes to
hell, but it it's worked in the past...  I think that re-packing as 12 bit
would give considerable space savings without a lot of CPU overhead.  I'll
have to give that one a go :)  I really like your idea of using FLAC.  Just
a quick Google search netted
http://www.rtl-sdr.com/compressing-filtering-iq-data/.  What concerns me is
that when I tried to use the command line flac in Ubuntu it said that the
sample rate must be between 1 and 655349 Hz.  I'll have to poke around at
it to see what happens when I set an incorrect bit rate (maybe a multiple
of will be fine?).

Thank you both!

-Dave

On Sat, Jul 16, 2016 at 5:14 AM, Marcus Müller 
wrote:

> Ah!
>
> On 16.07.2016 11:04, Marcus Müller wrote:
> > and maybe, but this is really speculation, you can just modify the
> > error calculation to just ignore the 4 lower bits of the actual sample
> > data, and safe another few percents of data volume.
> Yeah, there's a FLAC__stream_encoder_set_bits_per_sample[0] function--
> guess that you don't need to modify anything. Also, there's a whole
> listing of things .._set_compression_level[1] sets internally. This
> approach (using FLAC as lossless waveform encoder) might be really
> interesting.
>
>
>
> [0]
>
> https://xiph.org/flac/api/group__flac__stream__encoder.html#gabfa3c989377785cda7c496b69dcb98cb
> [1]
>
> https://xiph.org/flac/api/group__flac__stream__encoder.html#ga07fc8c7806381a055a1eef26387e509f
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Streaming IQ File Compression

[Marcus Müller]

Ah!

On 16.07.2016 11:04, Marcus Müller wrote:
> and maybe, but this is really speculation, you can just modify the
> error calculation to just ignore the 4 lower bits of the actual sample
> data, and safe another few percents of data volume.
Yeah, there's a FLAC__stream_encoder_set_bits_per_sample[0] function--
guess that you don't need to modify anything. Also, there's a whole
listing of things .._set_compression_level[1] sets internally. This
approach (using FLAC as lossless waveform encoder) might be really
interesting.



[0]
https://xiph.org/flac/api/group__flac__stream__encoder.html#gabfa3c989377785cda7c496b69dcb98cb
[1]
https://xiph.org/flac/api/group__flac__stream__encoder.html#ga07fc8c7806381a055a1eef26387e509f

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Streaming IQ File Compression

[Marcus Müller]

> If there's a lot of white noise, you won't get much compression
Alas, Entropy is killing compression.

So yeah, if you anyhow can, try to reduce bandwidth by filtering and
decimating.

You can also just "round" or even "throw away" bits – at 100MS/s
(presumably coming from a X310 running at a 200MS/s physical sampling
rate), the effect of oversampling (only by a factor of 2) will not have
filled up all the bits in your digital numbers with meaningful signal –
in fact, you basically gain 1 bit per oversampling of 2, so that's 15bit
(X310's ADC is 14 bit) only – now, buffering sixteen shorts, repacking
only their upper 15 bits into a 30 byte chunk of data, instead of a 32
byte chunk, might not really be the performance leap you're looking for.
But the effective number of bits you'll get from that ADC might be even
lower (see the ADS62P48 datasheet), and that's not even accounting for
noise floor – so if you keep only 12 of the 16 bit, you could actually
get a "free" storage bandwidth reduction of 4/16th=25%; better than
nothing (and much nicer to implement on a CPU than 15 out of 16), and
for all we can say about representing the original analog signal, still
loss-less. Every further bit you save will add quantization noise – in
fact, that should be around 6 dB per bit you save.

I think the truth here is that Dan is absolutely right: you need to
store the /information/ contained in a signal, not necessarily the
signal itself (because the signal might contain noise and things that
are irrelevant). Now, if you've got lots of CPU to spare, and knowledge
on what you're looking for, one would possibly go for things like sparse
representations of your signal (compressive sensing), or a different
quantization of coefficients of your signal under a different base (e.g.
after a DFT or wavelet transform) – which would then be a lossy
representation of your signal (and very close to what lossy audio codecs
essentially do).

Speaking of audio codecs: Maybe the lossless FLAC algorithm is something
for you; I haven't used libFLAC in what seems to be forever, but in
general, it has a linear predictor for "upcoming samples", and stores
the differences between actual samples and predicted samples,
compressing these with a Huffmanesque code. This works well because
audio samples tend to be quite correlated. But maybe the majority of
your sample data is, too.
I presume some work went into making that algorithm run fast – and
maybe, but this is really speculation, you can just modify the error
calculation to just ignore the 4 lower bits of the actual sample data,
and safe another few percents of data volume.

Best regards,

Marcus


On 16.07.2016 06:34, Dan CaJacob wrote:
> You'll likely have to buffer the output to a ramdisk and then slowly
> bleed that to the disk.  Compression typically doesn't work well on IQ
> data unless you've got a structured signal in there.  If there's a lot
> of white noise, you won't get much compression
>
> On Sat, Jul 16, 2016 at 12:00 AM Dave NotTelling  > wrote:
>
> Anyone have experience with streaming 100+ MSPS of 16 bit IQ data
> through a compression tool and then to disk?  I'd like to be able
> to take really wide band snaps for several minutes.  Currently
> that would take up 16 * 2 * SAMP_RATE bits per second.  So, for
> 200 MSPS that would end up being 800 MBytes/s.  That rate eats up
> a hard drive pretty quickly.  Running it through gzip by way of
> pigz was my first thought, but even on an 8 core Intel machine
> pigz just can't keep up.  I can sustain maybe 300 MBytes/s but
> that's it.  And I know it's not a hard disk limitation as the M.2
> drive I am using can easily sustain 800 MBytes/s of uncompressed
> data.
>
> Thoughts?
>
> Thank you!
>
>
> -Dave
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> -- 
> Very Respectfully,
>
> Dan CaJacob
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Streaming IQ File Compression

[Dan CaJacob]

You'll likely have to buffer the output to a ramdisk and then slowly bleed
that to the disk.  Compression typically doesn't work well on IQ data
unless you've got a structured signal in there.  If there's a lot of white
noise, you won't get much compression

On Sat, Jul 16, 2016 at 12:00 AM Dave NotTelling 
wrote:

> Anyone have experience with streaming 100+ MSPS of 16 bit IQ data through
> a compression tool and then to disk?  I'd like to be able to take really
> wide band snaps for several minutes.  Currently that would take up 16 * 2 *
> SAMP_RATE bits per second.  So, for 200 MSPS that would end up being 800
> MBytes/s.  That rate eats up a hard drive pretty quickly.  Running it
> through gzip by way of pigz was my first thought, but even on an 8 core
> Intel machine pigz just can't keep up.  I can sustain maybe 300 MBytes/s
> but that's it.  And I know it's not a hard disk limitation as the M.2 drive
> I am using can easily sustain 800 MBytes/s of uncompressed data.
>
> Thoughts?
>
> Thank you!
>
>
> -Dave
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

Dan CaJacob
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio