"Audio playback engine failed to start" error in Reference 4 Systemwide

Comments

6 comments

  • Avatar
    karlis.stenders (Edited )

    Hi everyone, 

    We are still sorting out a couple of problems with this new feature - for some users, the playback engine failure notification might be showing up every time on start-up. 

    We are hoping to sort this out in a few days time. The current release is build 4.3.4.2, check the downloads page in a few days - if there is a later build available, it should include the fix for this too.

    Thank you guys!

    0
    Comment actions Permalink
  • Avatar
    Jörg Stumpp

    Beta Revision 4.3.5.1 solved all issues

    0
    Comment actions Permalink
  • Avatar
    Ron Hatfield

    I get it every time I put my computer to sleep (Windows 10).

    It requires a computer restart for it to "find" the device again. 

    Total PITA.

    Reference 4.4.2.86

    0
    Comment actions Permalink
  • Avatar
    Chris

    Some users that experience playback engine failures on Reference 4.4.2. running Focusrite interfaces have reported that reinstall of current Focusrite drivers solves the issue. 
    Driver downloads can be retrieved following this link -

    https://customer.focusrite.com/en/support/downloads?brand=Focusrite&product_by_type=555&download_type=all

    0
    Comment actions Permalink
  • Avatar
    Alexander Zlamal

    Hi, it seems Sonarworks is incompatible with AudioHijack's ACE Extension, which enables the program to capture audio from any application that is currently open. With the ACE Extension I constantly got Errors regarding the Audio Playback Engine, removing the ACE Extension resolved the problem, everything is fine again now. Obviously Sonarworks and AudioHijack have a similar way to reroute system audio. Unfortunately the similarity also leads to an incompatibility. Maybe this can be resolved at some point?

    0
    Comment actions Permalink
  • Avatar
    Chris

    Hey Alexander,

    If AudioHijack also functions as a Virtual Output device it is very likely that you are correct.
    One virtual device routing signal into another might cause some conflicts, but this might differ from case to case depending on your interface, version of Reference 4 as well as OS. 
    If you'd like to investigate a possible solution further, feel free to submit a support ticket here and we will do our best to help you!

    0
    Comment actions Permalink

Please sign in to leave a comment.