public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
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/

  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