| Summary: | SDL application hangs on closing audio when using arts | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Patrice Mandin <patmandin> |
| Component: | audio | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P1 | ||
| Version: | 1.2.11 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Attachments: |
Patch using arts_suspended() function to check for audio device available
Use arts_suspend in a loop to wait for arts being ready |
||
|
Description
Patrice Mandin
2006-12-18 15:04:34 UTC
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 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 Created attachment 186 [details]
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.
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. Commited to 1.2.x, you can merge it in 1.3.x Reassigning bug to myself so I remember to merge into 1.3. --ryan. 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. 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. Created attachment 548 [details]
Use arts_suspend in a loop to wait for arts being ready
(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. That is scary. I went ahead and made that change for SDL 1.2 and 1.3.
I applied Attachment #548 [details], 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.
|