General Discussion - Thread #1
Comments
|
Cool... |
|
I saw your commit associated with retdec. It’s not the same sort of tool, but Ghidra can also be useful to investigate the inner workings of a binary |
|
Yes, ghidra exports were in the archive since first commit, however with decompiling/disassembling ARM binaries/libraries, there is problem, that the type of function arguments and return type cannot be detected automatically. If you've got any hints on this topic, i'd be glad for your input |
|
I didn’t realise your end goal was decompilation and recompilation . I don’t know about this implementation, but the version in the MD-380 and other TYT radios has hundreds of functions; so getting Everything to recompile will be a lot of work. I am not even sure if it’s necessary work, since most people will just want to call the encode and decode functions and won’t care what goes on inside those functions. The only thing, which I am not sure is fully understood with the TYT version of the codec is whether it’s possoble to change the tonal values of the compression , like the settings in radios like the Anytone 868 which use a hardware codec chip. In the OpenGD77 firmware, which uses the TYT codec from the manufacturer firmware, for some unknown reason, the Rx audio sounds cleaner and chrisper than in the official TYT ( aka Radioddity ) firmware. BTE. Baofeng also use the same codec, since all the firmware for all these Chinese DMR radios is written by a Chinese dev company, and not originally by the hardware manufacturers. |
|
It's not that I want to do that. However since the source is Android shared library, it's compiled against Bionic instead of (g)LIBC and qemu-arm is not capable of running such environment. So I have two choices, conduct all experiments on Android/ARM devices, or understand the inner workings of the library, decompile each function related to dvsi/ambe and try to work it out this way. If you'd know of any way how to run Android compiled shared libraries in Linux/Windows environment, without actual Android VM, i'll gladly take that route. In the end, I want to use the library and its functions to run encoding/decoding of the audio in linux x86 compatible environment |
|
I assumed you wanted it mainly to run on the RPi. I spoke to N4IRR on TAC 312 the other day and he told me that there was a wrapper to run the MD-380 codec binary, but I've tried emailing him to ask for more details but he hasn't got back to me :-( You could try getting his email from QRZ.com and emailing him about it, in case that helps with your emulation on the X86 platform |
|
I wrote him an email, but I suppose, he was talking about https://github.com/travisgoodspeed/md380tools/wiki/MD380-Emulator ? |
|
I added udp encode and decode to the emulator. It can be run on x86 using emu qemu-arm md380tools/emulator/md380-emu -S 2470 N4IRR |
|
Hi Michael, We spoke on TAC 312 last week, (you where on the train) but I was no able to get in touch with you via email for some reason. Anyway. Thanks for the link, because Kai DG4KLU is currently having some problems with the data produced by the TYT / Radioddity codec binary, so having other ways to compare the data could be useful. Was also thinking I could add voice prompts to the Kai's OpenGD77 firmware, by encoding some synthesised speech using the codec in the emulator, and then storing the encoded data for each word e.g. "Channel", "0","1","2" etc in the external Flash memory. And then playing that back by feeding the data into the firmware's decode system, as if the audio came from the DMR data stream. I presume since the data is heavily compressed it would not take up too much space, and could be a useful feature for visually impaired operators. VK3KYY |
|
You should have no problem using the emulator to encode a set of samples. The encoder takes 160 bytes of 16 bit signed PCM and produces 7 bytes of AMBE. |
|
Excellent We should be able to add voice prompts to the OpenGD-77 firmware and use hardly any of the 1M byte external flash |
|
Did you manage to get voice frames decoded through the source of the original app? |
|
@Nokoa i gave up my attempts and i'm now pursuing pure implementation using oboe sound library for android if you want to pick up some knowledge or continue in the efforts, see beon branch If I remember correctly, and i kept no notes on my progress sincerely, this compiles, can be used to init encoder and decoder function in single instance, however from time to time, segmentation fault appears. And since I have no knowledge on p25 (and the library calls require this), i am unable to progress further. |
|
Thank you! I didn't notice there was another branch. I did run this just to try and I noticed it is generating sound, but it almost sounds garbled, but with the sound of how to vocoder sounds. As if the vocoder is not setup with the correct rate. Is this a part that also didn't work for you? |
|
@Nokoa ad rate/config: Also input data, https://github.com/OK-DMR/ambe-codec-p25/blob/beon/app/src/main/cpp/mmdvm.cpp#L16 I have different one in the works,, that is based on manually merged imbe_vocoder and some other projects into compilable cpp library, see https://github.com/OK-DMR/ambe-codec-p25/tree/imbe/app/src/main/cpp Do you have any interest in pursuing these topics? Let me know |
|
I have never really worked with MMDVM. I am less on the Ham Radio side, more on the scanning side. Just looking for a better vocoder for my listening experience. I just got it to decode the audio properly. I had to give the vocoder frames that are already error corrected. With the error bits removed. So not the full 72 bits, but 49 bits. However I had to make the array of frames really short, otherwise the player caused the app to crash every time I tried to play. All in all, the vocoder is working!!! |
|
Yeah the implementation sucks, as i was not able to test and tune quality, never got to that phase actually. Can you share example array or diff of branch please? |
|
Note that I also had to comment out the encode initialization function. Otherwise it was also causing it to crash. So I am only initializing the decoder. I am getting errors such as
or
and
That come with a crash. I am also wondering how would you go about resetting the vocoder, so you can switch between the modes. Half rate, full rate, decode, encode. Also wondering whether there is a decode mode that does error correction and receives the full 72 bits for half rate mode. In addition whether it's actually possible to decode multiple calls at the same time, which seems like it might be fast enough to do now. However I believe that at some instances the vocoder looks at the previous frames to make certain decisions, so mixing multiple call may cause issues? On the hardware devices depending on the version 3000/3003, you can only do a limited number of channels, with a limited numbers of frames fed to the device at any given time. This is some Tait DMR. I am only able to play a small part of this. Anything long causes a crash. |
|
Wonderful @Nokoa great work Regarding resetting, we're in high-level programming, you can create multiple instances of the class probably. There are actually classes, that has self-explanatory names, such as I believe, you should just instantiate VoiceDecoderAmbeHalfRate for decoding, VoiceEncoderAmbeHalfRate for encoding, one will work with incoming queue from radio network, second will be fed samples from microphone and used to construct voice bursts. eg. where AmbeVocoder is much simpler And for the crash, i'd suspect my code handling the samples is faulty, you can feed it all samples before starting playback, i've not yet tried continuous buffer handling with jitter, because again, this is not something i understand in-depth. |
|
Also, is/should vocoder be deterministic, eg. if I have AMBE data, i decode them, encode them, do i get the same AMBE data i started with? Can those be compared in terms of content, BER, FEC or any other params? I'd like some quality estimation or comparison, to be able to fine-tune the implementation. |
On the BeOn java decompile i do see that they have an interface for the AmbeVocoder same as what you did. I am not certain how to use the P25 specific one. I did try to initialize 2 instances of AmbeVocoder, and tried reinitializing the one. Both led to errors. I also tried to see if I can have Java pass the frame data to C++ and then return the pcm audio to Java. But I got all sort of weird looking data on the Java side. Also it was crashing half the time if not all the time with every change I made on the C++ code. I had similar issues when playing around with the vocoder on MD380 emulator. But that can just be me. The speech from the microphone encoded through the vocoder cannot be reversed. The resulting speech is completely different. You will not get the same frames back. Half rate is usually 72 bits with error correction bits. I have yet to try full rate, or any encoding at all. |
|
AMBE full rate also working at 88 bits, deinterleaved without error correction bits.
|
No description provided.
The text was updated successfully, but these errors were encountered: