Decoding Opus Packets

Cliff - G4PZK

I am successfully receiving Opus audio packets both using C#, and latterly javascript via a websocket, but I am unable as yet to decode them to produce audio. I know from earlier posts that Opus packets of around 64 (32 bit) 'samples' are sent in each packet and also that the Opus stream is 2 channels 'sampled' at 24kHz but how do I decode them? If anybody has working C# code (probably with an external library) perhaps they could point me in the right direction?

I have even tried a javascript library without success. The Opus packets appear to be simply data packets without any form of packaging, eg ogg, and so even if I dump incoming data to a file and then attempt to play it back using vlc or audacity using ffmpeg I still cannot get any audio out.

As an aside I have successfully produced audio using a DAX channel and simply javascript player but of course there is no compression and the data rate is much higher.

Any pointers gratefully received of course.

Cliff, G4PZK

Doug - K3TZR

Cliff - G4PZK

Cliff - G4PZK

Doug - K3TZR

Cliff - G4PZK

Doug - K3TZR

Cliff - G4PZK

Doug - K3TZR

James Whiteway

Very interesting thread! Thanks for posting it here for all to follow along. I haven't really messed with audio decoding yet in my program. I am still trying to make my waterfall work properly. Being an over the road trucker gives little time for coding! James WD5GWY

Eric-KE5DTO

Take a look at POpus

Cliff - G4PZK

Cliff - G4PZK

Hi James,

Glad you found it interesting, programing the Flex is becoming an obsession for me now. The waterfall part of the coding is always tricky as it's quite complex in many ways.

Good luck when you get time to get it going.

Cliff, G4PZK

Doug - K3TZR

Cliff,

I agree that "it's complicated until you understand it", the problem for me is that after I understand it I forget it. It seems that once I finish something (e.g. Opus audio), a few months later while working on something else I need to go back to it and have to relearn a bit. It's one reason I've become a fanatical commenter, the comments are mostly for my own benefit.

It would be nice to have a thorough set of documentation to refer to. Since Flex produces the Radio (i.e firmware), the API (FlexLib) and the client (SmartSDR) they don't really need to share documentation with the rest of us. It's only as a courtesy to us that they provide the source for FlexLib. I sympathize with their efforts to document things (e.g. the Wiki). I've tried similar approaches and come away believing the code and the comments are the only documentation that will remain current.

I have done a large variety of languages starting at ones and zeros, then assembler .... I started my Apple project in Objective-C but switched whole-heartedly to Swift. I find Swift to be very powerful and relatively easy. I really like the Apple development environment (Xcode). What I like about Swift (different from C) is that one of its core objectives is to detect errors at compile time as opposed to run time.

I'm not aware of the problem you describe with Flex and TCP. As far as I know I have never failed to receive a reply to a TCP command. I think I'll add some code to verify that.