Forum Replies Created
-
Posts
-
Hi guys!
It’s an interesting feature indeed, and it will be a great feature to use for differentiating the future more advanced versions, rather than putting every bell & whistle in the cheap version 🙂.
///Leif
Hi Gerrit! I’m afraid not. There is no scheduling, API or Automation in Breakaway Broadcast.
///Leif
Howdy!
It couldn’t completely replace a 4800 — for example Breakaway Live won’t have feedback removal. However, in most situations where you’d use a 4800, you could probably use Breakaway Live instead.
CPU usage? Somewhat surprisingly, not much worse than the current version at all! A single core celeron will be able to run it very comfortably.
///Leif
Breakaway Live will also come with RTA software. The only thing missing is the sound card (duh) and a calibrated microphone, such as the $50 Behringer ECM8000.
SAME PRICE. The $129 stereo version will include separate equalization for up to eight speakers! There will be a mode switch in the I/O config, where you choose whether the first core should be in Broadcast or Audiophile mode.
In Audiophile mode, you get:
12-band (!) parametric eq per-speaker
Low and High-pass per speaker (to function as crossover)
Adjustable bass-clipping per speaker (to make the most of an inexpensive system when pushing for loudness)
Selectable Mono-sum per speaker (to drive a subwoofer amplifier)
Convenient Volume Control Popup (same as Breakaway Personal)
Volume Control API, to be able to hook it up to hardware. Personally I will use two buttons in a box, hooked up to the parallel port, to adjust volume up and down.
My "Loudness" controller. This one warrants some explanation —I’m sure you’re familiar with the Loudness button on stereo equipment. Basically, it boosts the bass and treble, usually too much. The logic behind this control is to boost bass and treble at low listening levels to compensate for the ear and the environment, and yield full pleasing sound at any volume, but the loudness control just never feels "right". It’s fixed, preset at the factory, and won’t match your environment. So, instead I implemented loudness as four parametric EQs, where you define a range on the volume control for it to take effect!
For example. Let’s say you want to boost bass at lower listening levels. You might set Frequency to 30, Width to 3.0, Gain to 12.0. Then, set "Begin" to -10, and "Full" to -22. As you turn the volume down past -10, it will start boosting the bass. As you reach -22, you have the full -12.0 bass boost.
This way, you can exactly tailor it to your environment, with great accuracy.
Other uses: Mellow out high frequencies at the very highest volume settings, to protect people from tinnitus while still yielding the "LOUD!!" experience. For clubs etc.
Now, let me explain what this upgrade is NOT:
It is NOT a broadcast eq! This EQ sits AFTER the Breakaway processing core, not before. In fact, it sits after the Breakaway core final limiter. By EQing, you ruin peak control and lose loudness. (When playing into a speaker, you do not care about peak control, but when broadcasting, you do.) 🙂
Since I foresee people violently demanding it, I will be adding broadcast eq to BBP and Live. Probably 3-band parametric (you don’t want any more than that for broadcast! trust me!) 😉. It won’t be in the next release, but it’ll be in the one after.
Best,
///Leifquote :I understand that Windows solved this problem in DS and Wave by resampling everything to the same rate and clock, but we’re now using WDM-KS which is supposed to bypass Kmixer. So why can we make such a connection every day and not experience clicks and pops?Windows uses synchronous sample rate conversion only, not asynchronous, so it could not solve this particular problem — but this problem does not occur in most circumstances.
quote :Furthermore, in a “typical” Breakaway Live configuration,
soundcard1(in)->application->pipeline->SRC->soundcard2(out),
if the application and the pipeline each has a different clock (than each other and than the two soundcards), then what good does the SRC do if it can only correct for the clock difference between the pipeline and soundcard2, but not for the difference between the pipeline and the application, the pipeline and soundcard1, or the application and soundcard1? There must be some sample rate sync mechanism that isn’t explained.The application does not have its own clock. The input thread of the application locks onto the input sound device, and the output thread locks onto the output sound device. So, it records and plays back in a robust manner — each side is synchronized to its respective hardware. The only thing missing is a link between them, so they can talk to each other! In most applications, this would be a fifo buffer. It works, and the longer the buffer, the rarer (but bigger) the glitches.
In my products, I use a Fifo coupled with an asynchronous SRC, which dynamically adjusts and keeps the fifo in the middle, so that drift-related glitches cannot happen.
quote :player->pipeline->ASIO4ALL->soundcard,ASIO makes no allowance for disparate input/output clocks. Audio is input and output on the same callback, in the same buffer set. Thus, it is the asio driver’s job to make sure it can follow this spec, and ASIO4ALL isn’t doing it. To really be robust, it would need to have an asynchronous sample rate converter built in, to convert incoming audio to the output device, and then call the ASIO client synced to the timing of the output device.
///Leif
quote :EDIT: On second thought, Pipeline1, Pipeline2, and Pipeline3 all have the same clock, don’t they? So the SRC between Pipeline 1 and Pipeline2 really won’t do anything.Indeed. Now you’re getting it 🙂
Live does not support 8-channel pipelines — it is a stereo processor.
However, I’m actually adding speaker controller features to live right now, and the next version WILL support outputting to an 8-channel pipeline. However, it will only support 2-channel input, so I don’t believe it will solve the problem..
I don’t have a good answer, sorry. Stable audio processing in Win32 is NOT easy — that’s why so few get it right.
///Leif
quote :Are you saying that each device locks to the clock of its source?I’m afraid not. Breakaway Pipeline (Virtual Audio Cable) has its OWN master clock, different from the sound card clock. It cannot lock onto any other clock. That’s what causes the need for SRC in Breakaway.
So, the application that takes audio from the internet and feeds it into a pipeline, needs an SRC.
The application that takes audio from a pipeline, and feeds it to a sound card, ALSO needs an SRC.Even if there are no internet dropouts, there will still be dropouts just from the fact that you’re using two separate clock sources. For example, if the internet stream is created at 44097 Hz, but your sound card runs at 44102 Hz, you’ll be losing 5 samples per second. Assuming 10 milliseconds of buffering, you’ll have a dropout every couple of minutes.
///Leif
Hey there!
Sure! http://bredband.leif.cx/browse/commercial
Also included: New BBP ASIO commercial 😉.
///Leif
Status update: Waiting on new code signing certificate from Verisign, among other things. While waiting, I’ve started working on the next version of Breakaway Live. Maybe we’ll just do a tripple-whammy release this time 🙂. (BBP + BBP ASIO + Live)
I’m afraid Breakaway Live (or any of the Breakaway products) cannot solve the problem, as it’s out of reach.
The SRC in Breakaway Live corrects for the drift between Breakaway’s Input and Output devices only.
If the streaming audio player is connected to your application by using a virtual cable, no drift occurs between the streaming audio player and your application. The drift occurs INSIDE your application (since your app outputs to the sound card, which has a different clock), so that’s where the SRC would have be.
So, that’s one problem. The other problem is the drift between the clock source of the internet stream, and your output sound card (or your virtual cable). That’s one more source of definite drift, and it’s not easy to account for. The question there is, how do you write an algorithm to tell the difference between internet-lag and clock drift?
///Leif
Hey Cybo,
Indeed, if you don’t need low latency, don’t get BBP ASIO!
Also, it’s not really an upgrade — it’s a different product. To be an upgrade, BBP ASIO would have to support all features that BBP does.. It doesn’t! BBP ASIO cannot use standard sound devices other than for the RDS/SYNC input — it only supports ASIO drivers.
BBP ASIO *does* however have the full-latency maximum quality back-end from standard BBP as well, so that you can get that on the air while enjoying ultra low latency monitoring, with a single sound card, and single program. To accomplish this, it actually runs TWO completely separate breakaway cores internally.. One in phase linear mode (100ms latency just for the crossovers) for air, and one in low latency mode for the studio output!
BBP -> BBP ASIO was NOT an easy code change to make, I guarantee it. Those 4 letters took an incredible amount of time. 🙂
Best,
///LeifI’ve never used RSS feeds other than when downloading podcasts with Juice, so I’m a complete newbie on this particular subject 🙂. Could someone tell me more?
///Leif
