Please tell me what is the problem in these steps:
1) A stream is opened using FSOUND_Stream_OpenFile
2) The stream is played
3) The stream is stopped (not unloaded)
4) The stream is played again
I can hear noise in the begining of playing this stream whenever steps 3 and 4 are repeated
The audio file I use is: 18kbps mp3, mono 11025 Hz, 16 bit
FMOD version : 3.63
- monem asked 15 years ago
I think I know what he means… I had similar problems when I tried to “preload” streams (i.e. PlayStream some seconds after OpenFile).
When the playback starts (or here “is continued”, though I haven’t had this problem by now), the read buffer is repeated until the following data is read (I guess it’s always so, but when nothing’s in the buffer, it’s just a “repeated silence”…). Depending on how big the buffer is, and how fast the access to the file works, the “noise” varies from “white noise” to a stutter.
In this case, I think about 50ms of the song after the pause is played (the data which is still in the buffer), then there’s a very short break, and then the song continues.
Playing the stream again (were it be stopped or not) causes this problem.
Using SetTime(0) causes the same problem too.
So I found the solution is to use FSOUND_Stream_Play as you wish but afterwards use FSOUND_Stream_SetTime(100). But I want Brett to say this is a good solution or to find another
[quote="Anonymous":dbp6l415]Playing the stream again (were it be stopped or not) causes this problem.[/quote:dbp6l415]
Well, it also happens, when the buffer was “pre-loaded” with FSOUND_NONBLOCKING.
It seems like it works like “Oh, the buffer is filled, let’s start playing”. “Oops, there’s nothing more in the buffer. Let’s try again…”. While this happens, a short break occurs. And then, the song is played again from the start.
[quote="Anonymous":dbp6l415]So I found the solution is to use FSOUND_Stream_Play as you wish but afterwards use FSOUND_Stream_SetTime(100).[/quote:dbp6l415]
Interesting solution… Strange, since 100ms are inside the default buffer size of 200ms. I would have expected to encounter the error in this case, too.
Maybe SetTime(1) before Play would work too, without skipping the first 1/10 second? Setting the Position after “Play” seems a bit risky to me, because it might cause some “stutter” or skipping depinding on the device speed…
Yes, I tried. IIRC, the only thing it changed was that the repeated part got longer…
Besides, there are some very strange effects if you set the buffer length quite high (I tried 2 seconds). E.g. if you call Stop, the playback stops [b:oq3mb7dz]after[/b:oq3mb7dz] the remaining buffer is played, i.e. with buffer length delay. That’s been the main reason for me to remove the code again… (I tried to program a “nearly gapless” playback by pre-buffering the next song while the current is played).
[quote="brett":26afssz7]Mort, your issue is totally different, i would first suggest trying to play the file you are trying to play in the fmodsamplce example player.
It is possible the stream thread isnt getting processed in your application for some reason.[/quote:26afssz7]
I think you’re talking about the “stop with lag” problem. IMHO, there isn’t much I could do wrong in my app. I just call FMOD_STREAM_Stop() (or such…), and <Buffer>ms later the playback stops.
[quote="brett":26afssz7]I’m not sure what you mean with ‘a buffer was preloaded with FSOUND_NONBLOCKING’, because that flag doesnt mean anything to do with preloading buffers, it just opens the stream in the background so you dont get any cpu stalling in the main app.[/quote:26afssz7]
Well, probably the same would happen without NONBLOCKING. It happens like this:
– Loading and playing stream 1 (Open and Play are immedially one after the other, no problems there)
– Pre-Loading stream 2 (Open with NONBLOCKING) while stream 1 plays
– Stream 1 ends, the callback function is called
– Play (the already opened) stream 2 – and here the “stutter” happens.
OK, my Yakumo Delta isn’t the fasted device, and maybe the SD isn’t that fast. But I think 500ms (which I tried as an acceptable buffer size) should be enough to catch up though, imho.
Maybe it’s the same cause tough, at least the symptoms are similar. I’ll download the patched DLL and recover the code (it’s commented out currently), and try it again. But I think I won’t find time for it before monday…
Please login first to submit.