This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch using arts_suspended() function to check for audio device available (SDL_artsaudio.c.diff, text/plain, 2007-01-05 15:16:12 +0000, 2317 bytes)
• Use arts_suspend in a loop to wait for arts being ready (sdl-arts.diff, text/plain, 2010-12-14 13:05:36 +0000, 1827 bytes)

Reported in version: 1.2.11
Reported for operating system, platform: Linux, All

Comments on the original bug report:

On 2006-12-18 15:04:34 +0000, Patrice Mandin wrote:

With Aranym emulator (http://www.aranym.org/) we got numerous reports of crashes on exit, and it was reported to be caused by some strange thread stuff in SDL audio layer. After investigation, here are the infos.

First you must run an audio application that does not use arts, like a music player to listen to your favorite tunes. Then run an SDL application that uses arts audio daemon (either automatically or through the environnement variable).

The arts layer seems to be able to open the audio device, and thus does not tell SDL it failed. The problem is that it hangs later on application exit, when it's time to close the audio device.

Example with running XMMS (you can select the audio device), and then trying to run Aranym (the SDL app)
; xmms aranym
; arts arts ok
; arts alsa ok, aranym can't open audio
; arts oss ok, aranym can't open audio
; oss arts aranym hangs on exit
; oss oss ok, aranym can't open audio
; oss alsa ok, aranym can't open audio
; alsa arts aranym hangs on exit
; alsa oss ok, aranym can't open audio
; alsa alsa ok, aranym can't open audio

Here is the gdb backtrace from Aranym:

0 0xb7c02ce3 in pthread_join () from /lib/tls/libpthread.so.0

1 0xb7c6a7c1 in SDL_SYS_WaitThread () from /usr/local/lib/libSDL-1.2.so.0

2 0xb7c22e08 in SDL_WaitThread () from /usr/local/lib/libSDL-1.2.so.0

3 0xb7c1a813 in SDL_AudioQuit () from /usr/local/lib/libSDL-1.2.so.0

4 0xb7c1959b in SDL_QuitSubSystem () from /usr/local/lib/libSDL-1.2.so.0

5 0xb7c1a72a in SDL_CloseAudio () from /usr/local/lib/libSDL-1.2.so.0

6 0x0806985d in ~Host (this=0x81f3da8) at ../host.cpp:64

7 0x0804bdc0 in ExitAll () at ../main.cpp:576

8 0x0804c11d in QuitEmulator () at main_unix.cpp:331

9 0x0804c0e2 in main (argc=-4, argv=0xbff7eca4) at main_unix.cpp:313

It hangs because it 'waits' for something.

On 2006-12-29 17:41:30 +0000, Patrice Mandin wrote:

Forgot the usual version suspect:

• Debian Sarge 3.0, running Kde 3.3.2, libarts 1.3.2
  I will have to try with latest libarts (seems to be 1.5.x) to be sure

On 2007-01-05 09:21:55 +0000, Patrice Mandin wrote:

Tested with arts 1.4.3, problem still present. Here are more infos:

• arts_init() function only report error if it can't connect to arts server. It does not mean the arts server can open the sound device to play audio (for example, if you tell it to release the audio device after X seconds for other apps to grab it).
• A new call arts_suspended() has been added to libarts to check if the arts server is suspended or not (i.e. can use audio device or not), but SDL does not use it (I don't know in which arts version it was added). See http://bugs.kde.org/show_bug.cgi?id=59184

On 2007-01-05 15:16:12 +0000, Patrice Mandin wrote:

Created attachment 186
Patch using arts_suspended() function to check for audio device available

OK, here is a patch, it's working for me. Wait for comments before commiting.

On 2007-01-05 15:45:40 +0000, Ryan C. Gordon wrote:

Looks good to me. Go ahead and commit it when libsdl.org comes back up.

Let me know if you want me to merge it for the 1.3 trunk.

--ryan.

On 2007-01-06 12:31:28 +0000, Patrice Mandin wrote:

Commited to 1.2.x, you can merge it in 1.3.x

On 2007-01-06 13:02:40 +0000, Ryan C. Gordon wrote:

Reassigning bug to myself so I remember to merge into 1.3.

--ryan.

On 2007-06-14 07:23:26 +0000, Ryan C. Gordon wrote:

Weird...this isn't in Subversion for 1.2...did this get lost when we converted from CVS to Subversion or something?

I've committed it, so it's in there now, svn revision # 3068 for the 1.2 branch, and # 3069 for the 1.3 branch.

(Bumping to P1 so we know this got changed right near the end of 1.2.12 development.)

--ryan.

On 2010-12-14 13:04:27 +0000, Patrice Mandin wrote:

Hello,

I reopen this bug because since I got a new (much faster) box a while ago, I had problems getting the arts backend to work.

As is, SDL nearly always fail using arts, because arts is not ready when arts_suspended is called in Audio_Available, and I also think the same happens in ARTS_OpenAudio.

arts provides arts_suspend() function, and using it before calling arts_suspended() improves the rate of success.

Replacing the calls to arts_suspended() (in Audio_Available and ARTS_OpenAudio) by a function that loops till arts is ready solves my problem, but it can potentially be an infinite loop.

I thought of using SDL_GetTicks() to timeout after 5 seconds, but SDL timers may not be available, and SDL ticks are not initialized when Audio_Available is called.

On 2010-12-14 13:05:36 +0000, Patrice Mandin wrote:

Created attachment 548
Use arts_suspend in a loop to wait for arts being ready

On 2011-12-30 00:42:07 +0000, Ryan C. Gordon wrote:

(In reply to comment # 8)

I thought of using SDL_GetTicks() to timeout after 5 seconds, but SDL timers
may not be available, and SDL ticks are not initialized when Audio_Available is
called.

That's scary, we actually do initialize the audio subsystem before the timer subsystem (which includes setting base ticks for SDL_GetTicks() to function correctly). We should really change that for SDL 1.3, since having GetTicks functional at (almost) all times should be a reasonable assumption, even inside SDL itself.

--ryan.

On 2011-12-30 03:42:20 +0000, Sam Lantinga wrote:

That is scary. I went ahead and made that change for SDL 1.2 and 1.3.

On 2012-01-02 15:30:33 +0000, Ryan C. Gordon wrote:

I applied Attachment # 548, with a tweak to abort after three seconds if arts_suspend() isn't working out.

This is hg changeset 331f27f01cdb for the 1.2 branch, and ff0bc7241515 for the 1.3 branch.

Thanks!

--ryan.