-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Partially fix "Dummy" actually using ALSA #2376
Conversation
Looks great. Not sure about the re-showing of the dialog problem, but I suspect that it is an existing problem. Clean shuffling of operations here to honor an explicit The only problem that I have with this approach in general is that the Dummy state is undesired almost always, so we should have a fallback state AND a dummy state so that dummy is explicitly chosen when it is explicitly selected. As mentioned in the bug report, I don't think this is possible currently because we don't keep track of what is selected, but rather what is displayed, so we may decide to keep the counter-intuitive behavior in lieu of better sane defaults. |
In // look whether mixer could use a audio-interface beside AudioDummy
else if( Engine::mixer()->audioDevName() == AudioDummy::name() )
{
// no, so we offer setup-dialog with audio-settings...
SetupDialog sd( SetupDialog::AudioSettings );
sd.exec();
} As we can see, the settings dialog will be shown every time Dummy is selected by the program (either explicitly or as a fallback). A simple solution is to set a boolean variable to |
In const surroundSampleFrame* b = mixer()->nextBuffer();
if( !b )
{
break;
} The cause of the error message when using DummyAudio and closing the program seems to be |
Somehow I missed the additional work you did on this. Thanks. Once someone has time to test, we'll need you to squash the commits and then we can merge the PR. |
Again... we can merge this once we get some valid testing and the commits are squashed. |
Except for the message on the console, everything went fine on my own tests some time ago, but I am going to do new tests today. I think the message on the console is a topic for a new issue. |
Thanks for the prompt reply. I'll tag a few testers... @Umcaruje @Wallacoloo @Spekular @musikBear if you had a dev environment setup, this would be a great one for you to test. |
@M374LX why did you close this? |
Having trouble with Git, as usual. |
👍 |
Finally, all changes in a single commit. Here are my tests:
|
@M374LX did you try to move/remove the |
By removing the file, the settings dialog is shown, but it looks like the program uses the first audio device available (ALSA in my system). Knowing that the audio device is initialized before the settings dialog is shown, this is perfectly logical. Again, this is a topic for a new issue. |
So SDL isn't available I take it? It should be first chosen via 1bb276b if it is available. |
Somehow, SDL seems to have been not detected on my system during the build process. It is not even available on the settings dialog. |
Fair enough. Thanks for the fix, testing, squashing. Top notch. Merging. |
Partially fix "Dummy" actually using ALSA
@tresf sorry, i dont have it- My old box dont have room for a linux partition |
It's tested and merged now, no worries. Want me to ship you a hard drive?
|
@tresf |
Just trying to get some help, that's all. 👍 |
Partial fix for #2349.
Even without this fix, an error opening the desired device seems to cause the setup dialog to be shown instead of simply falling back to Dummy. Also, the following message is shown on the console: