Skip to content
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

Integrate with SampledSignals.jl? #24

Open
Keno opened this issue Sep 13, 2021 · 3 comments
Open

Integrate with SampledSignals.jl? #24

Keno opened this issue Sep 13, 2021 · 3 comments

Comments

@Keno
Copy link
Collaborator

Keno commented Sep 13, 2021

https://github.com/JuliaAudio/SampledSignals.jl

Would be good to asses whether this is a worthwhile integration.

@mbaz
Copy link

mbaz commented Sep 13, 2021

I remember reading somewhere (discourse?) that SampledSignals was basically stagnant and in need of a re-write, but I can't find that message now. It would be a good idea to get up to speed on the state of the various related packages.

@sjkelly
Copy link
Collaborator

sjkelly commented Sep 13, 2021

I did a quick audit. Conceptually it is mostly similar, though we have some differences in abstraction. One thing I am keen on is giving us windows into controlling and introspecting latency, which should be addressed in #22. This does not seem to be handled in SampledSignals. This means keeping around time stamps and such. I also am doing a minor rework today to make sure we can handle CuArray and others without copy, something also missing there. EDIT: This doesn't work.

Though I generally think these types of software<->hardware interfaces could use a common abstraction. These things are no longer simple serial port IO. May be good to roll with what we have for now and bring some minds together to work on a common spec in the future. Maybe similar in spirit to the FileIO organization.

@sjkelly
Copy link
Collaborator

sjkelly commented Sep 14, 2021

On a more cursory audit I think SampledSignals is really good for the SDR use case (with some massaging, which should be pretty easy to SoapySampleSource <: AbstractSampleSource). Though I do think what we have here is mostly sufficient. I generally worry about dependency/scope creep. This is "Julia Wrappers for SoapySDR", and I think we are already few more rungs up the abstraction ladder here than we should be already. Maybe we look to back-ending SoapySDR to AbstractSDRand do more high level work with SampledSignals there?

cc @RGerzaguet

@sjkelly sjkelly mentioned this issue Oct 5, 2021
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants