From: Antti Palosaari <crope@iki.fi>
To: Andy Walls <awalls@md.metrocast.net>
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH RFC] libv4lconvert: SDR conversion from U8 to FLOAT
Date: Mon, 18 Nov 2013 19:43:57 +0200 [thread overview]
Message-ID: <528A51DD.8000502@iki.fi> (raw)
In-Reply-To: <1384179541.1949.24.camel@palomino.walls.org>
On 11.11.2013 16:19, Andy Walls wrote:
> On Sun, 2013-11-10 at 19:16 +0200, Antti Palosaari wrote:
>> Convert unsigned 8 to float 32 [-1 to +1], which is commonly
>> used format for baseband signals.
>
> Hi Annti,
>
> I don't think this a good idea. Floating point representations are
> inherently non-portable. Even though most everything now uses IEEE-754
> representation, things like denormaliazed numbers may be treated
> differently by different machines. If someone saves the data to a file,
> endianess issues aside, there are no guarantees that a different machine
> reading is going to interpret all the floating point data from that file
> properly.
>
> I really would recommend staying with scaled integer representations or
> explicit integer mantissa, exponent representations.
Do you mean scaled presentation like a sample is always 32 signed
integer and what ever ADC resolution is, it is scaled to 32-bit signed
int and returned?
What I would like to implement is 8-bit int, 16-bit int and maybe 32-bit
int (if there comes ADC outputting more than 16-bit). These all
conversions are done inside Kernel, which actually has price about
nothing as it is simple integer math with bit shifting (scaling == bit
shifting). If you do that kind of conversion on USB URB interrupt at the
same time as memory copy from URB to videobuf2 is needed, it is
basically free.
Then it is up to caller to select int8, int16, int32 and driver does the
rest, selects actual ADC resolution using info like sampling rate.
Also returning SDR floats directly from Kernel driver could be very
handy, but as floats are not allowed in Kernel...
But now all conversions are in the libv4l. However, it is possible to
add new formats to driver later - removing existing formats from driver
is about impossible.
regards
Antti
--
http://palosaari.fi/
next prev parent reply other threads:[~2013-11-18 17:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-10 17:16 [PATCH RFC] libv4lconvert: SDR conversion from U8 to FLOAT Antti Palosaari
2013-11-11 13:14 ` Hans Verkuil
2013-11-11 13:40 ` Antti Palosaari
2013-11-11 13:52 ` Hans Verkuil
2013-11-15 19:11 ` Antti Palosaari
2013-11-15 19:13 ` Devin Heitmueller
2013-11-15 19:17 ` Antti Palosaari
2013-11-16 14:11 ` Antti Palosaari
2013-11-16 17:28 ` Hans de Goede
2013-11-11 14:19 ` Andy Walls
2013-11-11 14:38 ` Hans Verkuil
2013-11-14 13:45 ` Antti Palosaari
2013-11-14 13:50 ` Hans Verkuil
2013-11-18 17:43 ` Antti Palosaari [this message]
2013-11-16 17:27 ` Hans de Goede
2013-11-16 17:34 ` Antti Palosaari
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=528A51DD.8000502@iki.fi \
--to=crope@iki.fi \
--cc=awalls@md.metrocast.net \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox