Home › Forums › Breakaway Professional Products – [discontinued] › Pipelines
- This topic has 15 replies, 4 voices, and was last updated 15 years, 7 months ago by Anonymous.
-
AuthorPosts
-
April 23, 2009 at 4:15 am #320AnonymousGuest
Leif,
I haven’t been doing much about BBP or Live lately as I’ve been experiencing those dropped buffers and was waiting for the release of the upgraded Pipeline to replace the current use of Pipelines and (in my case) VAC.
I found I was listening more for dropped buffers than the quality of the audio. π
Today while having general conversation with one of our "consultants", out of interest I showed him Breakaway on my laptop and mentioned the problems I was having with the VACs dropping buffers. He asked if he could have a look at how I had it setup. Then told me I had it setup incorrectly. That’s what consultants are paid to tell you, right? π Though he is not an IT consultant just an audio enthusiast.
I was using VAC as I had problems with glitching/stuttering with Pipelines. As all our audio is 44.1/16 PCM WAV files, I had the I/O setup as 44.1, using Virtual Audio Cable 1 for each play deck output of the playout software using Wave as the setting in Breakaway. He changed it to the following:
Each deck out on the playout as Breakaway Pipeline 1. I knew this would glitch and stutter but didn’t say anything. π
Breakway I/O Setup:
Input:
Interface: KS
Audio Device: Breakaway Pipeline 1
Buffer Size: 480
Buffer Count: 8
Sampe Rate 48000
SRC: CheckedOutput:
Interface: KS
Audio Device: Sigmatel Audio (my laptop)
Buffer Size: 480
Buffer Count: 8
Sampe Rate 48000Works great, and feeding the output of my laptop into the monitor router switcher it sounds excellent!
Is Breakaway doing the Sample Rate Conversion of the input 44.1/16 to 48/16?
I really have no idea what KS, DS and WAV and Pipleines etc do and I can’t find anything that tells me. Can you point me to anything that explains it as I certainly don’t want you to have to spend time explaining it all to me, but I think I am now hearing Breakaway sounding better than I’ve heard it since I downloaded it and installed it.
I think I now hear Spartacus working too.
Scott
April 23, 2009 at 6:57 am #7163LeifKeymasterHi Scotty!
Set up that way, Windows will be doing the sample rate conversion from 44.1 to 48 kHz. It will *not* do a good job. Create a 44100hz file with a linear sweep from 20 to 20000hz (5 seconds long is enough), play it through your player and listen. You should hear all sorts of "birdies" as the sweep goes up in frequency. Then, create the same sweep in a 48000hz file and play that — it should sound completely clean.
(BBP does not add audible aliasing while clipping.)
A pipeline is a virtual audio device with two ends. It looks like a sound card in both ends, but they’re connected, so as you play into "Pipeline 1 Out", it will appear on "Pipeline 1 In".
DS = DirectSound, Wave = MME. They’re both older, standardized ways to access audio cards, and they are in fact translated to KS (Kernel Streaming) by Windows. KS is the native language of almost all sound card drivers (including VAC / Pipeline), thus applications that support KS correctly can bypass several layers of windows.
Running the pipeline at 48000hz should not yield fewer glitches than running it at 44100, but who knows? Interesting find!
Best,
///LeifApril 23, 2009 at 9:10 am #7164AnonymousGuestLeif,
Thanks for the information.
I tried to set it back to 44.1 with KS but when I go to Test I get:
Failed to create output pin
Sound device busy?
Check Rate and ChannelsSo I have gone back to Wave 44.1 and VAC as before.
Why does Pipelines not work in some instances when VAC does?
Scott
April 23, 2009 at 10:30 am #7165AnonymousGuestLeif,
This "may" explain why it sounded better to me at 48,000 than 44,100:
I setup Tino Esser’s Tone Generator to 44,100 and created a 12KHz sine wave tone at -10db. Took a screenshot from the card output on the analyzer, and then reset the Tone Generator to 48,000 and used the same tone to take another screenshot.
See the results below
12,000Hz at 44,100:
12,000Hz at 48,000:
Maybe laptops are not meant to be used for audio. π
Does this mean the onboard audio card is really running at 48,000?
Scott
April 23, 2009 at 11:54 am #7166LeifKeymasterHi Scotty!
Nice instrument!
YES – this absolutely means the laptop’s onboard audio is really running at 48,000. Most consumer-grade audio chipsets do.
This is why the default Input Rate in Breakaway products is 44100, and the default Output Rate in Breakaway products is 48000. My SRC does NOT do what you see in that analysis screenshot π.
Best,
///LeifApril 24, 2009 at 9:20 am #7167AnonymousGuestLeif,
Thanks for the confirmation that the card is running 48K.
You should have seen the sweep from 20 to 20000hz on the analyzer at 44,100. It was a real strange display .. but some nice patterns. π At 48,000 the analyzer display looked exactly like you’d expect.
I have set Breakaway to:
Input:
Interface: KS
Audio Device: Breakaway Pipeline 1
Buffer Size: 441
Buffer Count: 8
Sample Rate: 44100
SRC: NOT CheckedOutput:
Interface: KS
Audio Device: Sigmatel Audio (my laptop)
Buffer Size: 480
Buffer Count: 8
Sample Rate: 48000So I am guessing that Breakaway is doing the SRC from 44.1/16 to 48/16?
No dropped buffers yet but I’m still testing and listening for one. π Maybe now I’m using KS and not Wave it might help the situation.
Thanks again for your assistance.
Do you see Breakaway (Broadcast and Live) coming out of Beta soon?
Scott
April 24, 2009 at 10:08 am #7168LeifKeymasterHi Scotty!
Indeed, Breakaway is doing the conversion from 44.1 to 48.0. You can test the performance of the SRC by hitting Bypass and then running a sweep through. Should look very nice and clean.
Coming out of Beta will be a while! The reason is that I’m still adding features. I thought they were stable, and then I realized all these other things I had to add.
For example, ITU BS.1770 loudness meters on the input:
Also, while still in Beta, I can still replace presets without people complaining too much. After official release, that gets much trickier, and rightfully so.
Best,
///LeifApril 25, 2009 at 12:49 pm #7169AnonymousGuestHi Leif,
[quote author=”Leif”]You can test the performance of the SRC by hitting Bypass and then running a sweep through. Should look very nice and clean.[/quote]Indeed it did look nice and clean. π Nice work.
I thought I had a problem with it as I input the sweep at -10 and was getting a reading of -16 on the output (in bypass) on the analyzer. The input must also go through the DSPs and I had not unchecked the -6db attenuator. I had unchecked the Adapt-X for Spartacus and also the Impact/Clunk for some tests I was capturing through it earlier.
I think I took Bass-EFX out at a suggestion Jesse made in an earlier topic.
[quote author=”Leif”]For example, ITU BS.1770 loudness meters on the input:
Also, while still in Beta, I can still replace presets without people complaining too much. After official release, that gets much trickier, and rightfully so.[/quote]Thanks, I totally understand why it is in Beta for so long. It just keeps improving as it goes along.
The loudness meters look great but why would they be on the input and not the output where it is monitoring loudness?
Thanks again,
ScottApril 27, 2009 at 10:03 am #7170LeifKeymasterHowdy!
The one reason for keeping it at the input instead of the output of a radio processor, is that the input loudness meter will greatly help set the input level, whereas for the output, there’s not much to show. Levels are very uniform after Breakaway (especially with radio-level processing), so there’s never a reason to use a loudness meter to set the output level.
For a TV processor, on the other hand, you’d need loudness meters on both input and output, since you’re not processing nearly as hard, and there are actual loudness standards to follow.
Best,
///LeifApril 27, 2009 at 3:32 pm #7171AnonymousGuest[quote author=”Leif”]Howdy!
The one reason for keeping it at the input instead of the output of a radio processor, is that the input loudness meter will greatly help set the input level, whereas for the output, there’s not much to show. Levels are very uniform after Breakaway (especially with radio-level processing),
Best,
///Leif[/quote]Unless of course you are experimenting with presets and drive settings, etc. Why not give the user the option of displaying the ITU BS.1770 on the outputs and let him or her decide its utility?
Stuart
April 28, 2009 at 1:55 am #7172LeifKeymasterCode and gui complexity, Stuart. The key to a user friendly product (and maintainable code) is to keep it simple.
It’s simply not useful enough at the output to warrant the complication.
I am however adding an ITU loudness meter to MpxTool! There, it makes sense, because you can then numerically compare your loudness to other stations.
///Leif
April 29, 2009 at 5:22 am #7173AnonymousGuestLeif,
[quote author=”Leif”]The one reason for keeping it at the input instead of the output of a radio processor, is that the input loudness meter will greatly help set the input level, whereas for the output, there’s not much to show. Levels are very uniform after Breakaway (especially with radio-level processing), so there’s never a reason to use a loudness meter to set the output level.[/quote]I thought a Loudness Meter monitors the output as that is where the result of all the processing (loudness) is. So, I learnt something new today. I have a lot to learn. π
I was reading through one of our Orban Manuals and all it seems to say about setting up the input (basically) is to set it so the AGC is riding at about 10db GR with normal program material. So, is changing the input for less GR at the AGC a control of loudness? If that is the case wouldn’t you notice that on the GR Meter and not necessarily need a loudness meter?
Scott
April 30, 2009 at 8:56 am #7174JesseGMemberThat is one way to look at it… but a more elegant solution might be to have accurate (LKFS / ITU BS.1770-1) loudness meters on the input, and have a dialnorm setting for a target input loudness than when changed also compensates the AGC range, the gates hold/freeze levels, and the multiband-expander thresholds. That way you can decide what dialnorm is best for the input, and compensate the whole processor to match it with one "knob".
Guess what one of the new features coming down the line is? π
April 30, 2009 at 11:36 pm #7175celarMemberNow THAT’S what’s really needed here!
That feature will be hugely important for "Jack" stations, where the average loudness of the input songs is all over the place.
This is the first time I’ve even heard another human being besides myself mention this idea. Thanks 4 the validation.
April 30, 2009 at 11:44 pm #7176celarMemberHey another question, Jesse:
So you wouldn’t auto-vary the compression ratio, then? Just the thresholds?
Whenever Iβve thought about this idea myself, I always pictured it as: βIf input song is more compressed", then βwe use a lower compression ratio in response to thatβ.
-
AuthorPosts
- The forum ‘Breakaway Professional Products – [discontinued]’ is closed to new topics and replies.