[LAU] Audio seamless switch

[Benny Alexandar]

Hi,

I'm looking for a tool to mix two audio. My requirement is
given two identical audio inputs say A1 & A2.
A1 is ahead of A2 by t sec, when switch from A1 to A2
it should be seamless and vice versa.

Please help if you know of any open source tool.

-ben

[Ralf Mardorf]

On Sat, 16 Jun 2018 17:47:21 +0000, Benny Alexandar wrote:
>I'm looking for a tool to mix two audio. My requirement is
>given two identical audio inputs say A1 & A2.
>A1 is ahead of A2 by t sec, when switch from A1 to A2
>it should be seamless and vice versa.

Hi Ben,

this is a vague description of the task. What is the reason that signal
1 is ahead of signal 2? What apps do you want to use, resp. do those
apps support plain alsa or jack or pulseaudio?

Perhaps a simple delay is what you are looking for, but maybe you need
resampling.

Regards,
Ralf

[Benny Alexandar]

>> What is the reason that signal
1 is ahead of signal 2?

For various reason, one audio receiving from network and
other thru air.

>> Perhaps a simple delay is what you are looking for, but maybe you need
resampling.

Yes delay estimation is required as the delay is not known upfront.
In addition to re-sampling stretching also required.


________________________________
From: Linux-audio-user <linux-audio-user-***@lists.linuxaudio.org> on behalf of Ralf Mardorf <***@alice-dsl.net>
Sent: Saturday, June 16, 2018 11:36 PM
To: linux-audio-***@lists.linuxaudio.org
Subject: Re: [LAU] Audio seamless switch

On Sat, 16 Jun 2018 17:47:21 +0000, Benny Alexandar wrote:
>I'm looking for a tool to mix two audio. My requirement is
>given two identical audio inputs say A1 & A2.
>A1 is ahead of A2 by t sec, when switch from A1 to A2
>it should be seamless and vice versa.

Hi Ben,

this is a vague description of the task. What is the reason that signal
1 is ahead of signal 2? What apps do you want to use, resp. do those
apps support plain alsa or jack or pulseaudio?

Perhaps a simple delay is what you are looking for, but maybe you need
resampling.

Regards,
Ralf

[Paul Davis]

On Sat, Jun 16, 2018 at 2:13 PM, Benny Alexandar <***@outlook.com>
wrote:

> >> What is the reason that signal
> 1 is ahead of signal 2?
>
> For various reason, one audio receiving from network and
> other thru air.
>
> >> Perhaps a simple delay is what you are looking for, but maybe you need
> resampling.
>
> Yes delay estimation is required as the delay is not known upfront.
> In addition to re-sampling stretching also required.
>

​that turns it into a totally different problem. You originally said: ​

two identical audio inputs say A1 & A2.

why would you need to resample/stretch them?

​

[Benny Alexandar]

>>>why would you need to resample/stretch them?
​
As mentioned earlier the two audio are identical but one will be ahead/delayed than other.
The user who is listening to it should not notice the switching, and this
switching happens when the quality of one audio is degraded compared to other.

-ben

________________________________
From: Paul Davis <***@linuxaudiosystems.com>
Sent: Sunday, June 17, 2018 12:01 AM
To: Benny Alexandar
Cc: Ralf Mardorf; linux-audio-***@lists.linuxaudio.org
Subject: Re: [LAU] Audio seamless switch



On Sat, Jun 16, 2018 at 2:13 PM, Benny Alexandar <***@outlook.com<mailto:***@outlook.com>> wrote:
>> What is the reason that signal
1 is ahead of signal 2?

For various reason, one audio receiving from network and
other thru air.

>> Perhaps a simple delay is what you are looking for, but maybe you need
resampling.

Yes delay estimation is required as the delay is not known upfront.
In addition to re-sampling stretching also required.

​that turns it into a totally different problem. You originally said: ​

two identical audio inputs say A1 & A2.

why would you need to resample/stretch them?

​

[Ralf Mardorf]

On Sun, 2018-06-17 at 08:16 +0000, Benny Alexandar wrote:
> >>>why would you need to resample/stretch them?
> As mentioned earlier the two audio are identical but one will be ahead/delayed than other.
> The user who is listening to it should not notice the switching, and this
> switching happens when the quality of one audio is degraded compared to other.

Hi Ben,

"ahead/delayed" could be caused by different sync issues. And
"identically" as well as "degraded" could be interpreted in different
ways.

You mentioned "one audio receiving from network and other thru air".

For example a single CD player's audio signal is send wireless to an
audio interface and by a network cable the same audio output of this CD
player is send to a network interface, you are not using two CD players
playing the same CD.

I don't have knowledge about wireless audio and audio by network, but I
suspect that it's similar to using two sound cards. To avoid "degraded"
sound quality two sound cards needs to be synced by a single clock
source e.g. word clock or you need to workaround this sync issue by
using software such as zita-ajbridge. That's one kind of sync issue.

