Skip to content

Commit

Permalink
Download link refers to Releases tab now
Browse files Browse the repository at this point in the history 
Because I actually use the Releases tab now (lol), I can now refer to it instead of the lame exe file inside the repository.
  • Loading branch information
GrimReaperFloof committed Sep 7, 2019
1 parent bfb5e48 commit 5125121
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion README.md
View file
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
![Logo Image](http://i.imgur.com/Nryqfgk.pngg)
## Source Audio Mixer and TTS

## [DOWNLOAD](https://github.com/GrimReaperFloof/STARK/blob/master/DOWNLOAD%20EXE%20FILE%20HERE/STARK.exe?raw=true)
## [DOWNLOAD](https://github.com/GrimReaperFloof/STARK/releases)

STARK is an application that allows you to read commands from Source games and playback audio files, or use Text-to-Speech.
This is a project that evolved from a proof-of-concept [axynos](https://github.com/axynos) made a while ago using AutoHotKey [link](https://github.com/axynos/CSGO-Text-To-Speech).
Expand Down

3 comments on commit 5125121

@axynos
Copy link

@axynos axynos commented on 5125121 Dec 30, 2019

Choose a reason for hiding this comment

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

I will reply here for your request about how to handle cross-platform compatibility for this.

The way I saw the future development for STARKv2 including cross-platform compatibility was this:

Build a common user interface component with a cross-platform solution such as Qt or Electron and then expose an API for each platform-specific release to integrate with.

For the audio part, you'd need two separate parts:

  1. An audio mixing engine to take in all the different audio streams and mix the volumes in-application
  2. Platform-specific native Loopback Device implementations to handle the final step that was key in the creation of STARKv1 - namely faking your output as an input device, so that games could use it as an input. STARKv1 let Virtual Audio Cable handle this (and the solution you mention VBCable could handle this too, good work!) instead of writing a native implementation, because I simply didn't have the skills necessary to build the solution myself.

For the Native Loopback Device, what you are looking to do, is write something called a Virtual Device Driver. I tried to do this, but eventually gave up because it seemed too hard at the time.

What I originally envisioned for STARKv2 was:

Handle the UI + Audio Mixing Engine with an application written on electron. Using electron would've given me access to WebRtc, which would've allowed me to handle the mixing with low latency - a critical point I wanted to improve in STARKv2. In addition to WebRtc, it would've allowed me to write a cross-platform responsive UI with minimal platform-specific implementation work.

Create an API that would talk with the platform-specific Node Native Addons, which would then talk with the platform-specific drivers/implementations to handle the final step - audio loopback.

This is clearly a lot of work, which eventually led me to abandoning the plans to create STARKv2. However, judging by the 4k downloads my original version has collected over the years, might be worth it. Who knows 😄

@fuck-shithub
Copy link
Owner

@fuck-shithub fuck-shithub commented on 5125121 Dec 31, 2019 •
edited
Loading

Choose a reason for hiding this comment

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

I will reply here for your request about how to handle cross-platform compatibility for this.

The way I saw the future development for STARKv2 including cross-platform compatibility was this:

Build a common user interface component with a cross-platform solution such as Qt or Electron and then expose an API for each platform-specific release to integrate with.

For the audio part, you'd need two separate parts:

  1. An audio mixing engine to take in all the different audio streams and mix the volumes in-application
  2. Platform-specific native Loopback Device implementations to handle the final step that was key in the creation of STARKv1 - namely faking your output as an input device, so that games could use it as an input. STARKv1 let Virtual Audio Cable handle this (and the solution you mention VBCable could handle this too, good work!) instead of writing a native implementation, because I simply didn't have the skills necessary to build the solution myself.

For the Native Loopback Device, what you are looking to do, is write something called a Virtual Device Driver. I tried to do this, but eventually gave up because it seemed too hard at the time.

What I originally envisioned for STARKv2 was:

Handle the UI + Audio Mixing Engine with an application written on electron. Using electron would've given me access to WebRtc, which would've allowed me to handle the mixing with low latency - a critical point I wanted to improve in STARKv2. In addition to WebRtc, it would've allowed me to write a cross-platform responsive UI with minimal platform-specific implementation work.

Create an API that would talk with the platform-specific Node Native Addons, which would then talk with the platform-specific drivers/implementations to handle the final step - audio loopback.

This is clearly a lot of work, which eventually led me to abandoning the plans to create STARKv2. However, judging by the 4k downloads my original version has collected over the years, might be worth it. Who knows

So you've been struggling with audio loopback for the most part? I get it, I've also been looking a lot for open source software to achieve that, but all I can find is Virtual Audio Cable and VBCable, and both are proprietary software. That kind of sucks. But this is only a problem on Windows. On Linux it's actually a lot easier. PulseAudio has loopback modules, and JACK just gives you full control over routing application audio to the speaker output.

So for Windows, it turns out we'll have to rely on proprietary software to do the work for us. If you skip trying to write your own device driver, you will be saving yourself a lot of work. Windows Audio just sucks I guess. If everything just worked with JACK, that would be heaven.

Also, you know I've been working on making a cross-platform alternative to STARK called SourceDJ right? I've written it in Python, and it currently uses gTTS for TTS (pyttsx3 didn't want to work correctly). It also uses PyAudio to handle the audio cross-platform.
It's still a bit clumsy and slow and has no user interface, but it somewhat works. I believe it currently doesn't behave nicely with Linux audio servers like PulseAudio and JACK due to how it keeps making new audio streams whenever an AudioQueue finishes playing all the audio data. I might have to look into that but god damn trying to get audio working was the hardest of all things. Because all the other audio libraries available for Python don't give you control over what audio devices you want to use, I had to use the low-level PyAudio library and handle all the audio myself.

Currently SourceDJ calls FFmpeg, which decodes the audio files into wav and gets piped back into SourceDJ, then SourceDJ reads the wav from the pipe and will concatenate the audio data at the end of the corresponding AudioQueue data array, which PyAudio plays audio from.

I'm not sure if this is a very clumsy method to do it, or if it's okay. This is the first time I'm working with audio low-level. At least I don't have to write code for every audio API out there, as PyAudio already does that for me.

@axynos
Copy link

@axynos axynos commented on 5125121 Dec 31, 2019

Choose a reason for hiding this comment

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

There is actually a windows port of Jack audio and I tried to write a solution with it, but for some reason I failed. I don't exactly remember why.

I've been told before that on Linux it's much easier and that's great, but the fact of the matter is that the main target audience would still be on Windows and personally, I want to step away from any kind of proprietary dependencies as that creates overhead for the end user. But then again, I'm no longer the active developer so it's not up to me. 😄

I have since switched to macOS as my daily driver - that's one of the reasons I stopped development of STARK. I simply wasn't the target audience anymore.

As for SourceDJ - I remember reading that somewhere before, yep. For the remaking new streams issue - I might be bullshitting, but if I remember correctly, somewhere in the STARKv1 pipeline, there is a circular buffer created by NAudio (the C# audio API I used) to keep a consistent output point that actually finally outputs the audio to the system that anything else can write to continuously.

I'm not that familiar with Python and it's ecosystem, so you're on your own there. 😄

Please sign in to comment.