asticode / go-astideepspeech

Golang bindings for Mozilla's DeepSpeech speech-to-text library

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Update with new API

lissyx opened this issue · comments

We recently merged a PR that exposes new information, via new API calls: mozilla/DeepSpeech@a009361#diff-0317a0e76ece10e0dba742af310a2362

This allows access to timing information. We have not yet updated our own bindings by exposing this, I can likely try and take care of that here as well.

Your PR would be most welcome!

@asticode I should be able to start working on that tomorrow, but I'd welcome any pointers / docs on how to properly expose structures and structures holding pointers to structures in Go, given my lack of knowledge in that language, any example / doc is useful :)

Thing is, structures containing C attributes should be handled differently than structures containing Go attributes as far as I'm concerned.

I'd simply recommend using getters/setters to access/write C attributes withing Go structs.

You can also check out this link or this one to learn more about native Go structs.

If anyone else have ideas, we're all ears.

Thing is, structures containing C attributes should be handled differently than structures containing Go attributes as far as I'm concerned.

I'd simply recommend using getters/setters to access/write C attributes withing Go structs.

Sounds like what I did for Rust bindings: RustAudio/deepspeech-rs@023dd85

Yeah, sounds like the safest route!

@asticode I'll first fix FreeString

@asticode https://stackoverflow.com/questions/28925179/cgo-how-to-pass-struct-array-from-c-to-go I've found that, trying to use however does not lead to something working. Code is available at https://github.com/lissyx/go-astideepspeech/commits/expose-metadata

This slicing "seems" to work, in the sense that it compiles and runs, but trying to range over it, I always get the first item, and looking at pointers it is always the same.

I always get the first item

That seems not true, I sometime get garbage, but always the same garbage value.

Okay, nevermind, it seems like this was because there was no C defintion being included for C.struct_MetadataItem