struct block_v120_format defines these members as uint8_t. On
little-endian systems, no swapping is done, and the generated block
header is fine. However, on big-endian machines, the value is swapped to
the high byte and then truncated by the assignment, causing both
bits_per_sample and samples_per_frame to be zero.
This fixes an assertion failure in container-test when later
parsing the header ["assert(*samples_per_frame > 0);" in
container_context_pre_process()].
Fixes: 4ab7510f3a: ("axfer: add support for a container of Creative Tech. voice format")
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
This commit adds support for data of Creative Tech. voice format. In this
data format, values in each of field are represented in little-endian byte
order and available formats of data sample are restricted in little-endian
byte order.
In version 1.10 of this format, sampling rate is represented with
reciprocal number of the rate, thus we cannot calculate original sampling
rate precisely just from its header. For example at 44.1kHz, file header
includes 233 (=256-1,000,000/44,100), but we cannot recover the value just
from the code (43478.2...). For my convenience, this commit adds a
pre-computed table and lookup major rates from the table.
Additionally, this format can includes several blocks with different
sample format. When handling this type of file, we need to start/stop
substream for each of the block, while this brings complicated code.
This type of format is enough ancient and presently quite minor. This
commit takes a compromise and handles a first sample block only.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
