Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Logging fixes #80

Merged
merged 12 commits into from
Apr 18, 2024
Merged

Logging fixes #80

merged 12 commits into from
Apr 18, 2024

Conversation

regularfry
Copy link
Contributor

I wrote this before I realised #76 existed, so apologies for that, but I've gone a little further:

  • Logging is mostly DEBUG rather than INFO so it's quiet by default
  • I've done the remaining bits in whisper_online_server.py too
  • The log level within faster-whisper is forced to WARNING so it doesn't make log noise for every processed chunk.
  • The transcription output is still just a print, which I figured was reasonable given that it's the important information.
  • I've added a --log-level command-line argument to control how verbose everything is, so if you want to see all the things, pass --log-level DEBUG and all will be revealed.

For convenience I've also added a requirements.txt and a separate cuda_requirements.txt, which gives me the right combination of versions today for faster-whisper not to complain about missing .so files. Happy to drop those and make a separate PR if that's too much all in one go, but it was literally the first thing I had to fix before I could do anything else.

@Gldkslfmsd
Copy link
Collaborator

I wrote this before I realised #76 existed, so apologies for that, but I've gone a little further:

* Logging is mostly `DEBUG` rather than `INFO` so it's quiet by default

* I've done the remaining bits in `whisper_online_server.py` too

I will check this and #60 later.

* The log level within `faster-whisper` is forced to `WARNING` so it doesn't make log noise for every processed chunk.

I'd like to have cmd option for this and the DEBUG level as the default.

* The transcription output is still just a `print`, which I figured was reasonable given that it's the important information.

ok

* I've added a `--log-level` command-line argument to control how verbose everything is, so if you want to see all the things, pass `--log-level DEBUG` and all will be revealed.

ok

For convenience I've also added a requirements.txt and a separate cuda_requirements.txt, which gives me the right combination of versions today for faster-whisper not to complain about missing .so files. Happy to drop those and make a separate PR if that's too much all in one go, but it was literally the first thing I had to fix before I could do anything else.

thanks but I don't want them -- the same reasons as in #29 .
You can suggest better wording of the installation instruction so that it's easier to prevent the missing .so files. In a new PR.

@regularfry
Copy link
Contributor Author

Happy to do the faster-whisper log level change and argument. What is it that you're using the DEBUG output for?

For the *requirements.txt question, I can remove them from this PR. It looks like the version issues should go away once SYSTRAN/faster-whisper#785 is resolved one way or another, so cuda_requirements.txt is only a temporary need while the faster-whisper README is wrong.

@Gldkslfmsd
Copy link
Collaborator

Happy to do the faster-whisper log level change and argument.

+1

What is it that you're using the DEBUG output for?

I believe that the debug output containing the transcribed/translated content can be used for easier bug detection and reproducibility. The outputs can be wrong but not crashing.
If anybody wants a production run without verbose logs, it's still possible with the option.

Copy link
Collaborator

@Gldkslfmsd Gldkslfmsd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! see comments to lines.

Also, please check #76 and apply the edits that are better there.

@@ -142,7 +148,7 @@ def format_output_transcript(self,o):
print("%1.0f %1.0f %s" % (beg,end,o[2]),flush=True,file=sys.stderr)
return "%1.0f %1.0f %s" % (beg,end,o[2])
else:
print(o,file=sys.stderr,flush=True)
# No text, so no output
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there should be at least debug log output

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 88a7f3a.

whisper_online.py Show resolved Hide resolved
@@ -44,25 +55,22 @@
demo_audio_path = "cs-maji-2.16k.wav"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please merge current main and update

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@regularfry
Copy link
Contributor Author

* The log level within `faster-whisper` is forced to `WARNING` so it doesn't make log noise for every processed chunk.

I'd like to have cmd option for this and the DEBUG level as the default.

What I've done here is to move the log level into the shared args, and defaulted it to DEBUG across the board. I'm not quite sure that was what you were after, but it does bring back the log info you were looking for.

I've also tweaked the log format so it tells you which logger the output's coming from. Sample output looks like this:

  $ ./run.sh ../whisper.cpp/samples/jfk.wav 
