Hello,
how to play wav files or mp3 files asynchronously?
I tried Thomas code that play wave files via Datatypes object, but the program execution stops until the full wave is played, then continue.
Moreover, would be nice to know how to play files such mp3 or ogg.
Thank you
Maybe using CreateNewProcess()?
and Function_Playsound() plays your soundfile via datatypes.
AOS4.1/SAM460ex/PPC460EX-1155MHZ/2048MB/RadeonHD6570/SSD120GB/DVDRW :-P
Thank you. I will try.
Btw, i was thinking about functions that you can use whenever you want, i.e. during game play.
Assuming i want to play/stop a sound within a certain event, adjust volume and son on...
Datatypes are always played asyncronously. If you'd look at the example carfully, you'd recognise that the DoMethod command triggers the play method and returns immediately while the sound is played in the background. The program contains an explicite Wait() so that it only exits when the sound has been played back completely. It does this because playing stops when the object is disposed. Instead of this Wait() you can certainly do something else.
@thomas
OK, thank you.
how do I know exactly when the sound stops playing?
There's a way to know currentPosition of the file when played?
If you set up a signal like in the example, you'll receive that signal when playing is finished.
I don't think so. But you can find it out yourself: just check the attributes of sound.datatype in the autodocs.
Thank you.
reading the autodocs...
I tried to play a 70 mb wave file, but doesn't work. It play only five seconds.
There's a way to play mp3 with this method? Or should i use other libraries?
Haw are you loading the sounds in? Just sending it to datatypes as a file? Or loading it in memory? In any case the sound would have to be converted to a 16-bit integer for AHI or whatever the output mode is set too. And if intending it for a game you will need to optimise it by using datatypes or some other means of caching the sounds in memory in native AHI format for instant playback.
I'd try to play the WAV file on Workbench t see if it's okay.
As for OGG and MP3 you will need a decoder. Unless there is a decoder already in datatypes you will need a datatype to decode it or use a library to do it.
Just loadingand playing the sound via DataType. The format, however, should be ok. Indeed the first 5 or more second are played, while the rest start jagging till no no sound at att soon after.
@AmigaBlitter
I just ripped a 69 MB song from a CD and converted it to RIFF-WAVE with AmiSoundEd (OS4Depot). I copied the WAV file to ram: and played it with Multiview (uses datatypes). I also set the WAV file as an event sound in Jabberwocky (which uses a seperate process to play sounds with datatypes). In both cases the song played perfectly to completion.
I suggest you try playing your WAV file with multiview. If it works in Multiview, it should work in any program that uses datatype sound play.
X1000 - OS 4.1FE
@xenic
Why not use AD Ripper? What have I been writing all those plugins for?! :-D
AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2
The easiest way may be to use no converters at all. OS4 includes audio tracks as AIFF files in the root. So all one has to do is open these on the Workbench or load them in with datatypes. They will be converted to AHI format either way. AIFF would be less overhead as AFAIK it's already the format AHI ues. Before AHI converts it to the native sound card format.
@hypex
That doesn't sound likely to me; why would AHI use any format? It's just an audio retargeting and playback system, all it accepts is raw sound data. It's the particular application (or datatype class) that is responsible for any conversion of data and feeding it raw to AHI. My guess at least.
AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2
Last time I checked, AHI (device interface) supported 8 or 16 bit signed or unsigned mono or stereo samples. 16 bit formats have to be stored MSB first (Motorola format).
As AIFF uses exactly this format (MSB first), you can load the AIFF data into a buffer and hand this buffer over to AHI without conversion.
In WAV files samples are stored LSB first, so you have to byte-swap the buffer before you can give it to AHI.
The AUDIO: file handler even knows AIFF headers so that you can simply copy an AIFF file to AUDIO: in order to play it back. You don't need to set data format, frequency and number of channels explicitely like you would with raw data.
@trixie
Actually, my statement wasn't entirely true. When 1 or 2 of my oldest CD's developed play errors, I copied all my CD's to a hard-disk partition for preservation. I actually converted a song from the copied file and not directly from a CD. I only wish that ADRipper could be updated to convert my music files from the hard disk instead of from the original CD's. ADRipper is sooooo much easier that converting with lame.
X1000 - OS 4.1FE
@xenic
Like CDex does it? Yes, that would indeed be splendid, but things would have to be changed in ADRipper on a rather fundamental level. The plugin system currently depends on the data provided by the main program, this being raw PCM data extracted from the CD.
At any rate you can try contacting CentaurZ but I'd guess he's too busy to embark on a substantial code rewrite.
AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2
@trixie
What thomas said. :-)
AHI pretty much uses native integers of the host system for its sound input data. So it could be said that it doesn't accept sound at all but integers. It also tends to use interleaved format for stereo channels where each channel sample comes after the other. As opposed to 8SVX or Paula where each channel is stored complete with the next one after that. So loading in an 8SVX and playing it can be hard in AHI. Trying to play each channel separately even over real Amiga hardware with AHI introduces timing issues.
So AHI has a standard for it's input. AHI also likes to do the mix-down itself and so can even convert the input data to floating point for this. Finally AHI sends a rendered stream to the soundcard and yet another conversion occurs to the native soundcard format.
Now you mentioned raw sound data. It has been asked if AHI could accept the native soundcard format to ensure a more direct efficient process. Such as a SoundBlaster using WAV for its native format. But it doesn't, as in this case, the native soundcard format is a relative term. That format could be anything. So AHI is the middleman which takes care of that dirty work. Also, being AHI likes to mixdown the final result itself, the native soundcard format would be no good anyway. :-)
@thomas, @hypex
Thanks for the explanations, both of you!
AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2