Add option for running ffmpeg_microphone_live as a background process
Author: mikamerath
Pull request: yes
Labels: name: Audio

# What does this PR do?
Gives the options for developers using audio_utils to fun `ffmpeg_microphone_live` as a background process instead of defaulting to STDIN which is the default option for ffmpeg. Useful for cases when running a different process that is using STDIN. The default case behavior is the same and now `ffmpeg_microphone_live` takes a boolean argument that allows the ffmpeg equivalent of passing in `-nostdin`.

<!--
Congratulations! You've made it this far! You're not quite done yet though.

Once merged, your PR is going to appear in the release notes with the title you set, so make sure it's a great title that fully reflects the extent of your awesome contribution.

Then, please replace this with a description of the change and which issue is fixed (if applicable). Please also include relevant motivation and context. List any dependencies (if any) that are required for this change.

Once you're done, someone will review your PR shortly (see the section "Who can review?" below to tag some potential reviewers). They may suggest changes to make the code even better. If no one reviewed your PR after a week has passed, don't hesitate to post a new comment @-mentioning the same persons---sometimes notifications get lost.
-->

<!-- Remove if not applicable -->

Fixes #30061 

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request),
      Pull Request section?
- [x] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?


## Who can review?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

- pipelines: @Narsil

<!-- Your PR will be replied to more quickly if you can figure out the right person to tag with @

 If you know how to use git blame, that is the easiest way, otherwise, here is a rough guide of **who to tag**.
 Please tag fewer than 3 people.

Models:

- text models: @ArthurZucker
- vision models: @amyeroberts
- speech models: @sanchit-gandhi
- graph models: @clefourrier

Library:

- flax: @sanchit-gandhi
- generate: @zucchini-nlp (visual-language models) or @gante (all others)
- pipelines: @Narsil
- tensorflow: @gante and @Rocketknight1
- tokenizers: @ArthurZucker
- trainer: @muellerzr and @SunMarc

Integrations:

- deepspeed: HF Trainer/Accelerate: @muellerzr
- ray/raytune: @richardliaw, @amogkam
- Big Model Inference: @SunMarc
- quantization (bitsandbytes, autogpt): @SunMarc

Documentation: @stevhliu

HF projects:

- accelerate: [different repo](https://github.com/huggingface/accelerate)
- datasets: [different repo](https://github.com/huggingface/datasets)
- diffusers: [different repo](https://github.com/huggingface/diffusers)
- rust tokenizers: [different repo](https://github.com/huggingface/tokenizers)

Maintained examples (not research project or legacy):

- Flax: @sanchit-gandhi
- PyTorch: See Models above and tag the person corresponding to the modality of the example.
- TensorFlow: @Rocketknight1

 -->


Comments:
cc @ylacombe 

@amyeroberts @ylacombe The project I'm working on is depending on this change. If there's any clarifications I can make about the motivation of this feature please let me know 😄 

@amyeroberts @ylacombe thank you for looking at this. It is hard for me to get a minimal working example because the problem is a little bit convoluted. Today or tomorrow, I can attach a GIF showing the problem and I'll try to come up with a minimal script that reproduces the error.


![NotWorking](https://github.com/user-attachments/assets/b326d770-a661-4cda-8215-351b55729248)
![Working](https://github.com/user-attachments/assets/49c3f1fb-36f8-444e-a0f2-8fd298537d39)


@amyeroberts @ylacombe Sorry for the long wait. This bug is hard to reproduce with a minimal example so I'll try to explain the motivation and what is causing it. We're using Whisper's speech to text for a project that has a local client/server connection. This connection uses IPC (which in turn uses STDIN) to pass messages back and forth.

When running our project, we would notice that part of the logs would include the message `Enter command: <target>|all <time>|-1 <command>[ <argument>]`. While investigating the error, I stumbled upon [This StackExchange Post](https://unix.stackexchange.com/questions/36310/strange-errors-when-using-ffmpeg-in-a-loop) that discussed similar errors when using ffmpeg. One of the solutions mentioned that ffmpeg uses STDIN by default and passing `-nostdin` which disables interaction. When adding `-nostdin` to the end of the arguments in `ffmpeg_command` the problem goes away, as demonstrated by the pictures attached at the top of this message. The first photo shows the error as it occurs now, while the second photo shows the behavior when this change has been made.

So I wanted to make a minimal change that would allow this feature to solve this issue. The default behavior stays the same, but it adds the ability to pass `-nostdin` so ffmpeg is not in interactive mode. I have tested it thoroughly with the present changes and it works perfectly. If you have additional questions or concerns, I'm happy to answer them.

@amyeroberts @ylacombe Any updates on your thoughts?

@mikamerath Thanks for providing this information! This seems like quite a niche use-case and not an issue that hasn't been brought up before. 

I'd propose one of two things: 
* Adapting the microphone logic such that any additional arguments can be passed to ffmpeg to configure its usage. This way, we don't have to add and handle a new flag for everything in ffmeg. 
* Don't merge this PR and reopen if other people in the community request this feature in the future

@amyeroberts Sounds good, I'll update this pull request this weekend to allow any additional arguments to be passed to ffmpeg.

@amyeroberts The code has been updated to allow additional arguments to be passed into `ffmpeg_microphone_live` by passing a list of additional arguments via `ffmpeg_additional_args` 

@amyeroberts I believe everything should be good now. Let me know what you think.

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_32838). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

@ArthurZucker Yes, I'm planning on adding a test for passing in arguments and not passing in arguments. Does that seem like it covers everything that you would want to see?

@ArthurZucker Tests have been added.

Is there anything else I need to do?