Re: quartz: Start DirectSound renderer as soon as possible.
I've been working on a set of patches (compiled together and attached for your convenience) to fix the background music in Fallout 3 (Bug #24478) and I've run into some trouble recently with commit 64b14c0ecdd13530a92ff636c451523a99253a0b. Before that commit (or removing that commit in current git) and applying the patches allows the music to function in both the main menu, properly stop when the menu is closed, and later play again when the user is in the game. With said commit applied these patches still permit the background music to work when at the main menu; however, the moment the "stop" occurs on exiting the menu then all audio in the entire game ceases to function. I would really appreciate any feedback you can provide or pointers on where to look for the source of this problem. Thanks in advance! Erich Hoover ehoover(a)mines.edu
Hi Erich, 2010/11/21 Erich Hoover <ehoover(a)mines.edu>:
I've been working on a set of patches (compiled together and attached for your convenience) to fix the background music in Fallout 3 (Bug #24478) and I've run into some trouble recently with commit 64b14c0ecdd13530a92ff636c451523a99253a0b. Before that commit (or removing that commit in current git) and applying the patches allows the music to function in both the main menu, properly stop when the menu is closed, and later play again when the user is in the game. With said commit applied these patches still permit the background music to work when at the main menu; however, the moment the "stop" occurs on exiting the menu then all audio in the entire game ceases to function. I would really appreciate any feedback you can provide or pointers on where to look for the source of this problem. Thanks in advance! There are other ways to handle this. What you're doing is wrong. I'm guessing the assert(!pSample); is wrong, if it's flushing it ought to return all samples held. If it has a sample and returned VFW_E_TIMEOUT I guess it has to break. The preferred allocator would have to be a separate patch.
Cheers, Maarten
On Sun, Nov 28, 2010 at 8:28 AM, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote:
... There are other ways to handle this. What you're doing is wrong. I'm guessing the assert(!pSample); is wrong, if it's flushing it ought to return all samples held. If it has a sample and returned VFW_E_TIMEOUT I guess it has to break. The preferred allocator would have to be a separate patch.
If you'd prefer I can attach these separately, but I really consider this to be three separate patches (applied in this order): 1) Freeing all pending samples when terminating 2) Only asserting when VFW_E_TIMEOUT actually times out 3) Passing a preferred allocator Patch 3 is the "main problem" for F3 and the first two are issues with paused/stopped filters. Without Patch 1 then Patch 3 always causes Fallout 3 to crash when exiting the main menu, and it will sometimes (very rarely) crash when exiting the menu without Patch 2. It sounds to me like you're taking issue with Patch 2 (the VFW_E_TIMEOUT portion), and I can look into better ways to do this part. The big thing that I was hoping you could help me with is that, with commit 64b14c0ecdd13530a92ff636c451523a99253a0b applied, once you exit the main menu then absolutely all the audio stops working - but only when both your commit and my patches are applied. It's not obvious to me how these patches could interact with your commit in this way, and nothing obvious stands out in the log, so I was hoping you could point me in the right direction for where to start figuring this out. Thanks so much for taking the time to look at this. Erich Hoover ehoover(a)mines.edu
Hi Erich, 2010/11/28 Erich Hoover <ehoover(a)mines.edu>:
On Sun, Nov 28, 2010 at 8:28 AM, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote:
... There are other ways to handle this. What you're doing is wrong. I'm guessing the assert(!pSample); is wrong, if it's flushing it ought to return all samples held. If it has a sample and returned VFW_E_TIMEOUT I guess it has to break. The preferred allocator would have to be a separate patch.
If you'd prefer I can attach these separately, but I really consider this to be three separate patches (applied in this order): 1) Freeing all pending samples when terminating 2) Only asserting when VFW_E_TIMEOUT actually times out 3) Passing a preferred allocator
Patch 3 is the "main problem" for F3 and the first two are issues with paused/stopped filters. Without Patch 1 then Patch 3 always causes Fallout 3 to crash when exiting the main menu, and it will sometimes (very rarely) crash when exiting the menu without Patch 2. It sounds to me like you're taking issue with Patch 2 (the VFW_E_TIMEOUT portion), and I can look into better ways to do this part. The big thing that I was hoping you could help me with is that, with commit 64b14c0ecdd13530a92ff636c451523a99253a0b applied, once you exit the main menu then absolutely all the audio stops working - but only when both your commit and my patches are applied. It's not obvious to me how these patches could interact with your commit in this way, and nothing obvious stands out in the log, so I was hoping you could point me in the right direction for where to start figuring this out. Thanks so much for taking the time to look at this. Well, that is because that assertion is wrong. pSample can be returned on timeout when flushing, but it wouldn't contain any data. I assume this is the bug you're hitting in patch 2, so if it holds a sample just break, and release all pSamples returned by that function.
Why my commit breaks things? If all sound stops working I'm guessing it is a sound bug. Cheers, Maarten
participants (2)
-
Erich Hoover -
Maarten Lankhorst