Another kind of sync issue could be caused by e.g. distance. For
example, one audio cable is 10 meters short, the other is as long as
from Earth to Mars and back. To workaround this time difference you
could use a delay effect, to delay the signal provided by the short
cable.

Assuming two CD player's should play the same CD, or better let's assume
two different professional audio recorders are individually playing the
same recording, instead of just using the signal of a single
professional audio recorder, you need to sync the two machines by a
timecode, such as SMPTE, to avoid drift.

You should be more detailed about the issue. What is the source of the
audio signal/s? What is "wireless" for? In what way is the audio quality
"degraded"? Is always the same sample rate etc. used? What software are
you using for mixing/switching the signals?

Regards,
Ralf

[Paul Davis]

​So you want to stretch/shrink the newly-switched-to audio so that it
"catches​ up" with the just-switched-from audio and then runs at normal
speed?

This strikes me as madness, but hey, good luck!


On Sun, Jun 17, 2018 at 4:16 AM, Benny Alexandar <***@outlook.com>
wrote:

> >>>why would you need to resample/stretch them?
> ​
> As mentioned earlier the two audio are identical but one will be
> ahead/delayed than other.
> The user who is listening to it should not notice the switching, and this
> switching happens when the quality of one audio is degraded compared to
> other.
>
> -ben
>
> ------------------------------
> *From:* Paul Davis <***@linuxaudiosystems.com>
> *Sent:* Sunday, June 17, 2018 12:01 AM
> *To:* Benny Alexandar
> *Cc:* Ralf Mardorf; linux-audio-***@lists.linuxaudio.org
> *Subject:* Re: [LAU] Audio seamless switch
>
>
>
> On Sat, Jun 16, 2018 at 2:13 PM, Benny Alexandar <***@outlook.com>
> wrote:
>
> >> What is the reason that signal
> 1 is ahead of signal 2?
>
> For various reason, one audio receiving from network and
> other thru air.
>
> >> Perhaps a simple delay is what you are looking for, but maybe you need
> resampling.
>
> Yes delay estimation is required as the delay is not known upfront.
> In addition to re-sampling stretching also required.
>
>
> ​that turns it into a totally different problem. You originally said: ​
>
> two identical audio inputs say A1 & A2.
>
> why would you need to resample/stretch them?
>
> ​
>

[Benny Alexandar]

Yes Paul, your understanding is right.

Rubber band audio is meant for this I guess
(Rubber Band Library is a high quality software library for audio time-stretching and pitch-shifting. )

-ben

________________________________
From: Paul Davis <***@linuxaudiosystems.com>
Sent: Sunday, June 17, 2018 4:38 PM
To: Benny Alexandar
Cc: Ralf Mardorf; linux-audio-***@lists.linuxaudio.org
Subject: Re: [LAU] Audio seamless switch

​So you want to stretch/shrink the newly-switched-to audio so that it "catches​ up" with the just-switched-from audio and then runs at normal speed?

This strikes me as madness, but hey, good luck!


On Sun, Jun 17, 2018 at 4:16 AM, Benny Alexandar <***@outlook.com<mailto:***@outlook.com>> wrote:
>>>why would you need to resample/stretch them?
​
As mentioned earlier the two audio are identical but one will be ahead/delayed than other.
The user who is listening to it should not notice the switching, and this
switching happens when the quality of one audio is degraded compared to other.

-ben

________________________________
From: Paul Davis <***@linuxaudiosystems.com<mailto:***@linuxaudiosystems.com>>
Sent: Sunday, June 17, 2018 12:01 AM
To: Benny Alexandar
Cc: Ralf Mardorf; linux-audio-***@lists.linuxaudio.org<mailto:linux-audio-***@lists.linuxaudio.org>
Subject: Re: [LAU] Audio seamless switch



On Sat, Jun 16, 2018 at 2:13 PM, Benny Alexandar <***@outlook.com<mailto:***@outlook.com>> wrote:
>> What is the reason that signal
1 is ahead of signal 2?

For various reason, one audio receiving from network and
other thru air.

>> Perhaps a simple delay is what you are looking for, but maybe you need
resampling.

Yes delay estimation is required as the delay is not known upfront.
In addition to re-sampling stretching also required.

​that turns it into a totally different problem. You originally said: ​

two identical audio inputs say A1 & A2.

why would you need to resample/stretch them?

​

[Fons Adriaensen]

On Sun, Jun 17, 2018 at 12:28:22PM +0000, Benny Alexandar wrote:

> Rubber band audio is meant for this I guess
> (Rubber Band Library is a high quality software library for audio time-stretching and pitch-shifting. )

This doesn't make any sense at all.

If the delay between the two signals isn't fixed, there is no point in
comparing their quality (unless the difference is so big that it's
obvious from the start). Whatever you do to stretch the signals will
produce so much artefacts that any subtle quality difference is lost.

And if the time difference is fixed, just adjust a delay plugin
manually, then crossfade. Any DAW will do that.

--
FA

[Chris Caudle]

