Forum Replies Created
-
Posts
-
No, I don't believe that is the case. Your announcers should be listening to the source (straight out of the mixing desk, or wherever your mic processing output is). In the good old days, before all the processing that occurs these days, we used to listen "off air", meaning that we heard what the listeners heard. However, that only works if the STL is not far away and therefore the difference between the input signal and the returned (broadcast) signal is only milliseconds, which our brain cannot detect. This was an advantage because we could detect instantly if the broadcast chain went down (as in a transmitter or STL failure).
Nowadays, there are many delays between the studio and, in the case of (say) a terrestrial FM broadcast (which might be almost straight out of the studio console) but also streamed through (say) Icecast, listening off the Internet would confuse even the most seasoned broadcaster.
Oh WOW! Welcome back, Oh Lord High Poo Bah.
I've been soldiering on under fairly high duress here. Thanks for your clarification 🙂 🙂 :).It's very hard to make an in-depth assessment from such a small grab of the logs, but my first reaction was that the warning on jitter rate seems to be quite regular, so, maybe BA1 hits a trigger point where the jitter is considered to be too high, and this forces a restart of the service.
Although I have seen jitter rates up to 100% without audible glitches, I try to get it down to less than 20%. Sometimes the recommended buffer size is not actually the best, and it does require a little experimentation between the ASIO buffer size of the actual sound card, and the internal I/O buffers.
Audio processing typically uses buffers or "blocks" to scoop up data and feed it through the program. This avoids hundreds of hard drive or input stream accesses, or, if the hard drive or stream is busy or compromised by other demands, it avoids drop outs. The same thing happens on the output side, but the down side is the enemy of all audio processing – latency.
This means that it might take several seconds to fill up the buffers, and the same time to empty them, creating a gap between the real time audio and the processed audio. This can be most noticeable when processing music, because the lip sync or things like hitting a drum snare does not line up with the audio. In radio, the announcer's spoken word if fed through a processor, comes back to him delayed by milliseconds, making it very hard to monitor your own voice.Generally, leave the fifo settings at the defaults, but, if you can reduce them and not get dropouts or glitches, this may improve latency. Conversely, if, at the default, there are still glitches, increasing the size may improve, but at the expense of higher latency.
I don't stream, but I believe it is where you define the connection, username, password etc to your external streaming service.
Latency has nothing to do with sample rate. It is the delay between the original signal source (for example – your spoken word) and the final signal ater processing. If there is no processing, the two are the same. If the ASIO buffers are very small, the delay will be minimal, but there may be artefacts, so the trick is to increase the buffer size just enough to get rid of any glitches.
Alternatively, listen to the unprocessed signal straight out of the desk.
Joint stereo saves space by masking off (mono) any signal which is L-R identical, so you only hear the differences as true stereo. In theory, there should be no difference (except space and bandwidth savings), but the purists will insist that both channels should contain all the data, including that which is duplicated in each channel.
Your strategy is sound.
There are several variables here, each of which can be the problem, or may contribute in some way.1) The OS. Although Win10 has been around for a while now, it does not have the same track record as Win7. If it were easily possible, a solution could be to downgrade the Win10 PC to Win7 so the OS platform is the same. Maybe a corollary of this would be to update the Win7 PC to Win10 to see if that introduces issues that are not present or are masked in Win7.
2) The hardware/drivers. Unless the two PCs are identical, there can be a variation of components or drivers influencing the final results. It would be great if both devices were the same – ideally based around the more stable unit.
3) The BA1 Management Package. I'm not convinced that this is a game changer, but Leif is on record as saying that running BA1 as a service uses less resources and therefore may be more stable.
4) There may even be a hardware issue, such as bad RAM in the PC which fails. Simply replacing the RAM with the best you can afford might save a lot of frustrating testing to achieve nothing.
[quote author=AntonisV link=topic=5731.msg19975#msg19975 date=1555336285]
@ Milky From your reply i get the feeling that you are not running BA 24/7, do you? Our TX version is running as a service with rock solid results, but the studio version is not (i think the Management Package is for this purpose after all).Do you run the BA as a service 24/7 with sound input/output and streaming encoders on windows 10?
[/quote]I only use BA1 for home entertainment now, so it gets a serious workout every day for at least eight hours continuously – longer on weekends. However, there is no streaming involved. I have the Management Package, and run BA1 as a service so that I can control it from a tablet or smartphone remotely e.g. when entertaining outside.
In my experience, there can be a delay of up to an hour between nags, so, if the update wasn't that long, you might get lucky. Even if you do get the nag, it is not that bad. It extols the virtues of Breakaway, but sounds a bit like a radio commercial. Most people wouldn't notice to be honest.
If you had both your playout PCs going to a mixer, it would be a simple matter to cross fade between the two so that the backup PC was playing whilst you update Win10. Once it comes back online, you can cross fade back the other way, or wait until the end of a track and start the upgraded PC.
The config files can be backed up (there is an option within BA1) and moved to the other PC as a complete folder. It is also possible to include the config address in the command line (ini_folder=c:/blah) so you can have it stored almost anywhere that is accessible to the PC.
My Dutch (I think) is not very good, but I believe that you have to look for a USB 3.0 device as the bandwidth of USB2 or lower can only support 96kHz.
I run BA1 on Win 10 with no stability problems, but I DO have the Management package, and therefore run BA1 as a service. I'm not sure that running as a service is the entire answer, but it certainly works for me. I have, on occasions, run Breakaway directly (not as a service), but only for relatively short periods. I never had a crash, but the running times were not very significant.
Do you run the TX version as a service?
Having said all of that, I would look at possible driver or code bloat as the culprit. Look at all unnecessary programs and processes and shut them down permanently. Also check for scheduled tasks. A lot of updates are now set up as a scheduled task and, if you delete them, they magically come back. This includes things like Adobe updates. I run a very "skinny" version of Win 10 (64 bit) and it seems very stable.
Have you experimented with buffer sizes etc? ASIO is very sensitive to the buffer geometry, and so you should optimise both your audio card and BA1 for the lowest setting without artefacts.
