Re: SDR sampling rate - control or IOCTL?

[Antti Palosaari <crope@iki.fi>]

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/