Compiler issue with sound commands

[Nuke]

Thanks Fellippe,

That was a good idea.  I was using the version that the Windows 10 latest stable link was pointing to.  I downloaded and tried the e490b1a build.  Installed and tried running it as administrator, and just entered the single line a& = _SNDOPEN("dog.wav") and got the same compiler error message.  Good try though. 

[FellippeHeitor]

/me sighs

This is really frustrating. I just updated my Windows 10 VM and installed QB64's dev build on it.

No issues compiling with sound statements at all.

The mp3 above played beyond 1:35 just fine.

The dog.wav file played a bit too fast, but no errors besides that.

I'm really sorry we can't pinpoint what's going wrong with your systems so it can be fixed.

[Nuke]

No worries, thanks for looking into it.  I'll just use the _SNDRAW command instead as a work around.  It seems to work for some reason.
This is frustrating, though.  There's very little to be gained from solving this issue, even for me, but unresolved errors drive me crazy.  If you hear of any developments, please let me know.

Sometimes coding seems like two steps forward, one step backwards, and not always in that order. 

[Bert22306]

Using Fellippe's program (modified only to give the proper path to the sound files, and added an END statement), Fellippe's IDE tweaks in the development build updated a couple of days ago, Win10, dog.wav, plays fine on my machine. Oh, also sulc.mp3 played fine.

[TempodiBasic]

Hey Fellippe
we got the same results on 2 different machine and OSes with  dev build of QB64!
Something goes good!

[FellippeHeitor]

Good to hear!

[FellippeHeitor]

So I found one more bug about SNDRAW in the 07-21-18 version - if the playing is longer than a minute and 35 seconds breaks into noise. When compiling in the old version of .85, this will not happen and everything works as it should. To test this error, I attach an external MP3 decoder (third party software). Take the attached MP3 file and play it in the previous program. When compiling in the latest ide, the noise will go to the end after 1:35. When compiling in the older one, everything runs right to the end.


edit: older ide = .85 a test it on more than 10 MP3 files, behavior is always the same. The old IDE .85 has no problem, the new sabotage my work after 1:35

I apologize for misreading your post, Petr. I see now that it's with your custom code for playing audio that there's noise after 1:35. I'll try your code this time and get back to you soon.

[FellippeHeitor]

Ok, I've just run your audio player and tested with the MP3 you provided, having been decoded by mp3enc.exe.

It played all the way through the end, no issues, on my Windows XP virtual machine.

It's again something interacting weirdly on your system, I'm sorry I can't help immediately.

Fellippe.

PS: I've said this before, but I do love your player and the visuals. It's still flickering at some points, but other than that it's a really cool app. The ending battery animation is really cool.

[Petr]

Thank you for the information Fellippe. It does it under windows 7. I add compiled EXE (if then it work right for you, then i have bug here.) Exe is compiled for sulc.mp3

I'm delighted that you like it.

This blinking is due to the fact that I did not have enough experience at the time I wrote it. Playing is direct, I would use a cache today because _SNDRAW is very sensitive to timely data delivery and the data-flow is big. This is also why the processor time is divided into different operations. When I tried everything at the same time, then program play very bad.
I even needed so much power, that I could not use _Display.

[Bert22306]

Hey, perhaps this is something everyone already knows. Whatever codec is used in QB64, to play back wav files, seems to play them back too fast? The dog.wav played back too fast, and so does the attached one.

Conversely, mp3 files sound great played back in QB64. Is this a well known problem?

I've also run up against a problem where the wav file won't even load. Doesn't happen all the time, and it can be hard to reproduce, but it seems like when it does happen, you have to play something else, then retry and it might work. Or it just won't play. Gives some useless error message. The important thing being, it does not even load.

Only wav files, not mp3 files, which seem to work flawlessly.

[Petr]

Hi. This is exactly the same as the sound we dealt with Nuke. QB64 simply reads this monophonic wav as if it were stereo, that is, 2 bytes per pass instead of 1 byte per pass, and this causes twice the speed and half the playback time. My program play your wav file right.

[Petr]

maybe it help you:

Code: QB64: [Select]

