On 11/21/2013 06:49 PM, Mauro Carvalho Chehab wrote:
> Em Thu, 21 Nov 2013 19:05:05 +0200
> Antti Palosaari <crope@xxxxxx> escreveu:
>
>> Hello
>> I am adding new property for sampling rate that is ideally the only
>> obligatory parameter required by SDR. It is value that could be only
>> positive and bigger the better, lets say unsigned 64 bit is quite ideal.
>> That value sets maximum radio frequency possible to receive (ideal SDR).
>>
>> Valid values are not always in some single range from X to Y, there
>> could be some multiple value ranges.
>>
>> For example possible values: 1000-2000, 23459, 900001-2800000
>>
>> Reading possible values from device could be nice, but not necessary.
>> Reading current value is more important.
>>
>> Here is what I though earlier as a requirements:
>>
>> sampling rate
>> * values: 1 - infinity (unit: Hz, samples per second)
>> currently 500 MHz is more than enough
>> * operations
>> GET, inquire what HW supports
>> GET, get current value
>> SET, set desired value
>>
>>
>> I am not sure what is best way to implement that kind of thing.
>> IOCTL like frequency
>> V4L2 Control?
>> put it into stream format request?
>>
>> Sampling rate is actually frequency of ADC. As there devices has almost
>> always tuner too (practical SDR) there is need for tuner frequency too.
>> As tuner is still own entity, is it possible to use same frequency
>> parameter for both ADC and RF tuner in same device?
>
> Well, a SDR capture device will always have ADC and RF tuner.
>
> A SDR output device will always have a DAC and a RF transmitter.
>
> On both cases, the sampling rate and the sampling format are mandatory
> arguments.
>
> In any case, the V4L2 API has already support for setting the mandatory
> parameters of the expected stream, at struct v4l2_format.
>
> So, it makes sense do do:
>
> struct v4l2_format {
> __u32 type;
> union {
> struct v4l2_pix_format pix; /* V4L2_BUF_TYPE_VIDEO_CAPTURE */
> struct v4l2_pix_format_mplane pix_mp; /* V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE */
> struct v4l2_window win; /* V4L2_BUF_TYPE_VIDEO_OVERLAY */
> struct v4l2_vbi_format vbi; /* V4L2_BUF_TYPE_VBI_CAPTURE */
> struct v4l2_sliced_vbi_format sliced; /* V4L2_BUF_TYPE_SLICED_VBI_CAPTURE */
> + struct v4l2_sdr_format sdr; /* V4L2_BUF_TYPE_SDR_CAPTURE */
> __u8 raw_data[200]; /* user-defined */
> } fmt;
> };
>
> And add the mandatory parameters for SDR inside its own structure, e. g.
> struct v4l2_sdr_format. Of course, the meta-data provided by a SDR device
> is different than the one for video or vbi, so you'll need to add a new
> streaming type for SDR anyway.
>
> Btw, that's what I proposed here:
>
> http://git.linuxtv.org/mchehab/experimental.git/blob/refs/heads/sdr:/include/uapi/linux/videodev2.h
>
> With regards to the sampling rate range, my proposal there were to add a min/max
> value for it, to be used by VIDIOC_G_FMT, as proposed on:
> http://git.linuxtv.org/mchehab/experimental.git/commitdiff/c3a73f84f038f043aeda5d5bfccc6fea66291451
>
> So, the v4l2_sdr_format should be like:
>
> +struct v4l2_sdr_format {
> + __u32 sampleformat;
> + __u32 sample_rate; /* in Hz */
> + __u32 min_sample_rate; /* in Hz */
> + __u32 max_sample_rate; /* in Hz */
> +
> +} __attribute__ ((packed));
>
> Where sampleformat would be something similar to FOURCC, defining the
> size of each sample, its format, and if the sampling is in quadradure,
> if they're plain PCM samples, or something more complex, like DPCM, RLE,
> etc.
>
> In the specific case of enumerating the sampling rate range, if the
> sampling rate can have multiple ranges, then maybe we'll need to do
> something more complex like what was done on VIDIOC_ENUM_FRAMESIZES.
Could this ioctl be adapted for this:
http://hverkuil.home.xs4all.nl/spec/media.html#vidioc-enum-freq-bands
BTW, can the sample rate change while streaming? Typically things you set
through S_FMT can not be changed while streaming.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
