int main(int argc, char** argv) {
if (!Mix_OpenAudio(44100, AUDIO_S16, 2, 4096)) {
Mix_Chunk *SoundTest = Mix_LoadWAV("/home/x/test.wav");
Mix_PlayChannel(-1, SoundTest, 0);
}
while (1);
}
The operating system is Ubuntu Server 10.04 with pulseaudio and asla installed perfectly. It also has an extremely basic Xorg installation with no window manager.
When I run this program within the command terminal (CTRL-ALT-F2), it works as expected: It plays the sound and sits there until I hit CTRL-C.
When I run this program within the basic Xorg desktop by launching it from the script “/etc/X11/xinit/xinitrc”, the program runs but the sound does not play. The peculiar thing about this problem is that if I then press CTRL-ALT-F2 and jump to the command window, it plays the sound during the transition. Its almost as if Xorg does not let SDL play the sound.
I have tried playing multiple sounds timed to play at different times, and it works as expected in the command line but it is deafly quiet in Xorg until I hit CTRL-ALT-F2 or CTRL-ALT-F1 or anything that hides Xorg at which point it plays all the sounds all at once during the transition as if it had been queued.
Can anyone point me in a productive direction to fix this problem?
I was under the impression that SDL mixer needed SDL_init called first…
-AlexOn Thu, May 10, 2012 at 2:50 PM, NiGHTS wrote:
**
Here is the code I am working with:
Code:
int main(int argc, char** argv) {
if (!Mix_OpenAudio(44100, AUDIO_S16, 2, 4096)) {
Mix_Chunk *SoundTest = Mix_LoadWAV("/home/x/test.wav");
Mix_PlayChannel(-1, SoundTest, 0);
}
while (1);
}
The operating system is Ubuntu Server 10.04 with pulseaudio and aslainstalled perfectly. It also has an extremely basic
Xorg installation with no window manager.
When I run this program within the command terminal (CTRL-ALT-F2), it
works as expected: It plays the sound and sits there until I hit CTRL-C.
When I run this program within the basic Xorg desktop by launching it from
the script “/etc/X11/xinit/xinitrc”, the program runs but the sound does
not play. The peculiar thing about this problem is that if I then press
CTRL-ALT-F2 and jump to the command window, it plays the sound during the
transition. Its almost as if Xorg does not let SDL play the sound.
I have tried playing multiple sounds timed to play at different times, and
it works as expected in the command line but it is deafly quiet in Xorg
until I hit CTRL-ALT-F2 or CTRL-ALT-F1 or anything that hides Xorg at which
point it plays all the sounds all at once during the transition as if it
had been queued.
Can anyone point me in a productive direction to fix this problem?
I was under the impression that SDL mixer needed SDL_init called first…-Alex
My original program with this implementation is several thousands of lines of C code. I commented out 99.99% of all the code leaving this. The original program uses SDL_Init(), but it is commented out and it still seems to work fine, so apparently it doesn’t need SDL_Init to work. Either way, the same symptoms occur in the main program with an entire OpenGL interface running.
What happens if you kill the PulseAudio process after X has started?On 10/05/12 21:50, NiGHTS wrote:
[…]
When I run this program within the basic Xorg desktop by launching it
from the script “/etc/X11/xinit/xinitrc”, the program runs but the sound
does not play. The peculiar thing about this problem is that if I then
press CTRL-ALT-F2 and jump to the command window, it plays the sound
during the transition. Its almost as if Xorg does not let SDL play the
sound.
I solved the problem. It was many things, none of which was related to SDL or SDL_mixer.
For those who want to know how I repaired it, I had to edit /etc/init.d/pulseaudio and change the value of PULSEAUDIO_SYSTEM_START to 1. Also, I needed to add the user logged in to Xorg to the following group’s: pulse, pulse-access, audio.
This is apparently only required for an Xorg installation with a minimalist window manager or none at all. If Gnome or KDE were installed, they take control of the audio system on their own and it would not be an issue.