Forum Replies Created
-
Posts
-
@MrKlorox This is the answer directly from the man who made it.
“The Input AGC in the breakaway core, as used in both BreakawayOne and Omnia.9, is _not_ multiband, and never was.
The reason is quite simple — it would suck the life out of the music.
For example, Orban processors use a coupled 2-band input AGC – BASS and MASTER. The coupling means that the bass can never be boosted more than the rest, but bass _can_ be reduced more than the rest, which is the entire purpose, because in a wideband AGC, if you suddenly have lots of bass in the input, you will hear the overall audio getting much quieter due to how much energy bass has compared to the perceived loudness of said bass.
The disadvantage of doing it this way is that when you play bass heavy music, particularly of the electronic variety, all the bass gets sucked out of it right at the Input AGC stage, resulting in wimpy sound.So, the breakaway core uses an in my opinion much better compromise. I use a wideband AGC with a _sidechain filter_ to essentially _desensitize_ the Input AGC to heavy bass. This way, excessive bass goes right through the Input AGC without causing much gain reaction, making the Input AGC response much more closely to how we _perceive_ loudness. This in turn means that excessive bass will enter the Multiband AGC section (which indeed both BreakawayOne and Omnia.9 has, of course!) which is actually equipped to handle it.
I made sure my audio processors can handle deep bass for the simple reason that I like music with heavy bass, as well as a whole lot of other genres. This is not the case with every audio processing developer, and if it’s not part of your playlist when you’re designing the audio processor, chances are the processor you’re designing won’t gracefully handle it.
Anyway, the Input AGC in BreakawayOne is in fact identical to Omnia.9, with the exception that Omnia.9 lets you adjust the sidechain filter exactly. Believe me when I say that this is not a limitation – I _never_ adjust it myself, it already handles everything I throw at it (from Pat Metheny to Count Basie to Infected Mushroom), I haven’t had to touch that slider for a decade.”
Hmm. Sounds like a teeny bug, possibly a caching issue. I know that Breakaway One scans each time it starts, in case a new encoder has just been installed, so it is odd that you need to re-boot to force it to update.
Are the relevant exe files in the BA folder?
@MrKlorox
I will forward your query on in its entirety so it maintains context. I’ll post any response here.If you use the BaRemote program, you can export the configuration “ini” files in Common > System > System Information > Backup Configuration.zip. This will produce a zip file of all the current settings (you get to option to specify where to save it). These files/folders by default actually live in {drive letter}/Users/{username}/AppData/Local/BreakawayOne.
So, to duplicate BA1 on another PC, here’s what I would do.
On “Master PC”
1) Export the zip file and copy it via USB or network to a temp folder on PC 2On “Slave PC”
1) Install fresh copy of Breakaway One
2) Export the default zip file so that you have a point to return to if things go wrong.
3) Copy the unzipped files from “Master” into the {drive letter}/Users/{username}/AppData/Local/BreakawayOne folder
4) Launch BA1. It should start and have the settings from PC1, but it will be running in demo mode because the licence will not match the MAC address.Adjusting the FIFO buffers will have some effect, but the real reduction in jitter will come from adjusting the input/output buffers in the BreakawayOne Config app. I would run the wizard first, and then see if tweaking the buffer size makes any improvement.
As stated elsewhere, jitter is simply a percentage of discarded frames because the incoming samples “didn’t fit”. This is why usually (but not always), the buffer count should be a multiple of the sample rate. For instance, if the sample rate is 44.1, theoretically buffers of 441 or 882 would “fit” all samples, with very few frames rejected. However, it takes longer to fill 882 buffer than 441, so this introduces latency, because nothing is passed to the output until the input buffer is filled with samples.
A low jitter rate would probably not produce audible artefacts, simply because there are enough useable complete frames to mask the dropouts. The higher the jitter percentage, the more rejected frames, and therefore sooner or later, you will hear artefacts. I am amazed to hear reports of no dropouts with 100% jitter. The processor must be running on the edge to keep processing the frames and passing them to the output.
Latency simply comes from processor capability. The audio has to come into the input buffers, and then feed through the audio processing algorithm and preset parameters, and then pass to the output buffers. It stands to reason that the quicker it can do this, the less latency is going to be experienced. Sure it is possible to run BA1 on a very low powered CPU, but the latency will increase. Similarly, if you run a top-end i7, but have other CPU-cycle-hogging processes running on the same computer, BA1 will not get enough of the CPU time slice, and latency will be the result.
Just as a finely tuned race car delivers better speed and therefore more wins, a high speed CPU with very few other tasks running will deliver better latency.
I don;t have an instant answer, but I am also certain that the changes that were released in 3.30.93 were only relatively minor, to address long-standing requests. I very much doubt that the core processes were touched at all. I will try to source a Juli card to see if I can replicate your situation. Meanwhile, what happens if you roll back to the previous, working version?
If you are using the Breakaway Pipeline, you may need to edit the range in the Breakaway Pipeline Control Panel. It should be 41,000 to 192,000.
What is the maximum range showing in Windows Audio Properties?
What version of Windows?
The fact that both 1.42 and 1.44 both crash would tend to point to a problem within the nucleus of Windows, rather than BAE.
Are you removing the Pipeline as well? You may have to go into Device manager and uninstall the Pipeline devices manually (under “Audio Inputs and Outputs” in Win 11).
Remember to reboot after the uninstall, before attempting to re-install.I discussed this with Leif once before and his reasoning was that a lot of VSTs crash and it is easier to keep 16 bit VSTs in their own memory space so that it doesn’t crash Breakaway One as well.
I’ll raise it with him again. Maybe the tides have turned since then.
The MPX signal can carry the full FM bandwidth, whether mono or stereo. If you can switch easily between the two, why not try it on an experimental broadcast? In stereo, the 19 kHz pilot tone should automatically be generated, and stereo receivers should then respond to that.
Well, the MPX signal is a L/R composite, so, if the input is stereo, the output will also be stereo. You will need to ensure that your deviation is within legal limits, of course, so you may have to tweak a preset to suit your format.
The general aim is to minimise the jitter figure, because that number represents the number of “lost” frames where the incoming (your playout software) data doesn’t quite fill out the sound device’s buffer size.
Sometimes, it is better to not use KS, even though that is the optimum setting, but you can always experiment and possibly come up with the best KS buffer size to give you the lowest jitter (and therefore) latency/jitter.
