i just changed the netsteam example to use alsa
and tryed to play an mp3 file, that worked for most files. i found one though that makes the process sudenly starve the cpu. (cpu usage goes to 100%, doing nothing). it looks like a pipe broke or something like it. with oss and esd i can play that file. sorry that i canot provide more information but trying to set the debug level with "FMOD_Debug_SetLevel(FMOD_DEBUG_LEVEL_ALL)"
resulted in: "71 A command issued was not supported by this object. Possibly a plugin without certain callbacks specified." i’m linking against libfmodex.so, so i don’t see the point of plugins here
i’m using the C api of 40600 with gcc-4.1.2
alsa kernel drivers of linux 2.6.19
thanks in advance
- aep asked 12 years ago
That thread you linked to is nothing like the report you have here. They are not the same issue.
We’ll see if we can reproduce something anyway, but as i said, if you have a normally working alsa installation you wouldnt even have this problem.
" i found one though that makes the process sudenly starve the cpu. (cpu usage goes to 100%, doing nothing)."
"sound disappears and according to FMOD_Sound_GetPosition, timer gets mad and runs approx. 10 times faster"
How are they even remotely similar?
Btw just reading that again you are saying you only get this problem for 1 mp3 file?
maybe i missed some essential part in the docu, but i wonder how to get more debug information. the error code for not available devices and blocked devices is the same, and i don’t want to tell the user error messages like "something went wrong".
and debug information would be usefull to find out why alsa dosn’t work too.
maybe my description was a bit bad.I’m sorry about that. the cpu goes to 100%, nothing is hearable but the timer runs very fast to the end.
it’s very random if it works or not. with mp3 files it happens more often and the netstream example can only be broken with one mp3 file (that one skips with ffmpeg, not with madlib)
also it depends on if there is already a program using alsa or not. if not the netstream example works always. i’m not using dmix btw, my driver can do hardware mixing, so it should not be a diference, but as i sayd portaudio had exactly the same problem.
i think these errors are coused by a combination of alsas bugs in an older version you used and some influences the qt threadlibs have on fmods decoder, but i’m not a professional in these things..
Have you tried using dmix? If it works okay with dmix, then it must be your hardware driver that is the problem (you mention that it doesn’t work in portaudio either).
You also mentioned earlier that you "found out that System::update is not thread save". Are you aware that all FMOD functions are not thread safe. If you are calling FMOD functions from different threads, that could cause problems also. Have a look at the "Threads and thread safety" section of the docs for more details about this.
I am experiencing a similar or the same problem. My system is setup to use dmix which works fine in all other applications on the desktop. When I modify the 3d example packaged with FMODEx with a call to System_SetOutput with FMOD_OUTPUTTYPE_ALSA, the audio plays for about half a second, then I hear nothing and CPU goes to 100% usage.
I tested with 3.06.12 and 4.07.09. Both behave the same way.
Note that I am simply adding a single line to examples/3d/main.c. There is no threading or other weirdness going on here.
If it helps, I have an Intel CoreDuo laptop. Perhaps this has to do with multicore or multiprocessor machines?
even happens while doing nothing (running the gui thread after init but never touch fmod again) in combination with qt.
also happens if fmods init is called before qts mainloop
also happens if you do an init and run for(;;) after
there are propably many other cases that couse the pipe to break, and i’m still in search for debug information
this happens for alsa only. i saw it often as i tryed to mess with alsa myself coused by a broken pipe.
i would be glad if anyone could some day answer on this thread.
actualy i don’t have to much hope this library actualy tends to work on linux. no g++ interface, no alsa, no jack. oss and esd are just there becouse other os use them too…
i connot sell a cross platform product using a library i never know if it works or not, sorry..
not providing debug information is the most amusing part, not only that it dosnt work, it does not even tell you why.
Are you saying this only happens WITH qt? What about alsa using the normal text mode apps like the 20 or so examples that fmod ships with. Have you tried these modes and confirmed you even get the same problem?
I havent heard of anyone else having this issue, you say alsa ‘doesnt work’ but its been workig for a while now with no complaints.
We’ll try and repro it here if you can give us some better info, like what hardware you have. You were talking about multithreading before, why was that relevant?
You said you did a for ( ; ; ) which basically will be locking up the thread anyway, is there a better test you have there, such as simply sleeping every 20ms or so with a printf inbetween.
What do you mean ‘no g++’ interface. g++ is a c++ compiler and we have fmod.hpp. Also i’m not sure why you would want JACK support, as far as I know that is just a wrapper for alsa/oss etc anyway.
it has already been reported here http://126.96.36.199/forum/viewtopic.php … light=alsa
yes it happens with the examples too, but not that often
the previous version of portaudio had the same problem, but it drops an error saying the pipe broke.
i would be glad if there is a way to get debug information. e.g. what exactly happened.
Please login first to submit.