Author |
Topic: wav files (Read 403 times) |
|
roy
New Member
member is offline
Posts: 44
|
 |
Re: wav files
« Reply #12 on: Mar 7th, 2018, 8:41pm » |
|
Hi Richard
That made no difference and I do not know how to re-encode them, so I tried some different wav files and manage to get three to play one after another  , but when I added a forth the first one played OK and then the next two played slowed down and the last one played OK
I guess they do need re-encode.
Regards Roy
|
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: wav files
« Reply #13 on: Mar 7th, 2018, 9:36pm » |
|
on Mar 7th, 2018, 8:41pm, roy wrote:| That made no difference and I do not know how to re-encode them. |
|
Google, as so often, is your friend. There are web sites that will do it for you. For example this one.
Richard.
|
|
Logged
|
|
|
|
vbi
Guest
|
|
Re: wav files
« Reply #14 on: Mar 8th, 2018, 09:59am » |
|
Hello Roy,
I'm glad to see that you've made some progress. Re-encoding all your wav files to the same format may well make your life easier. However, it is possible to play files of differing format encoding and sample rates sequentially with a little modification to the code.
In case it is useful to you, or indeed others, here in an example based on Richards's original code that works for me -
Code: DIM AudioSpecRequired{freq%, format%, channels&, silence&, samples{l&,h&}, size%, callback%, userdata%} DIM AudioSpecObtained{} = AudioSpecRequired{} REM Define some default settings - should be overwritten when WAV file is loaded AudioSpecRequired.freq% = 44100 AudioSpecRequired.format% = &8010 : REM AUDIO_S16LSB AudioSpecRequired.channels& = 2 max% = 4 DIM WavFile$(max%-1) WavFile$(0) = "c:\InOut\Test Card Music\23 - Going Places.wav" WavFile$(1) = "c:\InOut\Test Wavs\a2002011001-e02-ulaw.wav" WavFile$(2) = "c:\InOut\Test Wavs\a2002011001-e02-16kHz.wav" WavFile$(3) = "c:\InOut\Test Wavs\11k16bitpcm.wav" w% = 0 REPEAT Music% = FNLoadSound(WavFile$(w%)) IF Music% = 0 ERROR 100, "Couldn't load music file" PROCPlaySound(Music%) PROCAudioInfo(WavFile$(w%)) WAIT 1000 : REM = 10 Second Excerpt PROCCleanup w%+=1 UNTIL FALSE OR w% = max% END DEF FNLoadSound(path$) LOCAL A%, P%, R% DIM P% 7 : REM allocate from heap SYS "SDL_RWFromFile", path$, "rb" TO R% IF R% = 0 ERROR 114, "Couldn't open sound file: " + path$ SYS "SDL_LoadWAV_RW", R%, 1, AudioSpecRequired{}, P%, P%+4 TO A% IF A% = FALSE ERROR 115, "Couldn't buffer sound: " + path$ SYS "memcmp", A%, AudioSpecRequired{}, 9 TO R% IF R% ERROR 116, "Couldn't convert sound format: " + path$ = P% DEF PROCPlaySound(P%) IF @hwo% = FALSE SYS "SDL_OpenAudioDevice", FALSE, FALSE, \ \ AudioSpecRequired{}, AudioSpecObtained{}, 0, @memhdc% TO @hwo% IF @hwo% = FALSE ERROR 117, "Couldn't open audio device" SYS "SDL_ClearQueuedAudio", @hwo%, @memhdc% SYS "SDL_QueueAudio", @hwo%, !P%, P%!4, @memhdc% SYS "SDL_PauseAudioDevice", @hwo%, FALSE, @memhdc% ENDPROC DEF PROCAudioInfo(now$) LOCAL p%, tmp%, fmt$ PRINT "Now Playing > "+now$ FOR p% = 0 TO 1 IF p% tmp% = AudioSpecObtained.format% ELSE tmp% = AudioSpecRequired.format% REM This is a not an exhaustive list! CASE (tmp% AND &FFFF) OF WHEN &0008 : fmt$ = "AUDIO_U8" WHEN &8008 : fmt$ = "AUDIO_S8" WHEN &0010 : fmt$ = "AUDIO_U16LSB" WHEN &8010 : fmt$ = "AUDIO_S16LSB" WHEN &1010 : fmt$ = "AUDIO_U16MSB" WHEN &9010 : fmt$ = "AUDIO_S16MSB" OTHERWISE fmt$ = "UNDEFINED" ENDCASE IF p% THEN PRINT "Obtained Audio Device Sample Freq = "+STR$(AudioSpecObtained.freq%) PRINT "Obtained Audio Device Format) = "+fmt$ ELSE PRINT "Required Audio File Sample Freq = "+STR$(AudioSpecRequired.freq%) PRINT "Required Audio File Format = "+fmt$ ENDIF NEXT p% ENDPROC DEF PROCCleanup IF @hwo% THEN SYS "SDL_CloseAudioDevice", @hwo%, @memhdc% SYS "SDL_FreeWAV", !Music%, @memhdc% @hwo% = FALSE ENDIF ENDPROC
(Note: All the original PROCs have been modified in some way in this example)
This will (via the addition of PROCAudioInfo) print the current audio spec sample rate and format to the screen as the files are played -
All but one of the test files came from here -
http://www.music.helsinki.fi/tmt/opetus/uusmedia/esim/index-e.html
and here -
https://en.wikipedia.org/wiki/WAV
Again, this has been tested on Win7, as I'm nowhere near modern enough to have ever possessed an Android device!
I hope it may help someone.
|
| « Last Edit: Mar 8th, 2018, 10:03am by vbi » |
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: wav files
« Reply #15 on: Mar 8th, 2018, 1:09pm » |
|
on Mar 8th, 2018, 09:59am, vbi wrote:| In case it is useful to you, or indeed others, here in an example based on Richards's original code that works for me |
|
Roy claims to have tried that code already and to have found that it doesn't work (the only difference between your most recent code and what he tried is that you have renamed the structure temp{} to AudioSpecObtained{} and made it global).
So the question remains, why is it working for you (and me) and not for Roy? Unless he made some mistake, I can only assume that there is indeed a difference in the functionality of the SDL_*Audio* functions between Windows and Android. That would not be so surprising, for example it's entirely possible that Android cannot accept as wide a range of WAV formats as Windows can.
I would suggest to Roy that he first tests your code in Windows to confirm that it is working for him too, and then to try it on Android to confirm, or otherwise, that it is behaving differently.
Richard.
|
|
|
|
vbi
Guest
|
|
Re: wav files
« Reply #16 on: Mar 8th, 2018, 1:35pm » |
|
Hello Richard,
Yes, I agree, the majority of the changes made in that example are to allow for a verbose display of what is going on, to hopefully make any failures that occur clearer.
However, there is one important change, which is the addition of the line in PROCCleanup to force @hwo% to FALSE, therefore ensuring that the SDL_OpenAudioDevice gets re-run the next time around to take account of any changes in AudioSpecRequired{} structure.
This point was why I added the note to highlight that changes had been made to all FN/PROCs.
Over to you, Roy!
|
|
Logged
|
|
|
|
roy
New Member
member is offline
Posts: 44
|
|
Re: wav files
« Reply #17 on: Mar 8th, 2018, 3:14pm » |
|
Hi Richard
Thanks for the link. Believe it or not I did look on Google, but found nothing that help me!
Hi vbi
Thanks for the modified code. It works very well on the laptop and on my tablet
So it's a wow.wav from me.
Many thanks to both of you
Regards Roy
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: wav files
« Reply #18 on: Mar 8th, 2018, 7:09pm » |
|
on Mar 8th, 2018, 1:35pm, vbi wrote:| However, there is one important change, which is the addition of the line in PROCCleanup to force @hwo% to FALSE, therefore ensuring that the SDL_OpenAudioDevice gets re-run the next time around |
|
This question appeared on the SDL forum today. Assuming that it wasn't posted by you (!) it appears to be relevant to this discussion.
What I don't understand, and hopefully it may be explained there, is that in all the examples I have seen AudioSpecObtained{} is identical to AudioSpecRequired{}. I had assumed that if you don't close-and-re-open the audio device (which is undesirable because of the potential for clicks etc.) it would automatically convert the supplied format into whatever the output requires. This would also be important if the OS doesn't accept the source format without conversion.
It's not even clear that the initialisation of AudioSpecRequired{} has any effect at all!
Richard.
|
|
|
|
vbi
Guest
|
|
Re: wav files
« Reply #19 on: Mar 8th, 2018, 10:37pm » |
|
Hello Richard,
Quote:| This question appeared on the SDL forum today. Assuming that it wasn't posted by you (!) |
|
No, it wasn't me - I'm just a dabbler, utilising Roy's problem as my daily brain teaser. It's a good question though!
From my limited observations, I could believe that the understanding that the poster has set out seems to be entirely plausible. However, my lack of experience in these things led me not even to consider the potential for clicks to be generated on opening and closing the audio device more than is necessary (the benefits of ignorance, perhaps?!).
Quote:| It's not even clear that the initialisation of AudioSpecRequired{} has any effect at all! |
|
I assume you are referring to placing any parameters into AudioSpecRequired{} before calling SDL_LoadWAV_RW? If so I would agree. In fact I did take those lines out at one point, but put them back in a moment of self doubt because I thought that you must have put them there originally for a reason beyond my limited understanding of the SDL API.
It will be interesting to see what answer(s) come back to that question.
|
|
Logged
|
|
|
|
|
