Breaking changes in SDRPlay API
Breaking changes in SDRPlay API
Dear SDRPlay team
Here's a request:
Could you please mention the breaking changes when you release a new API, so other developers/etc can do something about it? (although in a perfect world, it would be nice not to have any breaking changes)
While compiling an open source project, I realized that it can't be compiled, because of the recent change to "mir_sdr_StreamCallback_t" 's signature (the addition of hwRemoved parameter) in API 2.13
I didn't find any announcement regarding this change in your API release notes or the specification.
Although you contribute code to popular projects like Soapy, other less-known projects could also use these announcements to be able to react in a timely manner and update their code
Best regards
Here's a request:
Could you please mention the breaking changes when you release a new API, so other developers/etc can do something about it? (although in a perfect world, it would be nice not to have any breaking changes)
While compiling an open source project, I realized that it can't be compiled, because of the recent change to "mir_sdr_StreamCallback_t" 's signature (the addition of hwRemoved parameter) in API 2.13
I didn't find any announcement regarding this change in your API release notes or the specification.
Although you contribute code to popular projects like Soapy, other less-known projects could also use these announcements to be able to react in a timely manner and update their code
Best regards
Reason: No reason
DF2HF, NM9A, EP2C
Re: Breaking changes in SDRPlay API
You are correct, there is indeed an extra parameter required in the stream callback, which I should have made developers aware of. I've spent quite a bit of time over the last week or so having discussions with developers about the change between 2.11 and 2.13 and rebuilding as much as I can.
Any developer struggling to use the API can email me at software@sdrplay.com
The addition of the hwRemoved parameter in the stream callback defintion is the only thing that will cause compilation issues.
Best regards,
Andy
Any developer struggling to use the API can email me at software@sdrplay.com
The addition of the hwRemoved parameter in the stream callback defintion is the only thing that will cause compilation issues.
Best regards,
Andy
Reason: No reason
Re: Breaking changes in SDRPlay API
Hi,
can't resist to remind that it would be great if SDRuno could be run without any RSP available. My RSPs are doing full duty 24/7, and I still have hundreds of gigabytes of wideband mid-winter MW IQ-recordings to listen - but I can't do that without an 'available' RSP.
73, Jukka
can't resist to remind that it would be great if SDRuno could be run without any RSP available. My RSPs are doing full duty 24/7, and I still have hundreds of gigabytes of wideband mid-winter MW IQ-recordings to listen - but I can't do that without an 'available' RSP.
73, Jukka
Reason: No reason
Re: Breaking changes in SDRPlay API
Current versions of SDRSharp will playback SDRPlay I/Q files. No driver required.
Reason: No reason
Re: Breaking changes in SDRPlay API
Ok Mike, also HDSDR does that, but I would like to use SDRuno.Mike2459 wrote:Current versions of SDRSharp will playback SDRPlay I/Q files. No driver required.
73, Jukka
Reason: No reason