View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005457 | ardour | bugs | public | 2013-04-23 19:24 | 2021-01-05 19:09 |
| Reporter | Lost_Highway | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | confirmed | Resolution | reopened | ||
| Product Version | 3.0 | ||||
| Summary | 0005457: Feedback loop detection [was: No sound and unrealistically low CPU load on re-opening a specific session] | ||||
| Description | Using 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 | ||||
| Tags | No tags attached. | ||||
|
2013-04-23 19:24
|
|
|
|
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. |
|
|
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. |
|
|
Ah, I see it now. Deleting (only disabling doesn't work AFAIK) one of the sends should bring back the sound again. |
|
|
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. |
|
|
Disabling of audio is a "feature" when there is an audio feedback loop present in a session. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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? |
| 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 |
