New SoapyRTLSDR Support Module about soapysdr HOT 9 CLOSED

Did a quick check with three different dongles:

[DEBUG] Device #0: Generic RTL2832U OEM
[DEBUG]     Manufacturer: Realtek, Product Name: RTL2838UHIDIR, Serial: 00000153
Found Rafael Micro R820T tuner
[DEBUG]      Tuner type: Rafael Micro R820T

[DEBUG] Device #0: Terratec NOXON DAB/DAB+ USB dongle (rev 2)
[DEBUG]     Manufacturer: Realtek, Product Name: RTL2832U, Serial: 00000001
Found Elonics E4000 tuner
[DEBUG]      Tuner type: Elonics E4000

[DEBUG] Device #0: Terratec NOXON DAB/DAB+ USB dongle (rev 1)
[DEBUG]     Manufacturer: NOXON, Product Name: DAB Stick, Serial: 0
Found Fitipower FC0013 tuner
[DEBUG]      Tuner type: Fitipower FC0013

All three are working fine, but audio is a little bit choppy, independent of bandwidth setting.

from soapysdr.

Cool. I guess this eventually deprecates the rtl support from Soapy Osmo, just like with the bladerf. Also, no need for the boost dependency. Let me know when you feel its done, I'm happy to host it here and do the debianization. Some comments:

settings in readStream
Is the reason for applying the settings inside of SoapyRTLSDR::readStream() thread related? Like an attempt to make it thread safe when different thread access the settings and the stream? I'm not super familiar w/ the RTL driver FWIW. The downside is, if there is an error applying the setting, it doesn't show up in the relevant setting call.

underflow in readStream
You don't want to be retuning SOAPY_SDR_UNDERFLOW from the readStream(), that's more of a transmit hardware issue. When n_read == 0, that might be a SOAPY_SDR_TIMEOUT (not sure if thats a timeout though, maybe SOAPY_SDR_STREAM_ERROR). And if the returnedElems is 0, i guess that means that the user passed in an empty buffer? they shouldn't do that, but it probably shouldn’t have an ill side-effects, the for loop just has nothing to convert in this case

some notes about readStream
The general idea behind readStream() is to provide a stream-like interface to the caller, think TCP recv(). Where the user passes in an arbitrary sized buffer and the readStream() will fill all or part of that buffer with samples. If it doesnt fill the entire buffer that the user passed in, this isnt an indication of error, or burst end, or timeout, etc -- the implementation is simply allowed to yield less whenever its convenient, because of underlying driver transport stuff -- also just like TCP recv().

A user's custom client code will usually call readStream() continually with the same buffer size, which is why we have that getStreamMTU() call. Platforms like GNU Radio and Pothos with streaming blocks and pre-allocated buffer polls may end up calling readStream() with small buffers as the buffers get passed downstream waiting for consumption. So small buffers can be a normal occurrence here.

Anyway, for this driver and the SDRPlay, I think I see a pattern with this is a pre-allocated temporary buffer. You should be able to re-use the buffer indefinitely without every resizing, erasing, or inserting. Just 2 variables to track samples remaining in the buffer, and samples consumed from the buffer. Whenever the samples remaining is 0, just perform a new device read. Then the behaviour of readStream() is to convert whatever is remaining of the temp buffer into the user's buffer until the user has called readStream() enough times to deplete the temp buffer -- then the cycle can continue with a device read again into the temp buffer.

copyright/license
I don't really want to claim any copyright over my stub code, that seems pretty pointless. Its your code, so feel free to come up with whatever licensing and headers you want. As a convention, I have been trying to use SPDX license identifiers and generally putting the code under a permissive license to maximize its utility to others. Although I do realize that the underlying driver(s) may not be as permissive.

from soapysdr.

Thanks for the info, that helps me understand a lot more about what I should be aiming for; I've been thinking about the function calls too literally to the module and optimizing as if there wasn't any management in-between...

readStream is where the settings are applied because I still have part of the setup in the setupStream() left over from first quick draft where settings functions were crashing by being called before the stream init before I realized the problem.. so I kept it consistent for the moment -- the change flags will be optimized out and the device calls will move into their relevant locations. It was a bit of a rush job since the first pass was working within an hour but I'll clean it up :)

The pre-allocated temporary buffer and insert/erase management was mostly just a way of making sure I didn't make an error in the buffering code for the SDRPlay module since I wrote it without having the hardware and couldn't fully test it -- so it's been copied and pasted from there since it was working. I'll definitely use what you're suggesting when I optimize now that I have a working Soapy RTLSDR driver; then should be able to port that optimization back to the SDRPlay module too.

I'll use whatever license the rest of SoapySDR is using at the moment where possible -- I'd like to move the SoapyRTLSDR repository over to the pothosware organization so it's at home with the others once I polish it up a bit.

Thanks!

from soapysdr.

@guruofquality I've cleaned up most of the issues and it's in a reasonably good state; let me know what I need to do to transfer it over to pothosware if you think it's ready. I picked MIT as the license (primarily since that's what I use in a few other projects) but if you have another preference I'll be glad to switch it up.

Cheers!

from soapysdr.

I took a look at the project earlier today. Looks good to me!

To transfer a repository, go to repository settings and hit transfer
https://help.github.com/articles/transferring-a-repository/

On my end, I probably will get an approval message. Never done it before though!

from soapysdr.

hmm, I tried transferring it to "pothosware" but it said I needed rights on the org with a big mean red banner -- I'll try transferring to your @guruofquality account directly instead of us messing with permissions since you'll have the rights in both places at that point.

from soapysdr.

Ok, transfer request sent!

from soapysdr.

Here it is: https://github.com/pothosware/SoapyRTLSDR
And you should have access. :-)

from soapysdr.

Looks good, cheers!

from soapysdr.