- This topic has 10 replies, 3 voices, and was last updated 15 years, 9 months ago by
.
-
Posts
-
Leif,
I discovered Breakaway Broadcast about a week ago and have been having a play and listen to it working. Very nice work!
What is it indicating when all the meters momentarily turn red during program material?
I had glitches and drop-outs when using the Breakaway Pipelines. Not sure what caused them but switching to FlexConnect instead of Pipeline cured all the glitches and droputs.
The machine I am trialing it on is a Dell Inspiron 6400 laptop. The playout software, Breakaway Broadcast and the OptiCodec software run the processor in the mid 30 to mid 40% range. As this doesn’t seem to be stressing the processor I was guessing the dropouts were related to dropped or whatever audio buffers for some reason.
I have VAC on another machine so I tried to use VAC’s Repeater (with Pipelines) to send the output of Breakaway to 2 seperate devices and it was disaster. 🙂 Just a trial to see if it would work.
I read in another thread on this forum you mentioned running Breakaway Live and running the output of that to the studio (announccer’s headphones) due to the low latency and then the output of Live into Broadcast. I think there was a mention there was a "Live" input in Broadcast. I’ve not tried Live but wouldn’t that cause dual processing? Just interested. Maybe I’ve not understood the context of the post in the forum.
Scott
Hi Scott!
Thank you 🙂.
Red meters indicates clipping detected on the input. The clipping could very likely be present in the source material — for example a clipped CD encoded to MP3 will clip again at decode, unless you attenuate inside the MP3 decoder.
It’s really nothing to worry about — the feature is there mostly for when using an external analog input, so that clipping is readily apparent. If you want to "turn off" the indicator, here is one way to do it: [attachment=1:2ckhu0yq]dsp_attenuator_1dB.zip[/attachment:2ckhu0yq]
LiveLink pulls *unprocessed* audio from Live. If it hadn’t, it would indeed be double processing. 🙂
LiveLink is a convenience feature — if you’re running BA Live with an ASIO sound card, there’d be no way to get the unprocessed audio from the same sound card. LiveLink makes that easy. If you’re using a standard sound card (KS / DS / Wave interface) then you can usually open the same card in different programs, and then there’s really no reason to use LiveLink.
Breakaway Pipeline is licensed VAC 4.x. FlexConnect is licensed VAC 2.x — and actually I had a hand in that too, as that was an Octiv product, which I co-founded. 😉
Anyway, VAC 4.x (and thus Pipeline) does have problems on certain systems. I’ve been bugging him for a solution, and have been for quite a while. In fact, he has given me a full version of VAC 3.12, legal to use for all Breakaway customers, until a more permanent solution is found. [attachment=0:2ckhu0yq]vac312full_breakaway.zip[/attachment:2ckhu0yq]
Using Audio Repeater with pipelines could work OK (if the pipelines weren’t causing problems already), but one issue is that the pipelines are not synchronized to the sound cards — there will always be clock drift. Breakaway (all versions!) contain asynchronous adaptive sample rate converters for this very reason — but (as far as i know) no other programs do, including Audio Repeater. So, even if it worked, there’d be periodical glitches.
Best regards,
///LeifHey Leif,
I think i’ve asked this already, but you probably missed it…VAC 4.x vs VAC 3.12, any difference in audio, or is it exactly the same? I’ve read what the differences are between the two, but don’t quite understand it 100%.
Cheers.
Hi lpy! I must have missed it.
When everything is optimal, they’re identical.
However, if you mismatch formats (for example try to play 48000hz into a 44100hz cable), the result will differ:
VAC 4.x is a WDM driver, so Windows will do (horrendously bad) sample rate conversion, but let the audio play.
VAC 3.x, on the other hand, will simply refuse to open.
Which method is better is a matter of opinion 🙂.
///Leif
Leif,
Thanks for the reply and sorry fort the delay in responding. I had login problems so it seemed easier to create another login (sorry). I wrote the password down this time. 🙂
I downloaded that dsp_attenuator_1dB.zip file and that solved the issue of the red meters. I found in the music library I had about 10 WAV files that created the Red meter problem and after some questioning I discovered that they were WAV files that had been created by converting MP3s to WAV. The rest of the files are WAVs ripped direct from CD.
I installed the VAC 3.12 you attached and it solved all the glitches I had. I don’t know why but I also noticed that I am using less CPU % now. Would changing from Pipeline to VAC version 3 affect that?
Also I can use Audio Repeater now and have no problems at all. Thanks for that solution. I appreciate it.
Do you know if it is possible to intercept (if that is the right word) the output of the Orban AAC+ Encoder and listen to it? Normally it would be directed to the Shoutcast Server’s IP but I would like to try something, to send the output of the encoder direct to a player (Winamp) to try to send a low latency aac+ stream between 2 locations. The output of the shoutcast server is about 17 seconds with 48K aac+ Stereo V2 stream. Any ideas?
Thanks again for your help.
Scott
Hi Scotty!
Intercepting would take a lot of programming — at that point it’d be easier to just write a new encoder instead of trying to work around Orban’s.
Shoutcast is slow indeed.
It will never be *low* latency, but you could make it a lot faster by using an Icecast2 server instead of a Shoutcast server. It has much less built in buffering — you should be able to get down to 2-3 seconds of latency this way.
///Leif
Leif,
Thanks for your reply.
I tried IceCast2 Server as you suggested but no matter what I set the buffer at the lowest I could get it was 12 seconds. I was wishfully thinking it was as simple as pointing (say) WinAmp at the same port as the OptiCodec was connecting to the server with (8001). Wishful thinking, as when I tried it Winamp told me it couldn’t sync with to the aac+ stream.
The good people at Tieline Industries loaned me a pair of their Tieline G3 codecs and I was able to accomplish the task using IP between the 2 sites on the 3G Cell/Mobile network with only about 20-50ms latency so a 2 way conversation could be held as I wanted to do as well as the remote feed of the music from the playout system.
I was going to try AudioTX Communicator but it turned out to be more trouble than it was worth.
To add Breakaway into the setup I took Audio out of the studio end Tieline and ran it into the AudioScience audio card on the control room PC which we had put Breakaway onto and then took the output of that card and that became the final program out for the demo I was doing. Sounded great!
What do you recommend the Buffer Size be set at for most modern PCs?
More questions as they come to hand, as I learn so much reading your responses to others in the forums.
Scott
Hi Scott!
Whoa, 20-50ms??? That’s tiny! Nice, but how is it even possible?
For one, they’re not actually using aacPlus.
I just checked the aacPlus codec delay (by initializing an encoder library and asking it).. it replied 4280 samples.
That assumes that our audio is already in 2048-sample blocks, which is the aac frame size. If it’s not, we have to buffer to build up a whole frame of data to process, so that’s 2048 + 4280 = 6328 samples! That’s 130ms of *algorithmic* delay, at 48000hz sampling rate. It assumes that we’re encoding and decoding on an infinitely fast computer. If we have to go through sound cards, out on a network (even a local one), buffer to compensate for block timing jitter (which you have to do in windows) etc, delay just keeps going up and up.
20ms of latency is *extremely* impressive for taking digital audio from one place to another through a low bitrate codec. I looked up the specs — 43.2kbps in one direction and 28.8 in the other? I wonder what that sounds like for music, since the codec can’t be quite as efficient as aacPlus if the delay is this low.
Also, remember those codecs do not use the public internet — they use a cell network. Over the public internet, I believe it’s (currently) impossible to have reliable, stable hifi audio with less than a few hundred milliseconds of delay.. The internet just isn’t that reliable — it has no delivery guarantees.
I wish there was an easier way 🙂.
Regarding Buffer Size, I would just keep it at medium unless there are any glitches. There shouldn’t be any — BBP (in an over-the-air broadcast environment) is really meant to be run on a dedicated system. Computers are already so inexpensive compared to traditional audio processing hardware — why compromise performance by unnecessarily assigning more tasks to the same hardware?
In a web streaming environment, I would just use Huge, since delay is already several seconds.
Best,
///LeifHi Leif,
I’ll speak to the techs involved tomorrow and clarify the latency figure, as what they told me during the test seems to be incorrect based on your data. Either that or I have confused what I was told. I’ll come back to you on that.
The Tieline doesn’t use acc, I think it is their own proprietary MusicPlus codec. Again, I’ll try and clarify that tomorrow.
AudioTX and some others are claiming 5 ms latency on their IP-STL units. 🙂
The only reason I was running the BBP on one of the Control Room PCs is because it was in the right place at the right time. It is a backup NexGen Digital system and I just hijacked the machine to use the audio card for my test. If (when) we go with BBP then it will have a PC of its own.
In this shot is the Brown (Red) line indicating that band (7) is gating?
Scott
- The forum ‘Breakaway Professional Products – [discontinued]’ is closed to new topics and replies.