> I think it's clear now that the current state of UHD doesn't include all > the features that you want, so I think we can close out this thread.
Or put it another way. Before this reply, it was never mentioned or confirmed that what I want was impossible with 3.11 so I thought the methods you provided are recommended or official solution of how these should be done in the new version of the library. IMHO though, those solutions are either not answering my question or has far greater impact that's not really usable as a general solution and that confused me a lot. If, instead, they are just work around for the missing feature, then sure, I understand how to use those and have actually thought about all of them before posting. In that case, this should be treated as a bug report of a feature regression as mentioned in my previous email. > For the record, it is perfectly reasonable to ask for additional > features here, and a runtime-disabling of the fastpath messages is not > something that is terribly complicated to implement. However, please > consider that while *your* particular application would like to have a > UHD feature that doesn't exist, this hasn't come up before, and we > balance feature requests (of which we get a lot) based on frequency of > request, perceived importance, etc. We are very happy to add features > that people need, but we can't anticipate all possible things people > could potentially ask for. > >> (And if one has to compile the library, why does the ettus uhd PPA > exists....) > > I'm not sure if this is a legitimate question, or if you're complaining > that the PPA is not configured to your particular taste, but the purpose > of the PPA is to provide *one* standard configuration of UHD as a binary > state. Other users might require other configure/compile time settings > (maybe disable certain boards, change default paths, etc.), and in that > case, same as yours, recompiling is the correct option. Providing > binaries for every version *and* every combination of UHD settings would > be nice, but it's also not feasible. > > Regards, > Martin > > _______________________________________________ > USRP-users mailing list > [email protected] > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com _______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