whisper-server-DEBUG:whisper_online: Loading Whisper large-v3 model for en...
whisper-server-DEBUG:urllib3.connectionpool: Starting new HTTPS connection (1): huggingface.co:443
whisper-server-DEBUG:urllib3.connectionpool: https://huggingface.co:443 "GET /api/models/Systran/faster-whisper-large-v3/revision/main HTTP/1.1" 200 2061
whisper-server-DEBUG:whisper_online: done. It took 1.31 seconds.
whisper-server-WARNING:__main__: Whisper is not warmed up. The first chunk processing may take longer.
whisper-server-INFO:__main__: Listening on('0', 2024)
whisper-server-INFO:__main__: Connected to client on ('127.0.0.1', 41130)
...

You can see the relevant __name__ in between the colons.

Is that what you're looking for?

@regularfry
Copy link
Contributor Author

For the *requirements.txt question, I can remove them from this PR.

Done at cc11b76.

@regularfry
Copy link
Contributor Author

At a first pass, I think that's it.

Also, please check #76 and apply the edits that are better there.

Is there anything in particular I'm missing here? @jcassee, anything you don't want left off?

Copy link

@jcassee jcassee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Gldkslfmsd @regularfry I added some comments. However, many are nit-picky, and this PR already makes the project strictly better in my opinion. So feel free to ignore most of it.

whisper_online.py Show resolved Hide resolved
whisper_online.py Show resolved Hide resolved
print(f"transcribing {len(self.audio_buffer)/self.SAMPLING_RATE:2.2f} seconds from {self.buffer_time_offset:2.2f}",file=self.logfile)
logger.debug(f"PROMPT: {prompt}")
logger.debug(f"CONTEXT: {non_prompt}")
logger.debug(f"transcribing {len(self.audio_buffer)/self.SAMPLING_RATE:2.2f} seconds from {self.buffer_time_offset:2.2f}")
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit-pick, and I also took shortcuts here so feel free to ignore, but formatting text in logs is better done using logger.debug("...%s...", value) because it avoids interpolation in case the log is not written because of the log level.

Similarly, if you create variables or do any processing just for logging (like in line 381 below) it is good form to wrap with if logger.isEnabledFor(somelevel):.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, agree. I'll tidy those up.

whisper_online.py Show resolved Hide resolved
@@ -611,14 +622,18 @@ def asr_factory(args, logfile=sys.stderr):
logfile = sys.stderr

if args.offline and args.comp_unaware:
print("No or one option from --offline and --comp_unaware are available, not both. Exiting.",file=logfile)
logger.error("No or one option from --offline and --comp_unaware are available, not both. Exiting.")
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think command line errors go to stderr explicitly. If you set the log level too high the command may confusingly fail without error message. (I think the file argument in the original was also a mistake.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, yes.

@@ -645,16 +660,16 @@ def output_transcript(o, now=None):
print("%1.4f %1.0f %1.0f %s" % (now*1000, o[0]*1000,o[1]*1000,o[2]),file=logfile,flush=True)
print("%1.4f %1.0f %1.0f %s" % (now*1000, o[0]*1000,o[1]*1000,o[2]),flush=True)
else:
print(o,file=logfile,flush=True)
# No text, so no output
pass
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems a functional change, but could be a good one. If o[0] is the emission time, the "no text" comment seems incorrect?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do we think? Is the emission time on a "no text" segment useful? Now you've said it I'm inclined to bring it back in, because otherwise the consumer has no clue that any silence has been processed.

print("assertion error",file=logfile)
pass
except AssertionError as e:
log.error(f"assertion error: {repr(e)}")
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have never seen these errors, would a full backtrace be useful here? (If so, log.exception would be better.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we were making changes here I'd be inclined to go the other way and say that a failed assertion should just crash the process. assert should be telling us that something's coded wrong, so to a certain degree all bets are off. That being said, given that I don't know what the original problem was that caused these exception handlers to be written, logging.exception is a good compromise if that seems overly harsh.

whisper_online_server.py Show resolved Hide resolved
whisper_online_server.py Show resolved Hide resolved
whisper_online.py Show resolved Hide resolved
@Gldkslfmsd Gldkslfmsd merged commit 88a7f3a into ufal:main Apr 18, 2024
@Gldkslfmsd
Copy link
Collaborator

Thanks, guys!
Sorry, I was lost in your conversation, it was too long. I did the changes that I liked and that I considered serious.
Like code deduplicating setting the log levels, with a simple hack.
Let's not overcomplicate it.

@jcassee
Copy link

jcassee commented Apr 18, 2024

@Gldkslfmsd @regularfry Thank you!

@regularfry
Copy link
Contributor Author

Ah fantastic, thank you for that!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants