* SDR sampling rate - control or IOCTL?
@ 2013-11-21 17:05 Antti Palosaari
2013-11-21 17:49 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 11+ messages in thread
From: Antti Palosaari @ 2013-11-21 17:05 UTC (permalink / raw)
To: LMML, Mauro Carvalho Chehab, Hans Verkuil, Hans de Goede
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?
regards
Antti
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: SDR sampling rate - control or IOCTL?
2013-11-21 17:05 SDR sampling rate - control or IOCTL? Antti Palosaari
@ 2013-11-21 17:49 ` Mauro Carvalho Chehab
2013-11-21 18:22 ` Hans Verkuil
2013-11-21 18:51 ` Antti Palosaari
0 siblings, 2 replies; 11+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-21 17:49 UTC (permalink / raw)
To: Antti Palosaari; +Cc: LMML, Hans Verkuil, Hans de Goede
Em Thu, 21 Nov 2013 19:05:05 +0200
Antti Palosaari <crope@iki.fi> 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.
Regards,
Mauro
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: SDR sampling rate - control or IOCTL?
2013-11-21 17:49 ` Mauro Carvalho Chehab
@ 2013-11-21 18:22 ` Hans Verkuil
2013-11-21 18:33 ` Antti Palosaari
2013-11-21 18:42 ` Mauro Carvalho Chehab
2013-11-21 18:51 ` Antti Palosaari
1 sibling, 2 replies; 11+ messages in thread
From: Hans Verkuil @ 2013-11-21 18:22 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Antti Palosaari, LMML, Hans de Goede
On 11/21/2013 06:49 PM, Mauro Carvalho Chehab wrote:
> Em Thu, 21 Nov 2013 19:05:05 +0200
> Antti Palosaari <crope@iki.fi> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: SDR sampling rate - control or IOCTL?
2013-11-21 18:22 ` Hans Verkuil
@ 2013-11-21 18:33 ` Antti Palosaari
2013-11-21 19:12 ` Mauro Carvalho Chehab
2013-11-21 18:42 ` Mauro Carvalho Chehab
1 sibling, 1 reply; 11+ messages in thread
From: Antti Palosaari @ 2013-11-21 18:33 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab; +Cc: LMML, Hans de Goede
On 21.11.2013 20:22, Hans Verkuil wrote:
> On 11/21/2013 06:49 PM, Mauro Carvalho Chehab wrote:
>> Em Thu, 21 Nov 2013 19:05:05 +0200
>> Antti Palosaari <crope@iki.fi> 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.
Yes, but in practice it is uncommon. When I reverse-engineered Mirics
MSi2500 USB ADC I did it hundred of times. Just started streaming and
injected numbers to ADC control registers, then calculated sampling rate
from the stream. That is only use case I know currently, there still
could be some others. Nothing prevents do to it, the key issue is that
sampling rate is needed to known by app. It is app developer choice if
he wants to restart streaming when changes sampling rate.
ADC sampling frequency has no direct relation to stream format. See for
example those Mirics libv4lconvert patches I send earlier that week.
regards
Antti
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: SDR sampling rate - control or IOCTL?
2013-11-21 18:22 ` Hans Verkuil
2013-11-21 18:33 ` Antti Palosaari
@ 2013-11-21 18:42 ` Mauro Carvalho Chehab
1 sibling, 0 replies; 11+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-21 18:42 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Antti Palosaari, LMML, Hans de Goede
Em Thu, 21 Nov 2013 19:22:51 +0100
Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> On 11/21/2013 06:49 PM, Mauro Carvalho Chehab wrote:
> > Em Thu, 21 Nov 2013 19:05:05 +0200
> > Antti Palosaari <crope@iki.fi> 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
I don't think so. Btw, it makes sense to have different frequency bands
for SDR too.
> BTW, can the sample rate change while streaming? Typically things you set
> through S_FMT can not be changed while streaming.
I don't think you can. If the sampling rate changes, you need to know exactly
on what sample the bit rate changed, or otherwise you can't decode the
samples.
In other words, you need to first stream off, then change the sampling rate,
then do a stream on.
Cheers,
Mauro
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: SDR sampling rate - control or IOCTL?
2013-11-21 17:49 ` Mauro Carvalho Chehab
2013-11-21 18:22 ` Hans Verkuil
@ 2013-11-21 18:51 ` Antti Palosaari
1 sibling, 0 replies; 11+ messages in thread
From: Antti Palosaari @ 2013-11-21 18:51 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: LMML, Hans Verkuil, Hans de Goede
On 21.11.2013 19:49, Mauro Carvalho Chehab wrote:
> Em Thu, 21 Nov 2013 19:05:05 +0200
> Antti Palosaari <crope@iki.fi> 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.
No, no no! Look for example Ettus USRP. It is fully modular and you
could select different RF boards. I think you could even feed I/O from
your DTV modulator to that that, having no tuner at all.
> A SDR output device will always have a DAC and a RF transmitter.
Nope! Usually you could feed baseband too, no "tuner" at all.
>
> On both cases, the sampling rate and the sampling format are mandatory
> arguments.
Yeah, app needs to know sampling rate and of course stream format.
Application stream format is typically pair of floats, whilst hardware
offers integer numbers as a ADC sampling levels.
> 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.
Personally I would like to implement that a way driver returns some
known integer formats. That means, driver does some small conversion,
reads device specific numbers from device and outputs those to some
known formats like integers.
But I already moved all that stuff to libv4lconvert.
> 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.
>
> Regards,
> Mauro
>
regards
Antti
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: SDR sampling rate - control or IOCTL?
2013-11-21 18:33 ` Antti Palosaari
@ 2013-11-21 19:12 ` Mauro Carvalho Chehab
2013-11-21 20:22 ` Antti Palosaari
0 siblings, 1 reply; 11+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-21 19:12 UTC (permalink / raw)
To: Antti Palosaari; +Cc: Hans Verkuil, LMML, Hans de Goede
Em Thu, 21 Nov 2013 20:33:15 +0200
Antti Palosaari <crope@iki.fi> escreveu:
> On 21.11.2013 20:22, Hans Verkuil wrote:
> > On 11/21/2013 06:49 PM, Mauro Carvalho Chehab wrote:
> >> Em Thu, 21 Nov 2013 19:05:05 +0200
> >> Antti Palosaari <crope@iki.fi> 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.
>
> Yes, but in practice it is uncommon. When I reverse-engineered Mirics
> MSi2500 USB ADC I did it hundred of times. Just started streaming and
> injected numbers to ADC control registers, then calculated sampling rate
> from the stream.
That's not an use case. It is just a developer's procedure. Anyway, you
could still measure the bit rate like that, if you do a stream start and
stop.
> That is only use case I know currently, there still could be some others.
Seriously? Since the Shannon theorem, all theory used on DSP assumes that
the samples are spaced at the very same bit rate.
> Nothing prevents do to it, the key issue is that
> sampling rate is needed to known by app.
No, it is harder than that: if the bit rate changes, then you need to pack
the sampling rate changes when they occur inside the stream, as otherwise
userspace will have no means to detect such changes.
This is the very same problem on video streams: we currently don't allow
calling VIDIOC_S_FMT in the middle of some transmission, as there's no
way to signalize when the changes are applied.
We used to allow it in the past, at least on bttv, as the old code, from
V4L1 times used to always allocate memory for the max possible resolution.
So, it used to support streaming resizing after start streaming.
There were even one V4L1 application doing that, basically due to a
programer's mistake:
The program used to first start streaming, and then changing the image
size, very quickly. I suspect that the original developer never suspected
about the application misbehavior, but that became a nightmare when we
removed V4L1 support. I ended by fixing the application in the process.
> It is app developer choice if
> he wants to restart streaming when changes sampling rate.
>
> ADC sampling frequency has no direct relation to stream format. See for
> example those Mirics libv4lconvert patches I send earlier that week.
The same applies to all write parameters passed via the pix_format structs:
they're orthogonal (e. g. one don't depend on the others).
In the specific case of v4l2_pix_format, the parameters filled by userspace
are orthogonal: width, height, pixelformat, field.
Ok, not all configs are valid, and the device may have some restrictions.
So, the driver can round those parameters to the closest possible value,
if needed.
The bytesperline, sizeimage and colorspace are parameters filled by the
driver. The first two parameters are derived from the image size and
pixelformat.
The colorspace parameter is a driver-dependent fixed value (Actually,
a few special drivers allow userspace to fill the colorspace too,
like the mem2mem drivers - but this is an exception).
Regards,
Mauro
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: SDR sampling rate - control or IOCTL?
2013-11-21 19:12 ` Mauro Carvalho Chehab
@ 2013-11-21 20:22 ` Antti Palosaari
2013-11-21 20:54 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 11+ messages in thread
From: Antti Palosaari @ 2013-11-21 20:22 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Hans Verkuil, LMML, Hans de Goede
On 21.11.2013 21:12, Mauro Carvalho Chehab wrote:
> Em Thu, 21 Nov 2013 20:33:15 +0200
> Antti Palosaari <crope@iki.fi> escreveu:
>
>> On 21.11.2013 20:22, Hans Verkuil wrote:
>>> On 11/21/2013 06:49 PM, Mauro Carvalho Chehab wrote:
>>>> Em Thu, 21 Nov 2013 19:05:05 +0200
>>>> Antti Palosaari <crope@iki.fi> 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.
>>
>> Yes, but in practice it is uncommon. When I reverse-engineered Mirics
>> MSi2500 USB ADC I did it hundred of times. Just started streaming and
>> injected numbers to ADC control registers, then calculated sampling rate
>> from the stream.
>
> That's not an use case. It is just a developer's procedure. Anyway, you
> could still measure the bit rate like that, if you do a stream start and
> stop.
>
>> That is only use case I know currently, there still could be some others.
>
> Seriously? Since the Shannon theorem, all theory used on DSP assumes that
> the samples are spaced at the very same bit rate.
>
>> Nothing prevents do to it, the key issue is that
>> sampling rate is needed to known by app.
>
> No, it is harder than that: if the bit rate changes, then you need to pack
> the sampling rate changes when they occur inside the stream, as otherwise
> userspace will have no means to detect such changes.
Heh, I cannot understood you. Could you explain why it works for me?
Here is video I recorded just for you:
http://palosaari.fi/linux/v4l-dvb/mirics_msi3101_sdrsharp_sampling_rate.mp4
It is Mirics MSi3101 streaming FM radio with sampling rate 2.048 Msps,
then I switch to 1.024 Msps and back few times - on the fly. IMHO
results are just as expected. Sound start cracking when DSP application
sampling rate does not match, but when you change it back to correct it
recovers.
If I will add button to tell app DSP that sampling rate is changed, it
will work for both cases. I haven't yet implemented that settings
button, it is hard coded to SDRSharp plugin.
Could you explain why it works if it is impossible as you said?
> This is the very same problem on video streams: we currently don't allow
> calling VIDIOC_S_FMT in the middle of some transmission, as there's no
> way to signalize when the changes are applied.
>
> We used to allow it in the past, at least on bttv, as the old code, from
> V4L1 times used to always allocate memory for the max possible resolution.
> So, it used to support streaming resizing after start streaming.
>
> There were even one V4L1 application doing that, basically due to a
> programer's mistake:
>
> The program used to first start streaming, and then changing the image
> size, very quickly. I suspect that the original developer never suspected
> about the application misbehavior, but that became a nightmare when we
> removed V4L1 support. I ended by fixing the application in the process.
>
>> It is app developer choice if
>> he wants to restart streaming when changes sampling rate.
>>
>> ADC sampling frequency has no direct relation to stream format. See for
>> example those Mirics libv4lconvert patches I send earlier that week.
>
> The same applies to all write parameters passed via the pix_format structs:
> they're orthogonal (e. g. one don't depend on the others).
>
> In the specific case of v4l2_pix_format, the parameters filled by userspace
> are orthogonal: width, height, pixelformat, field.
>
> Ok, not all configs are valid, and the device may have some restrictions.
> So, the driver can round those parameters to the closest possible value,
> if needed.
>
> The bytesperline, sizeimage and colorspace are parameters filled by the
> driver. The first two parameters are derived from the image size and
> pixelformat.
>
> The colorspace parameter is a driver-dependent fixed value (Actually,
> a few special drivers allow userspace to fill the colorspace too,
> like the mem2mem drivers - but this is an exception).
>
> Regards,
> Mauro
>
regards
Antti
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: SDR sampling rate - control or IOCTL?
2013-11-21 20:22 ` Antti Palosaari
@ 2013-11-21 20:54 ` Mauro Carvalho Chehab
2013-11-21 21:19 ` Antti Palosaari
0 siblings, 1 reply; 11+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-21 20:54 UTC (permalink / raw)
To: Antti Palosaari; +Cc: Hans Verkuil, LMML, Hans de Goede
Em Thu, 21 Nov 2013 22:22:49 +0200
Antti Palosaari <crope@iki.fi> escreveu:
> On 21.11.2013 21:12, Mauro Carvalho Chehab wrote:
> > Em Thu, 21 Nov 2013 20:33:15 +0200
> > Antti Palosaari <crope@iki.fi> escreveu:
> >
> >> On 21.11.2013 20:22, Hans Verkuil wrote:
> >>> On 11/21/2013 06:49 PM, Mauro Carvalho Chehab wrote:
> >>>> Em Thu, 21 Nov 2013 19:05:05 +0200
> >>>> Antti Palosaari <crope@iki.fi> 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.
> >>
> >> Yes, but in practice it is uncommon. When I reverse-engineered Mirics
> >> MSi2500 USB ADC I did it hundred of times. Just started streaming and
> >> injected numbers to ADC control registers, then calculated sampling rate
> >> from the stream.
> >
> > That's not an use case. It is just a developer's procedure. Anyway, you
> > could still measure the bit rate like that, if you do a stream start and
> > stop.
> >
> >> That is only use case I know currently, there still could be some others.
> >
> > Seriously? Since the Shannon theorem, all theory used on DSP assumes that
> > the samples are spaced at the very same bit rate.
> >
> >> Nothing prevents do to it, the key issue is that
> >> sampling rate is needed to known by app.
> >
> > No, it is harder than that: if the bit rate changes, then you need to pack
> > the sampling rate changes when they occur inside the stream, as otherwise
> > userspace will have no means to detect such changes.
>
> Heh, I cannot understood you. Could you explain why it works for me?
> Here is video I recorded just for you:
> http://palosaari.fi/linux/v4l-dvb/mirics_msi3101_sdrsharp_sampling_rate.mp4
>
> It is Mirics MSi3101 streaming FM radio with sampling rate 2.048 Msps,
> then I switch to 1.024 Msps and back few times - on the fly. IMHO
> results are just as expected. Sound start cracking when DSP application
> sampling rate does not match, but when you change it back to correct it
> recovers.
In other words, changing the sampling rate while streaming breaks decoding.
> If I will add button to tell app DSP that sampling rate is changed, it
> will work for both cases. I haven't yet implemented that settings
> button, it is hard coded to SDRSharp plugin.
>
> Could you explain why it works if it is impossible as you said?
I can't imagine any "magic" button that will be able to discover
on what exact sample the sampling rate changed. The hardware may
have buffers; the DMA engines and the USB stack for sure have, and
also V4L. Knowing on what exact sample the sampling rate changed
would require hardware support, to properly tag the sample where the
change started to apply.
If the hardware supports it, I don't see an reason why blocking calling
VIDIOC_S_FMT in the middle of a stream.
However, on all other hardwares, samples will be lost or will be
badly decoded, with would cause audio/video artifacts or even break
the decoding code if not properly written.
Anyway, if samples will be lost anyway, the right thing to do is to
just stop streaming, change the sampling rate and start streaming
again. This way, you'll know that all buffers received before the
changes will have the old sampling rate, and all new buffers, the new one.
Regards,
Mauro
>
>
> > This is the very same problem on video streams: we currently don't allow
> > calling VIDIOC_S_FMT in the middle of some transmission, as there's no
> > way to signalize when the changes are applied.
> >
> > We used to allow it in the past, at least on bttv, as the old code, from
> > V4L1 times used to always allocate memory for the max possible resolution.
> > So, it used to support streaming resizing after start streaming.
> >
> > There were even one V4L1 application doing that, basically due to a
> > programer's mistake:
> >
> > The program used to first start streaming, and then changing the image
> > size, very quickly. I suspect that the original developer never suspected
> > about the application misbehavior, but that became a nightmare when we
> > removed V4L1 support. I ended by fixing the application in the process.
> >
> >> It is app developer choice if
> >> he wants to restart streaming when changes sampling rate.
> >>
> >> ADC sampling frequency has no direct relation to stream format. See for
> >> example those Mirics libv4lconvert patches I send earlier that week.
> >
> > The same applies to all write parameters passed via the pix_format structs:
> > they're orthogonal (e. g. one don't depend on the others).
> >
> > In the specific case of v4l2_pix_format, the parameters filled by userspace
> > are orthogonal: width, height, pixelformat, field.
> >
> > Ok, not all configs are valid, and the device may have some restrictions.
> > So, the driver can round those parameters to the closest possible value,
> > if needed.
> >
> > The bytesperline, sizeimage and colorspace are parameters filled by the
> > driver. The first two parameters are derived from the image size and
> > pixelformat.
> >
> > The colorspace parameter is a driver-dependent fixed value (Actually,
> > a few special drivers allow userspace to fill the colorspace too,
> > like the mem2mem drivers - but this is an exception).
> >
> > Regards,
> > Mauro
> >
>
>
> regards
> Antti
>
--
Cheers,
Mauro
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: SDR sampling rate - control or IOCTL?
2013-11-21 20:54 ` Mauro Carvalho Chehab
@ 2013-11-21 21:19 ` Antti Palosaari
2013-12-09 23:14 ` Antti Palosaari
0 siblings, 1 reply; 11+ messages in thread
From: Antti Palosaari @ 2013-11-21 21:19 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Hans Verkuil, LMML, Hans de Goede
On 21.11.2013 22:54, Mauro Carvalho Chehab wrote:
> Em Thu, 21 Nov 2013 22:22:49 +0200
> Antti Palosaari <crope@iki.fi> escreveu:
>
>> On 21.11.2013 21:12, Mauro Carvalho Chehab wrote:
>>> Em Thu, 21 Nov 2013 20:33:15 +0200
>>> Antti Palosaari <crope@iki.fi> escreveu:
>>>
>>>> On 21.11.2013 20:22, Hans Verkuil wrote:
>>>>> BTW, can the sample rate change while streaming? Typically things you set
>>>>> through S_FMT can not be changed while streaming.
>>>>
>>>> Yes, but in practice it is uncommon. When I reverse-engineered Mirics
>>>> MSi2500 USB ADC I did it hundred of times. Just started streaming and
>>>> injected numbers to ADC control registers, then calculated sampling rate
>>>> from the stream.
>>>
>>> That's not an use case. It is just a developer's procedure. Anyway, you
>>> could still measure the bit rate like that, if you do a stream start and
>>> stop.
>>>
>>>> That is only use case I know currently, there still could be some others.
>>>
>>> Seriously? Since the Shannon theorem, all theory used on DSP assumes that
>>> the samples are spaced at the very same bit rate.
>>>
>>>> Nothing prevents do to it, the key issue is that
>>>> sampling rate is needed to known by app.
>>>
>>> No, it is harder than that: if the bit rate changes, then you need to pack
>>> the sampling rate changes when they occur inside the stream, as otherwise
>>> userspace will have no means to detect such changes.
>>
>> Heh, I cannot understood you. Could you explain why it works for me?
>> Here is video I recorded just for you:
>> http://palosaari.fi/linux/v4l-dvb/mirics_msi3101_sdrsharp_sampling_rate.mp4
>>
>> It is Mirics MSi3101 streaming FM radio with sampling rate 2.048 Msps,
>> then I switch to 1.024 Msps and back few times - on the fly. IMHO
>> results are just as expected. Sound start cracking when DSP application
>> sampling rate does not match, but when you change it back to correct it
>> recovers.
>
> In other words, changing the sampling rate while streaming breaks decoding.
Of course, in a case DSP does not know what it is. I have found that
changing frequency during streaming breaks my audio as well.
>> If I will add button to tell app DSP that sampling rate is changed, it
>> will work for both cases. I haven't yet implemented that settings
>> button, it is hard coded to SDRSharp plugin.
>>
>> Could you explain why it works if it is impossible as you said?
>
> I can't imagine any "magic" button that will be able to discover
> on what exact sample the sampling rate changed. The hardware may
> have buffers; the DMA engines and the USB stack for sure have, and
> also V4L. Knowing on what exact sample the sampling rate changed
> would require hardware support, to properly tag the sample where the
> change started to apply.
"Magic button". It is just DSP application which sends request to
hardware. And if hardware says OK, that magic SDR application says for
own DSP hey change sampling rate to mach stream.
There is huge amount of bits streaming, no need to tag. You could just
throw away second or two - does not matter. Imagine it similarly like a
UDP VoIP call - when you lose data, so what, it is 20ms of audio and
none cares.
It is similarly here, if you lose some data due to sampling rate
mismatch, so what. It is only few ms of audio (or some other). One way
radio channel is something it should be robust for such issues - you
cannot request retry.
> If the hardware supports it, I don't see an reason why blocking calling
> VIDIOC_S_FMT in the middle of a stream.
>
> However, on all other hardwares, samples will be lost or will be
> badly decoded, with would cause audio/video artifacts or even break
> the decoding code if not properly written.
>
> Anyway, if samples will be lost anyway, the right thing to do is to
> just stop streaming, change the sampling rate and start streaming
> again. This way, you'll know that all buffers received before the
> changes will have the old sampling rate, and all new buffers, the new one.
I cannot agree. It is too slow, without real benefits, for many use cases.
Also, I am pretty sure many of the hw DSP implementations will not
restart streaming when they hunt for demodulation lock. There is likely
just a long shift-register or FIFO where bits are running even different
sampling rates etc. are tested.
regards
Antti
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: SDR sampling rate - control or IOCTL?
2013-11-21 21:19 ` Antti Palosaari
@ 2013-12-09 23:14 ` Antti Palosaari
0 siblings, 0 replies; 11+ messages in thread
From: Antti Palosaari @ 2013-12-09 23:14 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Hans Verkuil, LMML, Hans de Goede
On 21.11.2013 23:19, Antti Palosaari wrote:
> On 21.11.2013 22:54, Mauro Carvalho Chehab wrote:
>> Em Thu, 21 Nov 2013 22:22:49 +0200
>> Antti Palosaari <crope@iki.fi> escreveu:
>>
>>> On 21.11.2013 21:12, Mauro Carvalho Chehab wrote:
>>>> Em Thu, 21 Nov 2013 20:33:15 +0200
>>>> Antti Palosaari <crope@iki.fi> escreveu:
>>>>
>>>>> On 21.11.2013 20:22, Hans Verkuil wrote:
>
>>>>>> BTW, can the sample rate change while streaming? Typically things
>>>>>> you set
>>>>>> through S_FMT can not be changed while streaming.
>>>>>
>>>>> Yes, but in practice it is uncommon. When I reverse-engineered Mirics
>>>>> MSi2500 USB ADC I did it hundred of times. Just started streaming and
>>>>> injected numbers to ADC control registers, then calculated sampling
>>>>> rate
>>>>> from the stream.
>>>>
>>>> That's not an use case. It is just a developer's procedure. Anyway, you
>>>> could still measure the bit rate like that, if you do a stream start
>>>> and
>>>> stop.
>>>>
>>>>> That is only use case I know currently, there still could be some
>>>>> others.
>>>>
>>>> Seriously? Since the Shannon theorem, all theory used on DSP assumes
>>>> that
>>>> the samples are spaced at the very same bit rate.
>>>>
>>>>> Nothing prevents do to it, the key issue is that
>>>>> sampling rate is needed to known by app.
>>>>
>>>> No, it is harder than that: if the bit rate changes, then you need
>>>> to pack
>>>> the sampling rate changes when they occur inside the stream, as
>>>> otherwise
>>>> userspace will have no means to detect such changes.
>>>
>>> Heh, I cannot understood you. Could you explain why it works for me?
>>> Here is video I recorded just for you:
>>> http://palosaari.fi/linux/v4l-dvb/mirics_msi3101_sdrsharp_sampling_rate.mp4
>>>
>>>
>>> It is Mirics MSi3101 streaming FM radio with sampling rate 2.048 Msps,
>>> then I switch to 1.024 Msps and back few times - on the fly. IMHO
>>> results are just as expected. Sound start cracking when DSP application
>>> sampling rate does not match, but when you change it back to correct it
>>> recovers.
>>
>> In other words, changing the sampling rate while streaming breaks
>> decoding.
>
> Of course, in a case DSP does not know what it is. I have found that
> changing frequency during streaming breaks my audio as well.
>
>
>>> If I will add button to tell app DSP that sampling rate is changed, it
>>> will work for both cases. I haven't yet implemented that settings
>>> button, it is hard coded to SDRSharp plugin.
>>>
>>> Could you explain why it works if it is impossible as you said?
>>
>> I can't imagine any "magic" button that will be able to discover
>> on what exact sample the sampling rate changed. The hardware may
>> have buffers; the DMA engines and the USB stack for sure have, and
>> also V4L. Knowing on what exact sample the sampling rate changed
>> would require hardware support, to properly tag the sample where the
>> change started to apply.
>
> "Magic button". It is just DSP application which sends request to
> hardware. And if hardware says OK, that magic SDR application says for
> own DSP hey change sampling rate to mach stream.
>
> There is huge amount of bits streaming, no need to tag. You could just
> throw away second or two - does not matter. Imagine it similarly like a
> UDP VoIP call - when you lose data, so what, it is 20ms of audio and
> none cares.
> It is similarly here, if you lose some data due to sampling rate
> mismatch, so what. It is only few ms of audio (or some other). One way
> radio channel is something it should be robust for such issues - you
> cannot request retry.
>
>> If the hardware supports it, I don't see an reason why blocking calling
>> VIDIOC_S_FMT in the middle of a stream.
>>
>> However, on all other hardwares, samples will be lost or will be
>> badly decoded, with would cause audio/video artifacts or even break
>> the decoding code if not properly written.
>>
>> Anyway, if samples will be lost anyway, the right thing to do is to
>> just stop streaming, change the sampling rate and start streaming
>> again. This way, you'll know that all buffers received before the
>> changes will have the old sampling rate, and all new buffers, the new
>> one.
>
> I cannot agree. It is too slow, without real benefits, for many use cases.
>
> Also, I am pretty sure many of the hw DSP implementations will not
> restart streaming when they hunt for demodulation lock. There is likely
> just a long shift-register or FIFO where bits are running even different
> sampling rates etc. are tested.
I did some study of runtime sampling rate changes and I am very sure it
is *required*, especially for digital receivers, like DTV dedulators,
where timing is important. The main reason is synchronization - not only
for when channel is acquired but for run time synchronization too in
order to maintain receiver sync (lock).
Here is one document which explains some reasons and solutions for
digital receiver synchronization:
http://www.cs.tut.fi/kurssit/TLT-5806/Synch.pdf
You can find a lot of more information when search "Synchronization
Techniques for Digital Receivers"
What goes to Mirics MSi2500 ADC, it has even flag to signal when
sampling rate is changed. Due to that you will not even lose many
samples and it is possible to make demodulator design simpler. It is
byte 5 in USB packet header which changes between 10/90 when sampling
rate is changed as I shown in earlier video. I am pretty sure that they
have had good reason to add support for run time sampling rate change as
it is the only software based TV demodulator solution currently.
**********
So the requirements are what I listed originally + it must be possible
to change sampling rate during streaming.
Now I am testing similar solution than VIDIOC_ENUM_FREQ_BANDS
regards
Antti
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2013-12-09 23:14 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-21 17:05 SDR sampling rate - control or IOCTL? Antti Palosaari
2013-11-21 17:49 ` Mauro Carvalho Chehab
2013-11-21 18:22 ` Hans Verkuil
2013-11-21 18:33 ` Antti Palosaari
2013-11-21 19:12 ` Mauro Carvalho Chehab
2013-11-21 20:22 ` Antti Palosaari
2013-11-21 20:54 ` Mauro Carvalho Chehab
2013-11-21 21:19 ` Antti Palosaari
2013-12-09 23:14 ` Antti Palosaari
2013-11-21 18:42 ` Mauro Carvalho Chehab
2013-11-21 18:51 ` Antti Palosaari
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.