Audio Messaging Interchange Specification. I am attempting to locate a copy of this rather old specification. Can anyone recommend where I might find this? All my searches have turned up endless references to glossaries but no actual specification.
Here is a start, but admitably it's not the complete specification. Perahps it's enough for your purposes though. There are actually two, AMIS-A (analog) and AMIS-D (digital).
Related
I have not used libbpf in a while. Now, when I'm looking at the source code and examples, it looks to me that all API now is built around bpf_object while before it was based on program FD (at least on the user-facing level). I believe that fd is now hidden in bpf_object or such.
Of course it keeps backward compatibility and I still can use bpf_prog_load for example, however it looks like the preferred way of writing application code using libbpf is by bpf_object API?
Correct me if I'm wrong. Thanks!
Sounds mostly correct to me.
Low-Level Wrappers
If I remember correctly, the functions returning file descriptors in libbpf, mostly defined in tools/lib/bpf/bpf.c, have always been very low-level. This is the case for bpf_load_program() for example, which is no more than a wrapper around the bpf() system call for loading programs. Such functions are still available, but their use may be tedious for complex use cases.
bpf_prog_load()
Some more advanced functions have long been provided. bpf_prog_load(), that you mention, is one of them, but it returns an error code, not a file descriptor. It is still available as one option to load programs with the library.
bpf_object__*()
Although I don't think there are strict guidelines, I believe it is true that most example now use the bpf_object__*() function. One reason is that they provide a more consistent user experience, being organised around the manipulation of an object file to extract all the relevant bytecode and metadata, and then to load and attach the program. One other reason, I think, is that since this model has been favoured over the last releases, these functions have better support for recent eBPF features and the bpf_object__*() functions offer features that the older bpf_prog_load() workflow does not support.
Libbpf Evolves
At last, it's worth mentioning that libbpf's API is currently undergoing some review and will likely be reworked as part of a major v1.0 release. You may want to have a look at the work document linked in the announcement: Some bpf_object__ functions may be deprecated, and similarly there is currently a proposal to:
Deprecate bpf_prog_load() and bpf_prog_load_xattr() in favor of bpf_object__open_{mem, file}() and bpf_object__load() combo.
There is nothing certain yet regarding the v1.0 release, so I wouldn't worry too much about “deprecation” at the moment - I don't expect all functions to be removed just yet. But that's something you may want to consider when building your next applications.
actions SDK does not recognize any other intent from the action.json.
I've read that that is not a bug in this post: unable to read intents
What I don't understand is why do we have the option to define actions, if they are not recognised by the SDK?
Is there any other way to add more intents without using DialogFlow?
That is correct, it is not a bug. The Intents listed in the actions.json file are primarily used to do matching for the initial Intents (plural - they help identify which initial Intent to use if you have multiple ones defined). They can help to do conversation shaping and suggest what patterns the speech-to-text parser should look for, but they don't mandate the parser follow them - I would venture this is intentional to allow for flexibility in the various Natural Language Parsers.
The latter is probably why they're, ultimately, not used. Unlike Alexa, which requires a wide range of exact text to match for its Intent definitions, Google probably started going that route and realized that it would be better to hand it off to other NLPs, either your own or commercial ones, which could handle the flexibility of how humans actually speak. (And then they bought one to provide as a suggested tool to use.)
So the Actions SDK has primarily become the tool to use if you do intend to hand the language parsing off to another tool. There isn't much advantage to using it over any other tool otherwise.
You're not obligated to use Dialogflow. You can use any NLP system that will accept text input for the language you need. Google also provides direct integration with Converse.AI, and I suspect that any other NLP out there will provide directions of how to integrate them with Actions.
Is there an official specification for the point cloud data (PCD) format? Or is it rather only intended for PCL-internal use? The only information I found about it is this which kind of looks like a specification, but it doesn't contain all the information needed.
I might want to write a PCD loader library (independent of PCL), but maybe this is discouraged?
Naturally, PCD files are mostly used in PCL-enabled applications written in C++. However, there are loaders implemented in other languages, for example Python and JavaScript, so it is definitely not just a PCL-internal format.
To my knowledge, there is no official specification besides the one you already linked. And indeed, it is incomplete, for instance the binary_compressed data storage format is not mentioned at all. I would suggest to use the PCL implementation (which is fairly stable) as a reference and resolve any ambiguities in the linked document by checking how the code works.
I've been hard pressed to find anything in search engines. It seems that adding "video" to the search query makes the search engines think that I want to watch a video [tutorial].
How do I read, play, and potentially (though this is not presently necessary) edit video files with Scala?
What libraries are available? What general useful information can you give?
I'm not much aware of any video processing libraries specifically for Scala, but you can use pretty much anything that works for Java. Out of my head, I would suggest taking a look at Processing and its video library. You might then go directly to the source libraries they use, e.g. gstreamer-java.
How would you go about comparing a spoken word to an audio file and determining if they match? For example, if I say "apple" to my iPhone application, I would like for it to record the audio and compare it with a prerecorded audio file of someone saying "apple". It should be able to determine that the two spoken words match.
What kind of algorithm or library could I use to perform this kind of voice-based audio file matching?
You should look up Acoustic Fingerprinting see wikipedia link below. Shazam is basically doing it for music.
http://en.wikipedia.org/wiki/Acoustic_fingerprint
I know this question is old, but I discovered this library today:
http://www.ispikit.com/
Sphinx does voice recognition and pocketSphinx has been ported to the iPhone by Brian King
check https://github.com/KingOfBrian/VocalKit
He has provided excellent details and made it easy to implement for yourself. I've run his example and modified my own rendition of it.
You can use a neural networks library and teach it to recognize different speech patterns. This will require some know how behind the general theory of neural networks and how they can be used to create systems that will behave a particular way. If you know nothing about the subject, you can get started on just the basics and then use a library rather than implementing something yourself. Hope that helps.