Re: CTCSS plugin #sdrsharp


jdow
 

OK, I saw the discussion as moving into the programmers' realm and your question hit me out of left field. It might be interesting to try to explain what the programmer would have to do. It's an issue involved in making modular portions of the program work well together. In the jargon data of this sort if moved in buffers or arrays of values. The modules work on the array of values and pass their output in buffers, sometimes the same ones it came in on and other times new buffers, on to the next module(s). Sometimes, as with some forms of filters, the software works better or even requires a specific size of buffer to work with. Smart modules which face this problem read the incoming data into a work buffer. If it runs out of data on any load of data through the chain of modules it saves the work buffer and waits for the next incoming buffer, Then it reads either until it has its work buffer full or it again runs out of input. As soon as it's work buffer is full, it performs its calculations, passes along the work buffer, switches to another work buffer, and starts filling it with the remaining incoming data. Of course, a good program module either is known to never get too much data or makes provisions for large incoming buffers and fills work buffer, calculates, feeds it on, switches to a new work buffer, and repeats at fills work buffer.

It appears the CTCSS plugin module does not do this and gets confused. The fix should not be very difficult. And there is a real chance it might make the module work better than it used to . Alas, the source code is nowhere to be found.

(Of course, a really enterprising programmer might obtain and install a copy of Ghidra from github and decompile the module. But, that's cheating - and not at all easy.)

Out of curiosity did I manage to make the above nearly understandable to a non-programmer? (It rather points out that programming is keeping your thinking process clear and organized. Math beyond basic MDAS is not often a major factor even for most of an SDR processing module.)

{^_^}

On 20210827 07:21:56, Patrick wrote:
Joanne : I'm not a programmer, just a basic user.
But I first thought the reply from Prog ("Buffer the samples you get and only process when you reach the right size") was intended for me, hence my question !


Le ven. 27 août 2021 à 16:16, jdow <jdow@...> a écrit :
"Concretely, how is this done?"

I guess it was you. If you are a programmer I'd expect you to understand concepts such as multiple buffers, fifos, and the like. If you are not the explanation gets a little boringly long.

And I'm feeling a lot more blunt than usual. I woke up at a very low energy level and that makes be cranky. "It's a featuer" of Aspergers,

{^_^}   Joanne

On 20210827 03:00:08, Patrick wrote:
@jdow : Who is your comment for ?

Le ven. 27 août 2021 à 11:50, jdow <jdow@...> a écrit :
You are kidding, right? Or else you are 100.000% not a programmer. Which is it so I can pitch my reply to your level.
{o.o}

On 20210827 02:22:43, Patrick wrote:
Concretely, how is this done ?

Le ven. 27 août 2021 à 11:05, prog <info@...> a écrit :
On Fri, Aug 27, 2021 at 10:25 AM, Patrick wrote:
Indeed ! I just found his message.
 
" As for the CTCSS plug-in, I don't see an immediate solution to fixing this.
The method the plug-in uses requires a few zero crossings to occur in the audio buffer to detect the tone.
Because the new SDR# (1822) has reduced its audio buffer size, the plug-in is no longer able to see the minimum amount of zero crossings to detect any tones. For me the number of samples in the buffer went from 1664 to 256".
 
I hope Prog will find a way to fix this glitch.
So basically this plugin never worked with low latency sound cards.
=> Buffer the samples you get and only process when your reach the right size.




Join airspy@groups.io to automatically receive all group messages.