View Issue Details

IDCategoryLast Update
0005457bugs2021-01-05 19:09
ReporterLost_HighwayAssigned To 
Reproducibilityalways 
Status confirmedResolutionreopened 
Product Version3.0 
Fixed in Version 
Summary0005457: Feedback loop detection [was: No sound and unrealistically low CPU load on re-opening a specific session]
DescriptionUsing Ardour 3.1 binary from the Ardour website (3.1-3-g1606996)

A session I was working on, which had a CPU load ~50%, was saved and closed. Upon re-opening the session the following day, the CPU load now registers 2% and there is no sound at all from the session.

Notes:
-- No tracks are soloed
-- Mute isn't activated on either the Master or Monitor section, Monitor volume at 0 dB
-- Transport appears to work normally
-- The session has been saved and re-opened numerous times before
-- Other sessions work fine
-- Not aware of any relevant lib upgrades from Ubuntu (doesn't using the binary from the website negate this?)
-- In qjackctl, all the relevant track/bus connections look to be in place, with tracks connected to Master, Master connected to Monitor, Monitor connected to system playback_1 and _2
-- Renaming and using the .bak session file instead makes no difference
-- Session file attached

TagsNo tags attached.

Activities

2013-04-23 19:24

 

SPANISH THEME ICE AXXE.ardour (547,686 bytes)

the_CLA

2013-04-23 22:20

reporter   ~0014878

Loading the session I noticed that the feedback button is blinking. The feedback detection is intended to keep you from accidentally creating a feedback loop wich might be harmful for your hearing and/or equipment, but I believe it is currently a bit broken in that it only blocks the audio after a session reload.

Also I dislike the way it currently is implemented. IMHO instead of blinking a button it should open a popup on creation and ask if the loop is intended, as there are cases where one wants to create a feedback loop - for example for adding filters in a delay loop etc... Maybe the feature should be disabled as long as it is not implemented properly.

Regarding your session I wasn't able to indentify a loop on a quick overview. So not sure if there actually is a loop or if Ardour only *thinks* there is one.

Lost_Highway

2013-04-23 22:28

reporter   ~0014879

There should be a feedback loop and it was intentional: a bus (with delay) feeds into a second bus (with reverb) that then feeds back into the first one.

The session operated fine with the feedback loop. Can't remember whether I've successfully re-opened it since, or whether it was the day after creating the feedback loop that it wouldn't re-open correctly.

the_CLA

2013-04-23 22:34

reporter   ~0014880

Ah, I see it now. Deleting (only disabling doesn't work AFAIK) one of the sends should bring back the sound again.

Lost_Highway

2013-04-24 09:06

reporter   ~0014881

Deleting one of the sends has restored audio.

So it's a "feature" of the feedback detection. I agree that the way it is implemented is not helpful: as you say, the fact that feedback loops can be purposefully implemented and serve a useful purpose, but also the fact that sound is disabled automatically without there being any message or warning of why it has been disabled.

Lost_Highway

2013-04-24 09:08

reporter   ~0014882

Disabling of audio is a "feature" when there is an audio feedback loop present in a session.

nettings

2013-04-24 10:11

manager   ~0014883

I got bitten by the same issue recently, and briefly discussed this with las and rgareus on IRC.
There is a "workaround": the audio only gets disabled when you load the session with feedback present. When you create a feedback loop at runtime, the warning lamp will blink but the audio graph will continue processing.
So before you save, break the feedback loop, and reconnect it manually when you resume working the next day. Ugly, but will get you going.

nettings

2013-04-24 10:17

manager   ~0014884

I'm reopening this bug because the reporter got bitten by the current implementation, which is less than ideal.
The way I see it, Ardour3 should

* mute audio the moment a feedback loop is created at runtime (which it doesn't, right now)
* blink the warning button red (which it does)
* allow the user to acknowledge that this particular feedback is intentional, and continue working, or detect that the user has removed an unintentional feedback loop, and continue working.

The problem with the status quo is that Ardour makes you believe creating feedback loops is ok and works, and then stops cooperating when you restore the session.

x42

2013-04-26 11:11

administrator   ~0014887

Feedback detection is not a feature. It's a side-effect.

Ardour tries to determine the order in which audio from all tracks/routes needs to be processed. IOW "it builds an execution graph and topologically sorts it".

If there is a feedback loop, the graph cannot be sorted.
Ardour it just uses the old graph - until the feedback loop is resolved.

When you reload a session -> there is no old graph.

The old graph order /may/ work with the feedback-loop that you've created but when you add new tracks or busses after creating a feedback loop, those nodes will not be included in the audio-processing graph.

There is no easy way to "disactivate" this feature. -- Ardour could break the loop for you (at some arbitrary point) in order to sort the graph:..the looped-back signal would arrive one cycle later. Yet Ardour cannot know which path it should keep and does not make any assumptions.

The old execution graph may produce feedback with the new set of connections.. Hence Ardour should just not use the old graph -> that'd fix the aspect of "makes you believe it works" and it would always mute the audio in case of a feedback.

caryoscelus

2021-01-05 19:09

reporter   ~0025382

even though this issue is old, it seems to be the most up-to-date discussion on topic, so since it's still not resolved i'm going to write my thoughts here.

that's a good explanation of the issue i haven't understood previously. thanks, x42.

but i think it also reveals potential solution. i'm not sure if there's any other valid use for feedback loops, but the only way i find them useful is when there's a delay (as explained here: https://discourse.ardour.org/t/creating-and-controlling-feedback/90481/7). in such situations proper sorting is still possible if delay plugin is discovered correctly (one way would be to make delay a built-in feature, but i'm not sure what would be easier/more convenient/generally better for ardour). would it be possible to implement this?

Issue History

Date Modified Username Field Change
2013-04-23 19:24 Lost_Highway New Issue
2013-04-23 19:24 Lost_Highway File Added: SPANISH THEME ICE AXXE.ardour
2013-04-23 22:20 the_CLA Note Added: 0014878
2013-04-23 22:28 Lost_Highway Note Added: 0014879
2013-04-23 22:34 the_CLA Note Added: 0014880
2013-04-24 09:06 Lost_Highway Note Added: 0014881
2013-04-24 09:08 Lost_Highway Note Added: 0014882
2013-04-24 09:08 Lost_Highway Status new => closed
2013-04-24 09:08 Lost_Highway Resolution open => no change required
2013-04-24 10:11 nettings Note Added: 0014883
2013-04-24 10:17 nettings Note Added: 0014884
2013-04-24 10:17 nettings Severity major => minor
2013-04-24 10:17 nettings Reproducibility have not tried => always
2013-04-24 10:17 nettings Status closed => confirmed
2013-04-24 10:17 nettings Resolution no change required => reopened
2013-04-24 10:17 nettings Summary No sound and unrealistically low CPU load on re-opening a specific session => Feedback loop detection [was: No sound and unrealistically low CPU load on re-opening a specific session]
2013-04-26 11:11 x42 Note Added: 0014887
2021-01-05 19:09 caryoscelus Note Added: 0025382