This is one of those cases where infinite loops are so predominantly a bad idea that there's no real support/convention around using them.

Based on the code you posted, what you've created here is a honeytrap. You can call the method any time you like, but you can never leave (I couldn't resist)

What you have here is the equivalent of asking your local government what signs you need to put up in your garden to tell people that you buried mines in your garden. The answer is that you shouldn't be burying mines in your garden.

The only practical use case for an infinite loop is for an application whose runtime process will be killed by the user (e.g. ping 8.8.8.8 -t is such an example). This is most commonly encountered in always-on services that are expected to run indefinitely.

However, playing a sound isn't something that you want your application to hang on. It's something you want to have happen concurrently. Therefore, you should design your code to work with it.

In essence, you should make a class that behaves like a media player. Maybe for you it's enough if this media player only has a start button with no way of ever turning it off again. I'll leave that up to you to decide.

But the play button click event is not an infinite loop. The sound should keep playing, but the click event should return.

This function never returns. Call it on a new thread.

Instead of pushing that responsibility to your consumer, just develop a class that, when called creates this thread and starts playing the sound.

This isn't a matter of "how do I tell my consumer that he should do this". It's significantly easier to do it for them. It promotes code reuse, lowers the change of bugs and unexpected behavior, and the documentation becomes easier to write as well.

Also, as an aside, you may want to look into using async/tasks instead of threads. It helps keep down the amount of active threads. But that's a different discussion.

This is one of those cases where infinite loops are so predominantly a bad idea that there's no real support/convention around using them.

Disclaimer
My experience is with C# (as is your code example, seems to be), but I would think that this is language-agnostic, unless there are languages which automatically wrap method calls in separate threads.

Based on the code you posted, what you've created here is a honeytrap. You can call the method any time you like, but you can never leave (I couldn't resist)

What you have here is the equivalent of asking your local government what signs you need to put up in your garden to tell people that you buried mines in your garden. The answer is that you shouldn't be burying mines in your garden.

The only practical use case for an infinite loop is for an application whose runtime process will be killed by the user (e.g. ping 8.8.8.8 -t is such an example). This is most commonly encountered in always-on services that are expected to run indefinitely.

However, playing a sound isn't something that you want your application to hang on. It's something you want to have happen concurrently. Therefore, you should design your code to work with it.

In essence, you should make a class that behaves like a media player. Maybe for you it's enough if this media player only has a start button with no way of ever turning it off again. I'll leave that up to you to decide.

But the play button click event is not an infinite loop. The sound should keep playing, but the click event should return.

This function never returns. Call it on a new thread.

Instead of pushing that responsibility to your consumer, just develop a class that, when called creates this thread and starts playing the sound.

This isn't a matter of "how do I tell my consumer that he should do this". It's significantly easier to do it for them. It promotes code reuse, lowers the change of bugs and unexpected behavior, and the documentation becomes easier to write as well.

Also, as an aside, you may want to look into using async/tasks instead of threads. It helps keep down the amount of active threads. But that's a different discussion.