0
0

The fileoffset in CreateSound still does not work, and just hang.

After some more testing is seems that the length parameter is ignored when fileoffset <> 0. My samplefile is 900MB and then it would of course take a LONG time to load and decode the sample when it ignores the length ๐Ÿ˜ฎ

When trying on a small file it did not hang. So it’s still a problem with the fileoffset/length.

But memoryload works, at least with a fileoffset of 0

  • You must to post comments
0
0

Hi !

Which flags should I use when creating the system and creating a sound to have a stream opened the quickest way ? I want to open a file for streaming, and use readdata/seekdata afterwards… should I use OPEN_ONLY | CREATE_STREAM, and that’s all ? It takes a “long” moment and a huge amount of CPU when opening (about 500-700ms, it’s not so long, but too long for me, and the huge amount of CPU makes the song I’m currently playing pause for a while… because it has no CPU left !)

Thanks !

  • You must to post comments
0
0

If your operations would conflict with fmod’s mixer thread, then they might also conflict if all your code is in the same thread as the thread you created the system object in.

  • You must to post comments
0
0

I use these 2 flags when creating my sound… but it takes 500-700ms to load it…

when I don’t specify createstream, it takes 4-5 seconds, and 50MB of ram :)

  • You must to post comments
0
0

But what does the mixer thread do if I’m not “playing” files ? I just open them and call readdata or seekdata…

  • You must to post comments
0
0

Is it the intention that a FMOD_CHANNEL_CALLBACKTYPE_END callback will fire when FMOD_Channel_Stop() is called?

This didn’t happen in previous betas – but I’m not sure exactly when the behaviour changed. Is this the expected behaviour now?

  • You must to post comments
0
0

I have done some more testing:

[code:8wreiue2]Private Sub Test()

Dim exinfo As FMOD_CREATESOUNDEXINFO
Dim lResult As Long
Dim sFileName As String
Dim lOffset As Long
Dim lLength As Long
Dim lPointer As Long
Dim System As Long
Dim version As Long

lResult = FMOD_System_Create(System)

lResult = FMOD_System_GetVersion(System, version)

If version &lt; FMOD_VERSION Then
    MsgBox &quot;Error!  You are using an old version of FMOD &quot; &amp; version &amp; &quot;. &quot; &amp; _
           &quot;This program requires &quot; &amp; FMOD_VERSION
End If

lResult = FMOD_System_Init(System, 32, 16, FMOD_INIT_NORMAL, 0)

sFileName = &quot;q:\etaleboka\etaleboka.tsb&quot;
lOffset = 845276630
lLength = 8539
exinfo.cbsize = Len(exinfo)
exinfo.fileoffset = lOffset
exinfo.length = lLength

lResult = FMOD_System_CreateSound(System, sFileName, FMOD_SOFTWARE + FMOD_CREATESAMPLE, exinfo, lPointer)

lResult = FMOD_System_Close(System)

End Sub[/code:8wreiue2]

This crashed FMOD. The length and offset are correct.

If I set a invalid offset (for example correct offset+1) it returns error 22 (Invalid sound format). Using offset 0 works.

By changing the length it still crashes, until the length is about 2000 then it returns error 22.

The format being read is OGG and in VB6.

It might be a specific problem with VB6 or the VB FMOD defs. I have double checked that the VB FMOD def files are correct, and the DLL.
BTW: Please include the verion number of FMOD Ex in the DLL file. It says 4.0.0.0

So I still insist that this is a bug ๐Ÿ˜€

  • You must to post comments
0
0

Hmmm… I’m not sure if it’s an “issue”, I can code around it if that is the intended behaviour.

I’m not sure it’s terribly intuitive however. I was certainly surprised to see the callback fire, and it hadn’t occured to me before that calling stop() might fire the _END callback.

Others might disagree though?

  • You must to post comments
0
0

[quote="brett":1fkzy1q6]if you say the version is 0 this just isnt the case. I looked at it using an example and the VB debugger and it said ‘262184’ which is 40028h as expected. All fmod examples do the version check.[/quote:1fkzy1q6]He’s talking about the Version resource in the actual DLL, which Windows Explorer uses for displaying DLL information. The version resource in fmodex and fmodexp says ‘4.0.0.0’.

  • You must to post comments
0
0

It seems logical to me, though I can understand why it might be desirable for it not to behave this way. Personally, i’d rather have it be consistently annoying than be inconsistently convenient. :)

  • You must to post comments
0
0

Hello !

I’ve posted in the previous thread (about version 27), but had no answers… And because I don’t see my problems in the fix list or so, I’m posting it here again :

[quote="FunkyMan":2sampv6y]Hello !

I’m using FMOD Ex to uncompress data.

I’m using ReadData and SeekData for that.

Everything works OK, but sometimes, ReadData throws some exceptions, and my reading thread gets killed… quite annoying ! Sometimes, SeekData throws me exceptions too…

I think I’m using it correctly, but because I don’t have any example, I can only assume it’s OK…

I’m using a Marshal.AllocHGlobal to allocate a buffer for unmanaged code, then I use Marshal.Copy to copy the buffer after having called ReadData and finally, Marshal.FreeHGlobal the buffer…

Is it a known bug ? Do you have some examples on how to use ReadData and SeekData correctly (I’m using C#) ?

Secondly, I have some problems with tags. Somethings, FMOD won’t read the tags. Calling the function a second time works… or not. It’s quite random. Sometimes yes, sometimes no.

The tags I’m trying to read are ID3 V1 from MP3.

The code I’m using is the one from the example (that gets the number of tags and calls get_tag for each one), except I have a file chooser.

When I try to read the tags from the same files, sometimes it works, sometimes it doesn’t… Not working means that some parts of the tags are NULL… (I can have the artist but not the title, or nothing, or both).

Is it a known bug ?

Thanks !!![/quote:2sampv6y]

Thanks in advance…

  • You must to post comments
0
0

Hi Brett,

Regarding the fileoffset problem I have sent you a mail with a test file.

David

  • You must to post comments
0
0

I’ll try to protect the readdata and seekdata with a mutex to avoid threading conflicts and post the result here…

But for the tag problem, I really don’t know. Accessing to different streams isn’t thread safe ? If I play a mp3 with a thread, I can’t open another stream and read its tags from another thread ?

In fact, I’m reading a mp3 on a thread with readdata, and I want to read the tags of other streams from another thread. Therefore, I open other streams, read the tags, and close the streams… If it’s not threadsafe, then it’s probably the cause of the problems !

I’ll try to protect that too, but I’ll appreciate if streams were threadsafe (I admit that readdata and seekdata on the same stream should not be safe, but accessing to other streams while reading should be ok in my opinion…)

Thanks for your answer, i’ll investigate threading problems ๐Ÿ˜‰

  • You must to post comments
0
0

[quote="brett":2wcs9eyr]i don’t think it would be hard to take out, but i think fmod3 fires on stop? can’t quite remember.[/quote:2wcs9eyr]
From going back to look at my fmod3 code I’m pretty sure that it didn’t. (A lot of things have changed since then – but I was using FSOUND_StopSound() in places.)

I agree with Janus that the most important thing is for it to be consistent, but to me the end callback was to indicate when a sound had played to the end not when it stopped for any reason. I guess it all depends on how you look at it. But I don’t think that fmod3 nor earlier fmodex alphas did this.

So long as it is documented in either case – I can code to either. 8)

  • You must to post comments
0
0

[quote="FunkyMan":24xp4kwm]I’ll try to protect the readdata and seekdata with a mutex to avoid threading conflicts and post the result here…

But for the tag problem, I really don’t know. Accessing to different streams isn’t thread safe ? If I play a mp3 with a thread, I can’t open another stream and read its tags from another thread ?

In fact, I’m reading a mp3 on a thread with readdata, and I want to read the tags of other streams from another thread. Therefore, I open other streams, read the tags, and close the streams… If it’s not threadsafe, then it’s probably the cause of the problems !

I’ll try to protect that too, but I’ll appreciate if streams were threadsafe (I admit that readdata and seekdata on the same stream should not be safe, but accessing to other streams while reading should be ok in my opinion…)

Thanks for your answer, i’ll investigate threading problems ;-)[/quote:24xp4kwm]A mutex might not necessarily protect you from threading issues, as FMod and FMod EX already create threads in the background to do mixing, etc. I suggest making ALL of your audio code run in the SAME thread.

  • You must to post comments
0
0

[quote="andrewboothman":pppdr66r]I agree with Janus that the most important thing is for it to be consistent, but to me the end callback was to indicate when a sound had played to the end not when it stopped for any reason. I guess it all depends on how you look at it. But I don’t think that fmod3 nor earlier fmodex alphas did this.[/quote:pppdr66r]Perhaps there need to be seperate callbacks for both End and Stop?

  • You must to post comments
0
0

With one of the first fmod ex beta I had some crashes due to calling readdata from different threads in my application.
I then added a critical section so that no fmod calls happen simultaneously and I didn’t have any threading problems after that.
I’m still doing the readdata’s in a different thread than the createsounds, and haven’t had a problem so far.

I haven’t tried reading tags with fmod though, so I can’t really tell if there are some threading issues with these other functions.

  • You must to post comments
0
0

the “stop” callback could be called when the stream is actually stopped, and that could be cool if the stream takes a long time to stop (change image when stop is effective, or something like this)

:)

  • You must to post comments
0
0

[quote="Janus":3rjv17z9]A mutex might not necessarily protect you from threading issues, as FMod and FMod EX already create threads in the background to do mixing, etc. I suggest making ALL of your audio code run in the SAME thread.[/quote:3rjv17z9]

a mutex won’t protect me from threading issues with readdata and seekdata ? I don’t use any other functions, appart from these 2 (and get tag)…

I can’t make all the audio code run in the same thread, that’s simply not possible :) How can someone seek while I’m reading data ? I’m using a graphic interface, and seeking can happen at any time…

I’ll use a kind of critical section tonight, and give you the feedback tomorrow

Thanks

  • You must to post comments
0
0

Yeah, in case you’ve not guessed I’m with Brett on this one. I’d just like to see the END callback fire only when a sound plays to its end!

  • You must to post comments
0
0

[quote="FunkyMan":32aca02h][quote="Janus":32aca02h]A mutex might not necessarily protect you from threading issues, as FMod and FMod EX already create threads in the background to do mixing, etc. I suggest making ALL of your audio code run in the SAME thread.[/quote:32aca02h]

a mutex won’t protect me from threading issues with readdata and seekdata ? I don’t use any other functions, appart from these 2 (and get tag)…

I can’t make all the audio code run in the same thread, that’s simply not possible :) How can someone seek while I’m reading data ? I’m using a graphic interface, and seeking can happen at any time…

I’ll use a kind of critical section tonight, and give you the feedback tomorrow

Thanks[/quote:32aca02h]The problem is that FMod and FMod EX both run mixer threads in the background and there’s a possibility that your operations might conflict with the mixer thread. I’m not aware of any way for you to prevent the mixer thread from doing things while you’re doing things, or for you to wait for the mixer to be ‘done’ before doing anything.

  • You must to post comments
Showing 20 results
Your Answer

Please first to submit.