Take this with a grain of salt. Although I have a rough idea of
sigrok's general architecture, I'm not too familiar with intimate
API details.
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. But as far as I know the
WAV files are in RIFF format. Which means that they are chunked,
and several chunks can get concatenated in transparent ways and
form one sequence of audio samples. Which is why players cope
with those files as long as more data is available. So WAV files
could get constructed from pieces as you see fit. Just provide
more intermediate headers as more chunks get added.
Regarding the update / adjustment of earlier provided data "after
the fact": I'd assume that this is not possible from decoders,
which operate on "streams" of data (and stacking could be
compared to piping in a sense). If you assume file storage and
want to update previously written data, then we'd be talking
about "output" modules, which are different from "decoders".
Looking at the specific I2S decoder, it appears to be implemented
inappropriately, or at least assumes a rather specific use and
may not fully reflect the general nature of its input. The I2S
decoder should generate one RIFF and WAVE and fmt chunk, but
should generate as many data chunks as are required to hold the
sample data. And it might apply padding to the last chunk when a
fixed chunk length is assumed and already was written?
I'm not certain about the length after the "RIFF" marker. The
comments and the encoded numbers don't match, are there typos?
Is there a blocker since that first length needs to reflect all
of the audio samples, which are not known at the time when the
header gets written? Hmm, would need to lookup the RIFF format
in more detail ...
Is the issue in the I2S decoder's writing RIFF data in the first
place, instead of generating a format that's "more streamable"?
Should WAV file generation and reflection of subsequent sample
data in preceeding headers be left to output modules instead?
Is the WAV header all fake in not reflecting the channel count,
sample width, and the sampling frequency either? Haven't seen
the I2S decoder "mapping" its input samples to the claimed 16kHz
audio frequency at a quick glance. Input is assumed to be stereo
(which might be appropriate for I2S) and 32bits (which may or may
not be appropriate for I2S in general).
> 2. Is it acceptible 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.
> 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).
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