On Sun, June 17, 2018 3:16 am, Benny Alexandar wrote:
> The user who is listening to it should not notice the switching, and this
> switching happens when the quality of one audio is degraded compared to
> other.

Is like the digital radio schemes where a digital program and an analog FM
signal are both broadcast, and if the reception changes such that the
digital signal cannot be received the audio is switched to the analog
signal?

> Yes delay estimation is required as the delay is not known upfront.

Is that acceptable to require user intervention, e.g. adjust delay until
it sounds correct, or are you looking for automatic delay estimation? If
you want automatic delay estimation it is unlikely you will find anything
off the shelf that does what you want. You would need to check the
auto-correlation value as a function of delay and find the delay at which
the signals are most correlated.

> In addition to re-sampling stretching also required.

You have not adequately explained why either resampling or stretching
would be required. If the two streams are from the same source but one
path has a delay, then presumably a fixed delay would be all you need.

--
Chris Caudle

[Benny Alexandar]

>Is like the digital radio schemes where a digital program and an analog FM
>signal are both broadcast, and if the reception changes such that the
>digital signal cannot be received the audio is switched to the analog
>signal?

Yes, you are right. That is the use case.

>Is that acceptable to require user intervention, e.g. adjust delay until
>it sounds correct, or are you looking for automatic delay estimation? If
>you want automatic delay estimation it is unlikely you will find anything
>off the shelf that does what you want. You would need to check the
>auto-correlation value as a function of delay and find the delay at which
>the signals are most correlated.

I would like that to be automated by correlating and finding the delay.
However, in case of analog broadcast to digital program will have a
fixed delay 3-4 seconds.But if the switching is from IP broadcast to
digital radio then it can be variable.

Can Ardour DAW be programmed to a fixed delay and do the cross fading of two audio ?
Will it support real time audio streaming audio captures through sound card and playback
through sound cards.

>If the two streams are from the same source but one
>path has a delay, then presumably a fixed delay would be all you need.

Yes, if the sample rates of both are same.

-ben
________________________________
From: Linux-audio-user <linux-audio-user-***@lists.linuxaudio.org> on behalf of Chris Caudle <***@chriscaudle.org>
Sent: Thursday, June 21, 2018 2:36 AM
To: linux-audio-***@lists.linuxaudio.org
Subject: Re: [LAU] Audio seamless switch

On Sun, June 17, 2018 3:16 am, Benny Alexandar wrote:
> The user who is listening to it should not notice the switching, and this
> switching happens when the quality of one audio is degraded compared to
> other.

Is like the digital radio schemes where a digital program and an analog FM
signal are both broadcast, and if the reception changes such that the
digital signal cannot be received the audio is switched to the analog
signal?

> Yes delay estimation is required as the delay is not known upfront.

Is that acceptable to require user intervention, e.g. adjust delay until
it sounds correct, or are you looking for automatic delay estimation? If
you want automatic delay estimation it is unlikely you will find anything
off the shelf that does what you want. You would need to check the
auto-correlation value as a function of delay and find the delay at which
the signals are most correlated.

> In addition to re-sampling stretching also required.

You have not adequately explained why either resampling or stretching
would be required. If the two streams are from the same source but one
path has a delay, then presumably a fixed delay would be all you need.

--
Chris Caudle

[Paul Davis]

On Wed, Jun 20, 2018 at 9:48 PM, Benny Alexandar <***@outlook.com>
wrote:

>
> Can Ardour DAW be programmed to a fixed delay and do the cross fading of
> two audio ?
>

​No, unless by "program" you mean "write code".​



> Will it support real time audio streaming audio captures through sound
> card and playback
> through sound cards.
>

​Of course. That's what it does (in part).​



>
> >If the two streams are from the same source but one
> >path has a delay, then presumably a fixed delay would be all you need.
>
> Yes, if the sample rates of both are same.
>

​You've previously expressed the belief that you need timestretching.​
​

[Chris Caudle]

On Wed, June 20, 2018 8:55 pm, Paul Davis wrote:
> On Wed, Jun 20, 2018 at 9:48 PM, Benny Alexandar <***@outlook.com>
> wrote:
>> Can Ardour DAW be programmed to a fixed delay and do the cross fading of
>> two audio ?

> ‹No, unless by "program" you mean "write code".

Fixed delay is pretty straight forward using a delay plugin, but that
generally is manually configured. Analyzing two streams to determine the
delay between them would have to be done external to Ardour, that is not
something you would do during music production.

>> >If the two streams are from the same source but one
>> >path has a delay, then presumably a fixed delay would be all you need.
>>
>> Yes, if the sample rates of both are same.
>
> You've [Benny] previously expressed the belief that you need
timestretching.

Delay and adjusting gain up and down are pretty simple, there are probably
a few different ways to do that, the complicated parts are automatically
determining the needed delay, and handling the case where delay changes
for some reason. That could be disruptive to the audio if you have to
change parameters on the stream which is currently playing.

--
Chris Caudle