I'm using an X5000. I used the PlayAHI test program (that you gave a link to) with some added Printf() statements in the LoadSample() function. The printout is good and the 2 example wave files you included with PlayAHI are working. The son_debut.wav is barely audible but both files play. Here is the printout from PlayAHI when I just tested again:
I also added in the meantime the same printf and all data are the same, except SDTA_Sample: zero here :(
Quote:
I have the same versions as you. Just to be sure here are the file sizes: wav.datatype = 70352 bytes sound.datatype = 141388 bytes
Yes same size here
Quote:
For testing the first fix at the end of July I received the mod.datatype, mpega.datatype, wav.datatype and sound.datatype. For test the latest fix I just received the sound.datatype.
I just got wav.datatype and sound.datatype but I guess mod.datatype and mpega.datatype are not required for the wav loading.
Quote:
As I mentioned, my wav.datatype and sound.datatype are the same version as yours. The only thing I can suggest is to check that you have the right WAVE descriptor in Devs:DataTypes and booting from the partition you updated. Of course the newer datatypes might not get used until rebooting after installing them. Other than that, I don't know why your datatypes are not working like mine.
Yes I used the right parititon and reboot before running PlayAHI. I also checked files versions at this time. So eveything is OK here.
Maybe the WAVE descriptor Devs:DataTypes: 2017-01-29 190 bytes Do you have the same?
Yes I used the right parititon and reboot before running PlayAHI. I also checked files versions at this time. So eveything is OK here.
Maybe the WAVE descriptor Devs:DataTypes: 2017-01-29 190 bytes Do you have the same?
Thank you for your help
Yes, my WAVE descriptor is the same.The only other thing I can suggest is that you play a WAVE sound with Multiview (or Multiviewer) and then enter "version sound.datatype" and "version wav.datatype" in a shell to check what versions are in memory. Beyond that, I can't really help you any more.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
@glames Don't feel bad. It stopped working for me too! As you can see in my first post, it worked the first day I received it. I can't really explain why it stopped working today. I didn't change anything on my system.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
@glames I've investigated what really happened with my testing. I have several boot partitions and I accidently tested the new sound.datatype on a partition that still had the OS4FE wav.datatype installed. Apparently, the latest wav.datatype I was sent for testing is still a streaming datatype. However, the latest test sound.datatype does work for non-streaming datatypes like 8SVX and AIFF. If the new wav.datatype can not be made to return the data address attribute, you can convert your sounds to 8SVX or AIFF and they should work.
Edited by xenic on 2017/8/29 13:38:50
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
@all Do to hasty testing my report that the Enhancer wav.datatype was returning an SDTA_Sample attribute was wrong. The latest sound.datatype did fix the SDTA_Sample attribute return by the (non-streaming) 8svx.datatype and aiff.datatype. Sorry for the misleading info.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
The wav datatype will return NULL for SDTA_Sample – it’s because the wav datatype is set to a streaming mode. Commodore documented “SDTA_Continuous” in the 3.1 NDK and defaulted to FALSE; the A-Eon sound datatype is the same in this respect. But that’s because the sound.datatype is a dumb component, it needs to be told what to do. The wav (and mod, mpega) subclass datatypes set SDTA_Continuous to TRUE to enable streaming, resulting in what was subsequently documented in the 3.5 NDK (v39) whereby the SDTA_LeftSample, SDTA_RightSample and SDTA_Sample will be NULL in this scenario. The reason AIFF/8SVX datatypes return a value is because they DO NOT stream – if they did, it would do exactly the same as the wav datatype.
I don’t know how to say it any simpler – this is a feature of a streaming scenario and not a bug – first documented in OS3.x, that has been present for ca. 20 years.
@amigakit Hopefully there are no plans to make any more sound datatypes streaming because we need at least one non-streaming datatype for small notification sounds like sending or receiving emails, instant messaging notification or any other programs that notify the user with short sounds.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
The wav datatype will return NULL for SDTA_Sample ? it?s because the wav datatype is set to a streaming mode.
TBH there is no reasonable reason for the WAV datatype to 'stream' by default. Memory is not an issue on modern amigaos systems. By making it stream by default you have broken the compatabilty of a standard system component, and this is *NOT* acceptable.
I haven't tested yet but I expet you can Add AWeb to the list of applications broken by the new datatype.
My suggestion would be that streaming default to off and be enabled by any appliactions that need it, by setting the appropriate flag.
[edit] This is imporant as there is not an easy way to verify the version of the datatypes classes available, since opening the library directly to check the version can cause the datatypes system to crash.
Do to hasty testing my report that the Enhancer wav.datatype was returning an SDTA_Sample attribute was wrong. The latest sound.datatype did fix the SDTA_Sample attribute return by the (non-streaming) 8svx.datatype and aiff.datatype. Sorry for the misleading info.
No problem. thank you for info.
@broadblues,
Quote:
TBH there is no reasonable reason for the WAV datatype to 'stream' by default. Memory is not an issue on modern amigaos systems. By making it stream by default you have broken the compatabilty of a standard system component, and this is *NOT* acceptable.
I DO agree. The compatibility of this standard system component was broken. Wav datatype must not stream by default as it was always the case, at least on AmigaOS 4 but also on MorphOS. Wav is often used to play small sounds so there is no need to do that.
@Amigakit,
It is *NOT* acceptable. I already spent 10 days to deal with an ISSUE that is not my fault (but yours). Moreover, two of my (commercial) games can't play any sounds for more than six months if users install enhanced packs or use X1000 or X5000. So I guess I, didn't make new sales because of it.
So, please FIX it and stop streaming wave files by default.
My suggestion would be that streaming default to off and be enabled by any appliactions that need it, by setting the appropriate flag.
Yes, surely SDTA_Continuous can be set on OM_NEW if required, so there's no need for the subclass to be defaulting it to something else?
As a temporary workaround for broken applications, can SDTA_Continuous, FALSE be set in the NewDTObject call? At least temporarily to check this fixes it?
As a temporary workaround for broken applications, can SDTA_Continuous, FALSE be set in the NewDTObject call? At least temporarily to check this fixes it?
Tried that. If you use GetDTAttrs() to get SDTA_Continuous after a NewDTObject call that doesn't set SDTA_Continuous, it is already FALSE. Setting it to FALSE in NewDTObject() doesn't change anything; SDTA_Sample is still NULL.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
If you turn off streaming in the new WAV datatype, it will in turn disable the new MultiChannel and downmixing support and all the other new features of the sound datatype as the WAV will be limited to the mono/left/right channels.
A small conditional block of 10 lines of code in your programs and you can support much richer and modern sound features.
Do we really want to be stuck in the 1990s with the old Sound DTC ?
Do you want to offer you customers the best sound experience in your product?
excuse me, but that isn't your call to make. you replaced an OS component outright which behaves differently, and you're asking third-party developers to change their code instead?!
this is *precisely* the reason why replacing OS components can be a bad idea. offering alternatives, no problem. that let's the users and developers decide. but overwriting the official software willy-nilly and expecting everyone else to support that is a bit much.
i'm really thrilled A-EON is doing so much, and i don't want to make it sound like i'm against all of the wonderful things you guys do, but you aren't hyperion. you aren't the OS vendor. either everything you replace must be 100% backwards compatible, or don't overwrite OS components. IMO, of course....
-- eliyahu
"Physical reality is consistent with universal laws. When the laws do not operate, there is no reality. All of this is unreal."
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
