- This topic has 14 replies, 2 voices, and was last updated 15 years, 5 months ago by
.
-
Posts
-
Hello.
I just downloaded Breakaway Live trial version, and I am a bit confused as to how to set it up. I have a bit of an unusual configuration, and I really only need the Breakaway Live SRC and routing capabilities. In fact I originally tried to use Virtual Audio Cable in this application (so the Breakaway Pipeline Control Panel looked very familiar), but its lack of SRC caused clock sync problems.
Here is the setup: Streaming audio comes in from the Internet (or it may be stored on disk, but it uses the same player). I need to route the streaming audio player’s outputs to an application that I have written myself, that runs under ASIO4ALL. The outputs of my ASIO4ALL application get sent to the physical sound card. The problem is that the streaming player seems to use one clock source, ASIO4ALL seems to use another, and the physical sound card seems to use yet another, even if all sampling rates are set to the same value. I say this because no matter how large I make the buffers, ASIO4ALL always eventually loses sync and the audio becomes corrupted.
So in Breakaway Live I have the choice of setting up the pipelines myself, or of enabling ASIO. Within my own program I can choose whatever inputs and outputs I want, as long as they are visible to ASIO4ALL as WDM-KS pins, so I should be able to make either choice work. But which would be better in my case?
If I do NOT enable ASIO, then I am confused as to how to set up the inputs and outputs. For now I have:
Input 1……Breakaway Pipeline 1……SRC checked
Output 1……Disabled
Input 2……Breakaway Pipeline 2……SRC checked
Output 2……the physical sound card
But I am not certain, with this setup, that the SRC is being applied between the output of the streaming audio player and the input of my ASIO4ALL application.If I DO enable ASIO, then the choices for the inputs and outputs are clear. I have:
Input L1……Breakaway Pipeline 1 1
Input L2……Breakaway Pipeline 1 2
…
Output L1….Breakaway Pipeline 2 1
Output L2….Breakaway Pipeline 2 2
…
But then again, I do not know whether SRC is being applied between the various clock domains.Please give me some guidance in this. Thank you.
Greg
Followup:
Is there any way to configure a Breakaway Pipeline for more than 2 channels? My ASIO4ALL application inputs 2 channels but outputs 8 channels. I have tried setting up the Pipeline in the Breakaway Pipeline Control Panel for 8 channels, and similarly in the Windows Vista Control Panel "Sounds" configuration, but Breakaway Live only outputs 2 channels.
Thanks.
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
[quote author=”Leif”]I’m afraid Breakaway Live (or any of the Breakaway products) cannot solve the problem, as it’s out of reach.[/quote]
Hmmm … that’s not good news, but I am not quite ready to give up. If I can find a 95% solution, that will be good enough.[quote author=”Leif”]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.[/quote]
Are you saying that each device locks to the clock of its source? If that is true then I at least have a starting point.I worked with Live all day yesterday, and I think I understand the routing a little better. If I could set up an 8-channel pipeline, then I could put that between the output of my application and the input to the sound card. But I could not figure out a way to create an 8-channel pipeline. Maybe four 2-channel pipelines, instead?
[quote author=”Leif”]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?[/quote]
That problem I’m not so worried about, at least not in this particular application. If there are Internet dropouts, then that’s just the roll of the dice. But I would like to have a solid playback path for when there are NOT Internet dropouts.Thanks for your help,
GregPS I noticed a weird problem right at the end of the day yesterday — any stereo audio passed through Breakaway Live comes out mono! (Keep in mind that all Live processing is bypassed.) I’m assuming that it’s something that I’ve configured incorrectly, but can you give me a hint as to what might cause this so that I can fix it? Thanks again.
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
[quote author=”Leif”]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.[/quote]
EXACTLY what I thought (and feared)! However, still not out of reach:
Internet->Pipeline1->SRC->Pipeline2->Application->Pipeline3->SRC->SoundCard
However, this requires that Pipeline3 have 8 channels. Does Live support 8 channel pipelines? If so, then how do I configure one? I have set up 8-channel pipelines in the Breakaway Control Panel and the Windows Control Panel, but Live always uses only 2 of the 8 channels.Thanks again,
GregEDIT: 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.
I only need to be able to run for about an hour, glitch-free. Maybe I’ll just set up a huge buffer in a single pipeline and try that.
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 author=”Leif”]Indeed. Now you’re getting it :)[/quote]
Oh, I don’t know about that … I don’t mean to belabor the point, but, seriously, I’m an engineer and consider myself a logical thinker, and this still makes no sense to me.In my configuration,
player->pipeline->ASIO4ALL->soundcard,
let’s ignore the sample clock on the Internet stream and pretend that the player is reading data off the hard drive. If the player has one clock, the pipeline has another, ASIO4ALL another, and the soundcard yet another, then there should be clock sync problems galore. In fact, eliminate the pipeline and ASIO4ALL and just connect the player directly to the soundcard, and there should STILL be clock sync problems. 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?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.quote :Live does not support 8-channel pipelines — it is a stereo processor.Maybe a future product idea for you, then.
quote :I don’t have a good answer, sorry. Stable audio processing in Win32 is NOT easy — that’s why so few get it right.Ultimately I plan to rewrite my application under WASAPI, but for now I just need proof-of-concept to be working under WDM-KS. It’s proving to be much more difficult than I ever imagined.
Thanks again,
Gregquote :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 author=”Leif”]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.[/quote]
Aha! Now it makes sense.[quote author=”Leif”]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]
You could probably make a minor product just out of a multichannel Breakaway Pipeline with SRC. I could certainly use an 8-channel version at the moment.Many thanks for your patience and comments.
Gregquote :You could probably make a minor product just out of a multichannel Breakaway Pipeline with SRC. I could certainly use an 8-channel version at the moment.That would be a nice thing to have! But, I’m not sure it’s possible either.
I didn’t write the Breakaway Pipeline. It’s the only part of the Breakaway products I didn’t write myself — I licensed Virtual Audio Cable 4.x. Even if I had written it though, I have reasons to believe it won’t work 🙂.
Previous versions of Virtual Audio Cable (3.x) had a synchronous mode, where the cable had no clock, but instead followed the clock of the application feeding data to it. This came with some issues, but it did solve the synchronization problem. It was possible because VAC 3.x was a native Wave driver.
I once asked Eugene why there wasn’t a synchronous mode in VAC 4.x. If I remember correctly, he answered that due to the way WDM driver architecture is, if the driver stands still for even a couple of milliseconds (while waiting for whatever it’s synchronizing to), the audio driver will be forcibly reset by Windows. WDM drivers has to function within all sorts of different frameworks (like the DirectSound emulation) so I can see how issues like this would come up.
The cleanest way would be for you to write that WASAPI support, I think. By the way, when you get that working, let me know if you’re interested in selling the WASAPI interface code 😉. I could use it, and can’t write it as long as my primary system runs XP.
///Leif
[quote author=”Leif”]
quote :You could probably make a minor product just out of a multichannel Breakaway Pipeline with SRC. I could certainly use an 8-channel version at the moment.That would be a nice thing to have! But, I’m not sure it’s possible either.[/quote]
Because of the number of channels? VAC 4.x shows up in ASIO4ALL as 64 channels in/out, and I have definitely used it successfully as an 8-channel device. I have also used Audio Repeater KS as an 8-channel device. Perhaps Audio Repeater KS could serve as the basis for your SRC product.quote :I once asked Eugene why there wasn’t a synchronous mode in VAC 4.x. If I remember correctly, he answered that due to the way WDM driver architecture is, if the driver stands still for even a couple of milliseconds (while waiting for whatever it’s synchronizing to), the audio driver will be forcibly reset by Windows. WDM drivers has to function within all sorts of different frameworks (like the DirectSound emulation) so I can see how issues like this would come up.The entire Windows audio environment makes it obvious that Windows PCs were never intended to be audio devices! Trying to get bit-perfect audio from input to output is all but impossible.
quote :The cleanest way would be for you to write that WASAPI support, I think. By the way, when you get that working, let me know if you’re interested in selling the WASAPI interface code ;). I could use it, and can’t write it as long as my primary system runs XP.I’m told that even WASAPI still has sync problems. Apparently Mac Core Audio is a step above, while ASIO still leads the pack.
Before I can write under WASAPI, I need to understand the environment MUCH better. That’s the reason I’m trying to prototype with off-the-shelf SW.
Best,
Gregquote :Because of the number of channels? VAC 4.x shows up in ASIO4ALL as 64 channels in/out, and I have definitely used it successfully as an 8-channel device. I have also used Audio Repeater KS as an 8-channel device. Perhaps Audio Repeater KS could serve as the basis for your SRC product.No, the problem is adding SRC inside a pipeline, not the number of channels, for the reasons I already mentioned 🙂.
quote :The entire Windows audio environment makes it obvious that Windows PCs were never intended to be audio devices! Trying to get bit-perfect audio from input to output is all but impossible.True that. However, with proper hardware, it’s really not that bad. Your issue stems from using ASIO4ALL. If you used a REAL asio device, you would not be having this problem — it would be properly synchronized just like it should, and you’d be able to get bit-accurate input to output.
Sync problems in WASAPI still? That sucks. Hopefully they’ll fix it before Windows 7 release.
///Leif
[quote author=”Leif”]No, the problem is adding SRC inside a pipeline, not the number of channels, for the reasons I already mentioned :). [/quote]
I’m confused. If you can do it with 2 channels, why not 64?quote :Sync problems in WASAPI still? That sucks. Hopefully they’ll fix it before Windows 7 release.That’s third-hand information, so I cannot vouch for it.
Greg
quote :I’m confused. If you can do it with 2 channels, why not 64?I’m not doing it inside the pipeline (a driver presenting two wave devices synchronized to its internal clock). I’m doing it in my program (a user-level application using two separate wave devices with different clocks). The number of channels, as I said, doesn’t matter. Indeed, if you can do it with 2, you can do it with 64.
///Leif
- The forum ‘Breakaway Professional Products – [discontinued]’ is closed to new topics and replies.