[ summary: use an output module, see srzip for prior art ]
On Tue, Oct 11, 2016 at 06:03 +0000, Chris Dreher wrote:
>
> It seems the streaming design of sigrok eliminates a lot of
> file formats. Namely, most file formats with a size field that
> precedes a large variable amount of data can not be supported
> in sigrok. This includes file formats that are 99%
> stream-oriented. For example, MIDI files are 99% compatible
> with sigrok's stream design other than a single 32-bit size
> field in the track chunk. For the MIDI protocol, there are not
> good alternatives to saving data other than in a MIDI file. It
> is unfortunate that such files currently can not be supported
> by sigrok.
>
> That said, I get that sigrok's primary goal is support for
> logic analysis and oscilloscope. Being able to extract and
> save data to a file format is secondary.
This might be too strict an interpretation. I still feel that
what you want to achieve _is_ possible, just not from within
_decoders_. It's simply that seek operations and manipulation of
previously written data needs to occur in the most appropriate
location, which is not from within a pipe that operates on
strictly linear streams.
In theory or rather strictly speaking, output modules might
assume mere streaming, too. It's good practice to avoid
unnecessary dependencies when possible. But there is prior art
where some output module has direct access to a file object, and
does manipulate previously written data as more chunks of
information become available.
It's true that in the current set of output modules most fill in
an "out" string parameter in their receive() method in straight
forward ways (mere formatting of what they received). Those
strings then are put into an output stream in strict linear ways.
The CSV output mostly passes on the samples, and later writes
additional gnuplot(1) information that was accumulated in the
process (if the respective feature was enabled). Multiple files
appear to get written by that one output module (optional).
The "srzip" output module for sigrok's native .sr file format
stands out in that it operates on a ZIP archive that gets created
initially, and gets updated in several steps at several points in
time while the input stream is being received and processed. See
the zip_create() and zip_append() routines.
So I wouldn't consider it too far a stretch when the WAV (and
later MIDI) output modules insist in accessing a file object
directly, open the file with an initial header which reflects the
available information at the time of file creation, and update
that header as more chunks or samples get appended to the file.
This seems to perfectly be in line with what existing output
modules do already. It's reflecting on a property of the very
format that the user requested for the output.
For the record: The notion of "internal I/O handling" in output
modules and the associated "output flag" was introduced in commit
3cd4b381 as of 2015-08-15.
Note that I might be slightly off in my reading of the CSV output
module's logic, only had a cursory look. But the srzip output
module certainly does have a test for "filename available?" in
init(), and calls zip_add(), zip_rename(), and zip_replace()
routines which do more than merely append data at the end of a
previously written file. Even if one interprets the ZIP archive
as "just a directory" -- still previously written members get
updated as required. And none of this feels wrong to me, it all
looks appropriate. Just not for a decoder. :)
> Do people think addressing this issue is worth fixing or is
> time better spent on other issues and features?
I think that the decoder API doesn't need fixing. When
individual decoder implementations assume conditions that are not
met, then the implementations need fixing but not the design.
"The issue" goes away if you move the respective manipulation
logic from the decoder to an output module.
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
