> Date: Thu, 6 Oct 2016 09:23:16 +0200
> From: gerhard.sit...@gmx.net
> To: sigrok-devel@lists.sourceforge.net
> Subject: Re: [sigrok-devel] Outputting files from Protocol Decoders
>
> On Wed, Oct 05, 2016 at 11:36 -0700, Chris Dreher wrote:
> >
> > In looking at how to output files from protocol decoders, I
> > have the following questions:
> >
> > 1. Once put() is called for OUTPUT_BINARY, is there anyway to
> > go back and change those bytes? This is especially useful for
> > adjusting file headers based on sample inputs the come later in
> > the stream. For example, the i2s PD can output a WAV file.
> > However, because the WAV file headers include a size field and
> > these headers are written out first and before the rest of the
> > sample inputs are handled, the current i2s code is just
> > hardcoding a corrupt size field. While some media players are
> > forgiving for WAV files, other non-WAV file formats have strict
> > size fields.
>
> This does not solve the general issue.
Actually, it would solve the general issue. Going back and changing previously
submitted bytes would provide similar functionality as seek() followed by a
write() that most operating systems provide.
I deleted the remainder of the WAV-specific response since the question is
about how to solve the issue generally. The WAV output by the i2s PD is just
an example of existing code where an incorrect header is output because the
total length of the data is known.
> > 2. Is it acceptable to buffer most of the file data and then
> > just output the entire file at the end? Again, this relates to
> > file headers. Theoretically, a PD could buffer the file data
> > until it reaches the end of the sample inputs, then calculate
> > the size fields, and finally call put() to output the entire
> > file at once. Are there memory limits in python, similar to
> > Java VM memory limits, or is memory only limited by the OS's
> > memory limits?
>
> Have seen decoders buffer data all the time, though they only
> "defer" data until the completion of a frame or transaction.
> Haven't seen deferral for all of the input data yet.
Are you confirming that python does not have the memory limits that other
languages (ex: Java) has? I've written code in C++ that defers output but the
question is whether this is ok in python and whether it is acceptable for
sigrok's PDs.
> > 3. Is there a way to know that the end of the sample input
> > stream has been reached? This way, a PD would know that there
> > is no more data and that decoding is done. This would prevent
> > a PD from waiting any further for sample inputs that will never
> > come.
>
> I'm not aware of a "stop()" method like "start()", neither am I
> aware of a special "decode()" invocation which would communicate
> the end of the input stream. Could "metadata()" help when a
> "sample limit" applies? Though I'm afraid that this would be
> optional, not generally applicable.
>
> For a more robust approach, introducing a stop() decoder method
> might be a good idea, after coming up with an API that fits all
> decoders in the general case.
>
> For the short term, I'd suggest looking into whether you can
> create one WAV file from several RIFF chunks, when a single RIFF
> header and multiple data chunks are not GoodEnough(TM).
I'm not too interested in generating WAV files. It was just an example used in
question #1.
I've thought of the same 3 possible solutions. I agree that a stop() would be
the best solution. Unfortunately, calling decode() with special invocation
might not get passed to the protocol further down the chain (ex: the uart
decode might not pass the special values to the midi decoder). For similar
reasons, passing the max sample number via metadata() wouldn't work if a lower
level PD didn't send the last sample data further down the chain.
Are there other options? Anything available via the API that has been
overlooked to know that the end of the samples has been reached?
> virtually yours
> Gerhard Sittig
> --
> If you don't understand or are scared by any of the above
> ask your parents or an adult to help you.
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> sigrok-devel mailing list
> sigrok-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sigrok-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
