search

drowe67 / codec2

Open source speech codec designed for communications quality speech between 700 and 3200 bit/s. The main application is low bandwidth HF/VHF digital radio.
GNU Lesser General Public License v2.1
201 stars 32 forks source link

WP2000 - Codec 2 Algorithm Description #31

Closed drowe67 closed 11 months ago

drowe67 commented 1 year ago

20

drowe67 commented 1 year ago

@tmiw - oh I'm sorry, did I press the review button by mistake? Or maybe GitHub requests a review automatically? Anyway, I've only just started. Its very much WIP, not needing any review at this stage

tmiw commented 1 year ago

@tmiw - oh I'm sorry, did I press the review button by mistake? Or maybe GitHub requests a review automatically? Anyway, I've only just started. Its very much WIP, not needing any review at this stage

I think I get emails whenever a PR gets created, not just when requested for review. Sorry for the confusion!

drowe67 commented 1 year ago

@tmiw - oh I'm sorry, did I press the review button by mistake? Or maybe GitHub requests a review automatically? Anyway, I've only just started. Its very much WIP, not needing any review at this stage

I think I get emails whenever a PR gets created, not just when requested for review. Sorry for the confusion!

That's fine. Actually at some stage it would be good to get feedback from Hams on what they would like to know about Codec 2, so I can answer the most common questions. Perhaps after a first draft of the document is ready.

drowe67 commented 11 months ago

@tmiw - I've set up a Makefile to build the document automatically, so we can make sure if doesn't suffer from bit rot, what do you think about:

  1. Should we build the doc as part of the ctests, or have a separate github actions hook? It will require a few more packages to be installed.
  2. Like freedv-gui - it will generate another codec2.pdf that clashes with the committed version. However I like the idea of having the PDF ready to read, and not require an end user to build it.
  3. Note the pdflatex build stuff is super verbose, but the doc is building OK for me on two machines.

@Tyrbiter - I've kicked off another review WP in #37, or feel free to review in this PR. I'm doing some proof reading myself, but I know I'll miss stuff.

drowe67 commented 11 months ago

OK, I've added the doc building as a ctest, as it needs c2sim built anyway.

tmiw commented 11 months ago

@tmiw - I've set up a Makefile to build the document automatically, so we can make sure if doesn't suffer from bit rot, what do you think about:

  1. Should we build the doc as part of the ctests, or have a separate github actions hook? It will require a few more packages to be installed.
  2. Like freedv-gui - it will generate another codec2.pdf that clashes with the committed version. However I like the idea of having the PDF ready to read, and not require an end user to build it.
  3. Note the pdflatex build stuff is super verbose, but the doc is building OK for me on two machines.

FWIW, freedv-gui uses GitHub actions for this but doesn't actually generate the PDF/HTML for the user manual until PRs are merged to master to avoid having to constantly deal with merge conflicts. It would probably be a good idea to also either have a ctest to verify document changes or somehow suppress the additional check-in for the module in the GitHub action unless the PR is being merged.

drowe67 commented 11 months ago

@tmiw - The doc ctest is bombing on GitHub, but works OK for me at home on three Ubuntu 22 machines. Could you pls take a look and see if there are any obvious issues?

drowe67 commented 11 months ago

@tmiw - I've set up a Makefile to build the document automatically, so we can make sure if doesn't suffer from bit rot, what do you think about:

  1. Should we build the doc as part of the ctests, or have a separate github actions hook? It will require a few more packages to be installed.
  2. Like freedv-gui - it will generate another codec2.pdf that clashes with the committed version. However I like the idea of having the PDF ready to read, and not require an end user to build it.
  3. Note the pdflatex build stuff is super verbose, but the doc is building OK for me on two machines.

FWIW, freedv-gui uses GitHub actions for this but doesn't actually generate the PDF/HTML for the user manual until PRs are merged to master to avoid having to constantly deal with merge conflicts. It would probably be a good idea to also either have a ctest to verify document changes or somehow suppress the additional check-in for the module in the GitHub action unless the PR is being merged.

The doc has it's own Makefile, so I was thinking of:

  1. If you really want to create a new codec2.pdf (say after editing) run the Makefile from the doc dir: 
    cd ~/codec2/doc
make
  2. If we are just testing the doc build procedure run the ctest: 
     cd ~/codec2/build_linux
 ctest -R test_codec2_doc

    We could configure the ctest version up to write the codec2.pdf to a temp dir so Git doesn't see it as a changed file.

tmiw commented 11 months ago

@drowe67, did you still want me to investigate why the ctest for the documentation isn't running in the GitHub environment? I haven't had time to get around to it yet but just noticed that you merged.

drowe67 commented 11 months ago

@drowe67, did you still want me to investigate why the ctest for the documentation isn't running in the GitHub environment? I haven't had time to get around to it yet but just noticed that you merged.

Sure if you want to that would be great. I've bumped that task to the further work WP: #37