Possible issue with readStream before activateStream?

[cjcliffe]

Not sure if this is a SoapyRemote or SoapySDRPlay issue; but it appears when using SoapySDRPlay remotely that upon initialization readStream() is being called before activateStream() has been called.

Most notably on OSX it shows:

mir_sdr_ReadPacket: called before mir_sdr_Init()

and on Linux:

libusb_claim_interface() - 6 error:  interface has already been claimed

running SoapySDRUtil --make works fine.

SoapySDRPlay also initializes the device during enumeration to tell if it's there; not sure if that would be a factor here?

[guruofquality]

I think you are right. The setupStream spawns the handler threads for both endpoints. For transmit, this isnt an issue, the transmit thread will never actually call writeStream() until the client provides data. But for receive, the thread immediately starts calling readStream(), before active stream can be called by the client.

However, I think most of the implementations basically timeout in the read/writeStream() calls if activateStream() has not been called. activateStream() was supposed to be a comparatively lightweight call to enable streaming after setupStream() did all of the heavy lifting.

So SoapyRemote might be acting "rude" by calling readStream prematurely, but SoapySDRPlay might be doing way too much in activate. I'm still thinking about... Its not like I declared in the documentation ahead of time that this particular order of calls should be safe :-)

[cjcliffe]

I think this is ok if I know I should return timeout in this case; I think that would solve the issue we're seeing. It's possible I have some things in the wrong place and I'll review/compare that as well.

[guruofquality]

Keep in mind the timeout implementation is going to actually have to wait or sleep or it will end up with a 100% cpu loop in the stream thread.

[guruofquality]

Thinking about this more, if we couldn’t guarantee that it was safe to call readStream() before activateStream(), then its not super clear when the readStream() thread should be allowed to run -- because the activate/deactivate calls can handle advanced stream control like timed bursts. Even though there is an obvious answer in this case for SoapySDRPlay.

Also, we would loose the ability to have the threads setup ahead of time to be ready to go when the stream is activated. Its along the same lines of "setup stream does the costly setup and heavy lifting", "activate stream is doing lightweight minimal work enable/control the stream". And FWIW, SoapyRemote may not be the only instance where the stream API gets used like this because of how the user sets up threads for example.

So I think its best if SoapySDRPlay was robust against being read even before activation happens. And for that matter, any others if this issue also comes up.

[guruofquality]

Hopefully this wasn't too much of a "cop-out" coming up with the readStream() timeout before activate, but I think its for the best.

[cjcliffe]

Aye, seems to work ok here now; I don't have a problem with it just might want to document it somewhere.

[guruofquality]

Good idea. I added some comments about it: pothosware/SoapySDR@9e7e528