-
Notifications
You must be signed in to change notification settings - Fork 175
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New SoapyRTLSDR Support Module #33
Comments
Did a quick check with three different dongles:
All three are working fine, but audio is a little bit choppy, independent of bandwidth setting. |
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 underflow in readStream some notes about readStream 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 |
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! |
@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! |
I took a look at the project earlier today. Looks good to me! To transfer a repository, go to repository settings and hit transfer On my end, I probably will get an approval message. Never done it before though! |
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. |
Ok, transfer request sent! |
Here it is: https://github.com/pothosware/SoapyRTLSDR |
Looks good, cheers! |
I've pushed up a working standalone RTL-SDR Support Module; still needs a lot of tweaking but it's mostly functional :)
https://github.com/cjcliffe/SoapyRTLSDR
The text was updated successfully, but these errors were encountered: