Po odpaleniu procesu, proces bardzo laguje

Siema, gdy używam procesu z przechwytywaniem outputu to mi tak jakby proces laguje czyli działa co minutę na minutę. Unity działa git, nie ma żadnych lagów. Skrypt python'a jak go odpalę w terminalu tez działa git. Dopiero jak to połączę to dziwnie działa. Kod C# powinien działać bo jak łączyłem go z Python'em który korzystał z MediaPipe to działało git.

Kod C#: https://github.com/NintyS/TranslatorOverlay/blob/main/Assets/Text.cs
Kod Python'a: https://github.com/alphacep/vosk-api/blob/master/python/example/test_microphone.py

Zgaduję że musisz flushować output w pythonie:

sys.stdout.flush()

Jeśli chcesz to poprawić po stronie c# to z tego co wygogloowałem, możesz skorzystać z eventów typu process.OutputDataReceived zamiast czytać zwyczajnie z process.StandardOutput
https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.process.outputdatareceived?view=net-7.0

Jeśli zrobisz to na asynchronicznych eventach to możesz też zrezygnować z osobnego threada

Dziękuję Panie i wybawicielu!

Nie wiem jakie zadanie realizuesz, są takie dla których podproces jest sensowny, ale dla wielu nie jest.
Interpretery się szybko odpala w programie hostujacym (a zintegrowany może być każdy niuians)
Dla tej pary języków jest to

https://ironpython.net/

ja osobiscie BARDZO żałuję, że javowski odpowiednik odpadł na zakrętach Python 2 -> Python 3, dotnetowy jest aktualny.
Milion lat temu integrowałem Pythona jako język wewnętrzny C/C++, znaczny to był projekt, i pięknie to szło, w najmniejszym stoniu nie było "kopniaków w du..ę" ze strony kiepskiego narzędzia

ZrobieDobrze napisał(a):

Nie wiem jakie zadanie realizuesz, są takie dla których podproces jest sensowny, ale dla wielu nie jest.
Interpretery się szybko odpala w programie hostujacym (a zintegrowany może być każdy niuians)
Dla tej pary języków jest to

https://ironpython.net/

ja osobiscie BARDZO żałuję, że javowski odpowiednik odpadł na zakrętach Python 2 -> Python 3, dotnetowy jest aktualny.
Milion lat temu integrowałem Pythona jako język wewnętrzny C/C++, znaczny to był projekt, i pięknie to szło, w najmniejszym stoniu nie było "kopniaków w du..ę" ze strony kiepskiego narzędzia

A, dziękuję, przyda się.

ZrobieDobrze napisał(a):

Nie wiem jakie zadanie realizuesz, są takie dla których podproces jest sensowny, ale dla wielu nie jest.
Interpretery się szybko odpala w programie hostujacym (a zintegrowany może być każdy niuians)
Dla tej pary języków jest to

https://ironpython.net/

No tak idąc dalej to w ogóle w tym przypadku pewnie nie jest potrzebny python. Ta sama biblioteka która jest używana tam w pythonie do rozpoznawania mowy (kaldi) jest dostępna bezpośrednio dla C#
https://github.com/alphacep/vosk-api
A nawet jest specjalne wsparcie dla Unity:
https://alphacephei.com/vosk/unity