Blackaddr
Well-known member
I have noticed a potential bug / limitation regarding the order in which audio effects (classes which inherit AudioStream) are called.
I was seeing much greater latency then I should, and the latency was changing with the number of effects in the chain. I eventually narrowed this symptom down to the following sequence:
- AudioStream constructors append themself to the update list.
- The order they appear in this list is based on the order they are instantiated in the code, since that's the orders the constructors are called.
- The update_all() software ISR will call their individual update() functions based on the order they appear in the list, not the order they are connected. For multichannel chains with mixers, this is a complicated graph that requires precise traversal order.
Most people probably don't notice because they naturally declare their objects in the order they intend to the connect them and don't have much multi-channel chaining going on. However, if you declare them in a different order then they will be connected, I suspect their update() functions will be called in the wrong sequence. For me, this oddly seemed to manifest itself as additional latency, but I think it's better to say when connection order doesn't match declaration order, results are undefined? I have never noticed obviously corrupted or wrong audio, but I definitely see a manifestion of increased latency.
In my case, I have an advanced AudioStream class object that provides some dynamic signal chain changes, so I cannot simply instantiate in a fixed order that matches the audio processing order.
I was seeing much greater latency then I should, and the latency was changing with the number of effects in the chain. I eventually narrowed this symptom down to the following sequence:
- AudioStream constructors append themself to the update list.
- The order they appear in this list is based on the order they are instantiated in the code, since that's the orders the constructors are called.
- The update_all() software ISR will call their individual update() functions based on the order they appear in the list, not the order they are connected. For multichannel chains with mixers, this is a complicated graph that requires precise traversal order.
Most people probably don't notice because they naturally declare their objects in the order they intend to the connect them and don't have much multi-channel chaining going on. However, if you declare them in a different order then they will be connected, I suspect their update() functions will be called in the wrong sequence. For me, this oddly seemed to manifest itself as additional latency, but I think it's better to say when connection order doesn't match declaration order, results are undefined? I have never noticed obviously corrupted or wrong audio, but I definitely see a manifestion of increased latency.
In my case, I have an advanced AudioStream class object that provides some dynamic signal chain changes, so I cannot simply instantiate in a fixed order that matches the audio processing order.
Last edited: