YAM can't quit after filter action with sound.

last lines of a '@all all' log

I just tested this on OS4 with about 20 mails to be filtered. After lots of noise due to one sample being played 20 times YAM was able shut down without a single warning.

This really seems to be an issue with the sound.datatype being used. As I said before already, there are several versions out there which don't implement asynchronous playback on a per object basis correctly. The v41sound.datatype I use on my WinUAE setup perfectly plays several samples, but only the last of YAM's playback threads will be notified of the finished playback. All other threads are left in the rain. This indicates that the notification information is stored globally instead in the object's instance data and any additional playback will erase the notification information of the first object.

The former synchronous implementation just aborted playback of any still playing sample whenever a new sample had to be played. From my point of view this is not what one would expect. Constantly aborting the playback until the last filter's playback action finally plays the sample completely is no really good idea.

There are several options to solve this:

1. switch back to synchronous playback as in YAM 2.6, at least for OS3
2. remove sound playback from the possible filter actions, because one cannot know how many mails will be filtered and having one sample being played a hundred times because the filter was used that often will be quite noisy.
3. find a sound.datatype for OS3 which correctly implements simultaneous asynchronous playback of several samples and advice the people to use this.

Personally I would go for either 2 or 3 first.

The sample playback for new mails happens only once for each download attempt, but not for every single mail, which is a far better approach than the per filter and per mail playback.

I investigated a bit and for AmigaOS3 the situation is really bad.

I have two versions of sound.datatype on my WinUAE setup:
v41sound.datatype 41.11 (11.08.2000) © 1998-2000 by Stephan Rupprecht
sound.datatype 44.25 (18.10.2001)

Both can play more than one sample, but with different results. I used a simple 8bit mono sample.

v41sound.datatype can play only one sample and signal the end of the playback. Starting a second playback action while the first is still running will play both, but the end of the first playback will never be signaled, only the end of the second playback.

sound.datatype 44.25 can play up to 4 samples and the end of each playback action is correctly signaled. But from the 5th playback action on while the first 4 are still running I get the same result as with v41sound.datatype. This seems to be due to the mono sample. For a stereo sample I assume the limit would have been 2.

To make a long story short: playing lots of samples with any sound.datatype on AmigaOS3 is a real PITA and will definitely fail sooner or later. Because of this, and the fact that playing a sample for each and every mail being filtered by one filter is absolute non-sense, I really opt to remove the sound playback option from the filters.

Opinions please!

Back from vacation I have now read through the discussion and I have to say that I vote against removing the playback option from the filter action as many people might already use that. Instead I have the feeling that we should probably bring back the old behaviour in that particular case. I understand that putting the playback into a separate thread might be favourable, but if we can't garantuee that this really works because of dependencies against sound.datatype, I think we should synchronize the playback threads somehow so that only one thread can playback at a time. This could be either be done with a separate public sempahore or with reverting to the old mechanism of playing the sample in the main thread because the playback is anyway performed asynchronously (as it alwas has been before we introduced the threads) and thus will not block anything and we also don't really need to know if the playback was successfull or not (we don't need to give the user a feedback for that really).

So for me the option to remove the possibility to play a sound on a filter action is really the worst option and we should think about other possibilities (like I outlined).

I use that feature in my filters so i vote of course for not removing
that feature. I use it not for every filter but for some important
filters. Most i hear the sound if i get a mail which inform me that
i got a bill.

I don't have a solution for the problem and i can't believe that
the sound.datatype is so corrupt and nobody complained...

Ok, I will revert the sound playback to the old approach then.
But believe me. Certain parts of AmigaOS3 are really buggy, if you like it or not. And the fact that nobody complained so far is just because nobody has used simultaneous playback of many samples excessively by now. Otherwise this design fault would have be obvious instantly, as it now happend with YAM.

(In [5263]) * YAM_UT.c, Threads.c: removed the sound playback in a separate thread again

and reverted to the old approach. AmigaOS3's sound.datatype is simply too
buggy to be able to play more than 4 samples in different threads without
causing major problems. This closes #214.