@Heiko, When the system automatically signs-on the user and starts your application there may be a small delay before the session is locked. You can receive notifications when the system locks/unlocks a session. So if your application is notified that the session has been locked it should defer taking action (playing audio) until it receives a notification that the session has been unlocked.
Notifications can be received by using the SystemEvents.SessionSwitch Event. In the past some have indicated that events have not been fired. Alternative solutions are included in this thread - https://learn.microsoft.com/en-us/answers/questions/1293407/unable-to-capture-sessionswitch-events-in-windows
Update:
There is also a Windows API function that you can call using p/invoke that will return whether a session is locked/unlocked. The function is WTSQuerySessionInformationA and the information class to be requested is WTSSessionInfoEx. The returned WTSINFOEXA structure contains a WTSINFOEX_LEVEL1_A structure whose SessionFlags member indicates locked or unlocked. As with most Windows API functions there is also a "W" variant of the function and related structures for wide character strings (UNICODE).