1. wav "slacker.wav"
2.  
3. SUB wav (file$)
4.     TYPE head
5.         chunk AS STRING * 4 '       4 bytes  (RIFF)
6.         size AS LONG '              4 bytes  (?E??)
7.         fomat AS STRING * 4 '       4 bytes  (WAVE)
8.         sub1 AS STRING * 4 '        4 bytes  (fmt )
9.         subchunksize AS LONG '      4 bytes  (lo / hi), $00000010 for PCM audio
10.         format AS STRING * 2 '      2 bytes  (0001 = standard PCM, 0101 = IBM mu-law, 0102 = IBM a-law, 0103 = IBM AVC ADPCM)
11.         channels AS INTEGER '       2 bytes  (1 = mono, 2 = stereo)
12.         rate AS LONG '              4 bytes  (sample rate, standard is 44100)
13.         ByteRate AS LONG '          4 bytes  (= sample rate * number of channels * (bits per channel /8))
14.         Block AS INTEGER '          2 bytes  (block align = number of channels * bits per sample /8)
15.         Bits AS INTEGER '           2 bytes  (bits per sample. 8 = 8, 16 = 16)
16.         subchunk2 AS STRING * 4 '   4 bytes  ("data")  contains begin audio samples
17.     END TYPE '                     40 bytes  total
18.     DIM H AS head
19.     ch = FREEFILE
20.  
21.     IF _FILEEXISTS(file$) THEN OPEN file$ FOR BINARY AS #ch ELSE PRINT file$; " not found": SLEEP 2: SYSTEM
22.     GET #ch, , H
23.  
24.     block = H.Block
25.     RATE = H.rate
26.     chan = H.channels
27.     bits = H.Bits
28.  
29.     DO WHILE NOT EOF(ch)
30.         IF bits = 16 AND chan = 2 THEN
31.             REDIM lefi AS INTEGER, righi AS INTEGER
32.             GET #ch, , lefi
33.             GET #ch, , righi
34.             lef = lefi / RATE
35.             righ = righi / RATE
36.         END IF
37.  
38.         IF bits = 16 AND chan = 1 THEN
39.             REDIM leftMono AS INTEGER
40.             GET #ch, , leftMono
41.             lef = leftMono / RATE
42.             righ = leftMono / RATE
43.         END IF
44.  
45.         IF bits = 8 AND chan = 2 THEN
46.             REDIM lleft8 AS _UNSIGNED _BYTE, rright8 AS _UNSIGNED _BYTE
47.             GET #ch, , lleft8
48.             GET #ch, , rright8
49.             lef = lleft8 / 256
50.             righ = rright8 / 256
51.         END IF
52.  
53.         IF bits = 8 AND chan = 1 THEN
54.             REDIM mono8 AS _UNSIGNED _BYTE
55.             GET #ch, , mono8
56.             lef = mono8 / 256
57.             righ = lef
58.         END IF
59.  
60.         IF RATE > 44100 THEN frekvence = RATE ELSE frekvence = 44100
61.         FOR plll = 1 TO frekvence / RATE
62.             _SNDRAW lef, righ
63.         NEXT plll
64.  
65.         DO WHILE _SNDRAWLEN > 0: LOOP: REM comment this
66.     LOOP
67.     CLOSE ch
68. END SUB
69.  

for playing "in background" comment line, selected in source, but this is not recomended, because if you use big wav files, memory usage is very high and this can do problems.

edit: source code upgraded (unnecessary portions of the code deleted, without affecting the function)

[Bert22306]

Thanks, Petr. That does work. So, it's a question of mono playback not understanding that all of the sound packets now belong to one channel, as opposed to half of them to the right and half to the left. So only stereo files will play correctly, as things stand. Interesting. Should be addressed at some point in QB64?

[Cobalt]

just FYI guys, your Dog.wav plays back just fine on my VISTA laptop machine with QB64 build 20171106/82

a& = _SNDOPEN("dog.wav")
IF a& = 0 THEN BEEP ELSE _SNDPLAY a& 'check for valid handle before using!

granted mono 11k sounds bad but it played no issue.

[SMcNeill]

And try the latest version (the development build, not the stable build).  I remember Luke pushing changes to fix issues like these for us.  Check to see if the problem has already been addressed, please.